Working at a design consultancy, documentation is often the primary deliverable we hand off to clients. When dealing with complex interactions, it’s not uncommon for documents to be over 100 pages long. Drafting these types of deliverables takes serious care, attention to detail, and significant time working at high fidelity in programs like Illustrator and Photoshop.

The big concern is that when designers ship their work to clients, the final documentation doesn’t become the final product regardless of how well it’s crafted.

“Documentation could be overlooked, ignored, or simply out of date by the time it comes to actually implement a feature if we’re working with a very agile development team.”

This is something Jason Frasier, design director at DesignMap, said when he stopped by Tradecraft last year to share his perspectives on prototyping. He discussed how it's replacing documentation as a UX deliverable, and how we can utilize prototyping in our design process.

Documentation is inflexible. Often, the effort involved keeping things consistent when changes are made can be more challenging than creating the design itself. In all, documentation can’t always meet the evolving needs of a client when they prepare to ship their product and that is problematic.

Prototypes are Powerful

"People don’t read products, they interact with them."

Creating a prototype as a final deliverable allows for greater interaction with the product and a deeper-level understanding of how the product is experienced. It can also easily be adopted for usability testing and iterated on quickly and efficiently to push out new versions.

Prototyping is also an impactful way to present to your client. People know how to interact with products. Demonstrating interactions with a prototype helps to spark well-informed discussions with clients and can lead to better design more quickly.

Demonstrating interactions with a prototype helps to spark well-informed discussions with clients

When discussing prototyping, it’s important to understand the methods and know when to use them. Jason went over five prototyping techniques that he thought were important to utilize at different parts of the design process.

How to Utilize Prototypes

Here’s Jason’s breakdown of how to use prototypes as you move through the design process.

Paper Prototype
  • Creating rough, hand-drawn sketches of UIs to put in front of users for testing.
  • When to Use: When you want to validate basic design ideas and understand rough interactions before going forward at a higher fidelity.
  • Presentation: Paper cutouts
Vision Prototype
  • Creating a presentation that quickly runs through an interaction at high fidelity.
  • When to use: When you want to wow your client. When it’s more about the polish than the actual experience. If you need to sell an idea.
  • Presentation: Keynote
Click-Through Prototype
  • Creating a set of static wireframe slides and discussing slide interactions.
  • When to use: When working with developers and project managers to demonstrate a linear flow through an experience quickly and efficiently.
  • Presentation: Invision, PDF
Wireframe Prototype
  • Creating a clickable wireframe prototype that can be put in front of users.
  • When to use: When conducting user testing or demonstrating interactions to clients at a higher fidelity.
  • Presentation: InVision
High Fidelity Prototype
  • Creating a prototype that closely resembles the real product.
  • When to use: When your product is nearly ready to ship.
  • Presentation: Web browser, mobile device, InVision.

Conclusion

If you’re a UX designer, knowing how and when to prototype is already a requisite skill. Now, teams are transitioning from documentation to prototypes as final deliverables. Prototyping can make your design process more agile, allow you to express complex interactions elegantly, and present your work to your client in a more dynamic and iterative way. Avoid 100+ page documents and start prototyping.

 

Image of crumpled paper spilling out of wastebasket courtesy Shutterstock.

Article No. 1 345 | November 17, 2014
Article No. 1 255 | June 17, 2014
Article No. 1 145 | November 19, 2013

Add new comment

Comments

I'm very curious about how big you can scale to bigger project with InVision, particularly with a remote teams. InVision isn't a tool we could completely switch to.If you have a lot of logic, many different states and variations etc... invision isn't relaly suited to that. InVision is great at prototyping key flows between screens, but not as good at going into the details on those screens.I wonder how people manage that either with InVision or together with other tools? Have you heard more about that since you wrote this?

I was prototyping in the 1990's. We would work up designs from sketches through to paper models and then build click through prototypes. In those days we were using Macromind Director (on Macs - which we had to pretty much hide from view) to produce animations that would be signed off and handed over to C coders who used it to make the fundamental apps for an OS being developed by a major player (definitely not for Macs). The animations looked and worked exactly how they ended up but of course the depth of functionality was very slim. We were able to pass these prototypes over to the documentation team at the same time so they could get a head-start.

However, we always also produced paper documentation to provide that extra information on what it was all about. We just could not skip on paper documentation.

This was, fortunately, a relatively short period in my career. Our team was then asked to develop designs for software by various customers who had seen our prototypes but we had switched development tools. The look of amazement from our clients when we told them that what they thought would only be a prototype was actually 75% of the end product with no rewriting (or additional cost) was a joy.

Always prototype. You would develop a new physical product without making a number of test models now would you? Prototype early and often.

Great job on the post. I think we need the documentation for what are requirements and anyone know what going on with the project. Prototyping is great for people who need a form of visual. Also, great for the finding a errors like visual and side by side for stakeholder to see which one they like. For the engineers, we need a form of documentation that way we can know what we need and not need to use or make for the project.

First off, great write up. I totally believe documentation is on it's way out. Especially in a lean work place. This article though, seems to be more of an InVision App fan boy article. Having just spent the past two weeks researching prototyping tools, InVision falls very short in comparison to most of the other tools. 

 

1) Marvel app is much like InVision, it's well worth a try, as it has some other features InVision is missing.

2) InVision lacks data, dynamic text fields, input, or tables. This brings us to JustInMind, a free PRO trial is available for 30 days.

3) UXPin, is not native, though it's great for initial prototyping, but has it's limitations. JustInMind has those short comings covered. 

4) InDesign, Keynote, Acrobat, and PowerPoint - They are options, but have many of the same short comings as InVision. InVision requires you to create full-size mocks of each state. Yeah, want to fill that text field with a user name? You have to create the text field with a predefined user name and REXPORT the image as a Screen. No thank you, that's to much like the Acrobat workflow. InVision lacks layer visibility. No thank you again.

5)  ZURB's Solidify is an app for prototyping, it's similar to InVision and Marvel. Keep going, it's way to basic and they have the whole subscription-based-price-to-feature model. No thanks. $60 a month and you get even more basic tools. Bleh.

6) Macaw App, (allegedly) generates usable code. Having spent some with with the app as an early beta tester, I have to say that it's a great concept, it's still young though. It's being improved upon regularly. It's mission, generate usable code from a decent WYSIWYG editor. It can be basic, or it can be advanced. It's in the same family as Dreamweaver.

 

InVision is great for showing the one or two interactions in a linear fashion. Limiting the level of detail you can dive into. I'm using JustInMind for a very large project, with many views and dozens of interactions on each view. It's working(for me) very well.

Hey Rubix - Thanks for your candor. In regards to how I approached structuring the article and the prototyping app that I listed, I decided to list my personal go-to and focused my formatting on one or two tools for designers to get started. InVision is the prototyping app that I use for many of my needs although there are others that offer similar and complementary features that can be helpful as well. I wrote another article about prototyping that contains a more comprehensive list of prototyping tools here: http://bit.ly/1qqoqOh 

Great to get your contributions! 

Great article! Check out http://paperproto.com it goes along with the paper prototyping section of this article.

I was told that in my design field of Design Management that we cannot prototype because we are not a product, we are a strategy-and that we would have to keep creating strategy documentation.  

May I have some feedback on this please?

thank you

 

 

You have to validate your strategy somehow, no? Though if you're not creating a product or an interface from which users, or mangers in your case, will interact, what exactly are you prototyping?

I learned a long time ago that school taught us one very significant thing. Where the rules are and why they exist. After that, it's your choice to take creative liberty with those rules, and break them, expand upon them, and change them as you see fit. Just becuase a rule exist, does not mean it wasn't made to be broken.

If you believe that your workflow can benefit from prototyping, then prototype.

Is the author in some way affiliated with Invision, or is the company sponsoring uxmag without a proper disclaimer...??

But the issue described is interesting. I have had some success replacing docs with prototyping in HTML/LESS with static site generators such as Mixture.io (I'm not affiliated).

Hey Andreas - I'm not affliated with InVision, although the product is my go-to prototyping software for the cases I listed. Marvel App and Proto.io are also good options to check out. Hope this helps! Cheers, 

I find myself in the same boat these days. Generate a prototype with supporting documentations such as user story whiteboards and certain edge cases only have the documentation portion being ignored.

With agile timeline being what it is, I decided to get the software evelopers to add their own notes to the prototype as a separate layer. This activity encourages conversations and dicsussions between interaction design and software design, enabling us to find edge cases from both business side and software side. Since part of the supporting documentation is generated by the software development team, it encourages them to revisit the documentation. If they have further questions, the supporting documentation is right there where they are looking instead of having to dig through a different document artifact or a whole other system.

This activity takes place in the form of a meeting, but I find that it saves me time later. There are less adhoc, and often duplicate, questions being asked by multiple developers.

 

Great idea having devs augment prototypes, but there's still the issue of keeping the prototype up to date.

With Responsive Web Design being the de facto standard now, we started creating high fidelity prototypes as the final delivery in the UX/design phase of website projects. Unfortunately there is still a fair bit of documentation needed as a prototype sometimes can't cover all variations/business cases. This is an issue as implementers have to look at two deliverables instead of one (and tend to ignore the documentation...). Still looking for a good solution, did anybody face similar difficulties?

Agreed. In many cases a prototype complements instead of replaces documentation. It's also a great communication tool. Remember the "a prototype is worth a thousand meetings" quote, that's very true. You have to see it work to really be able to judge an approach.

I think there's still a great challenge in covering all the business rules and exceptional cases in prototypes, like Finn mentioned. Technically, all these rules can be integrated in (a rather complex) prototype, but how would you make sure these edge cases will be covered in development? Some sort of checklist for the possible use cases would be needed.

Documentation is indeed failing several ways as mentioned by Jason Frasier. Prototypes can help in communicating these design ideas. But I think that in a classic waterfall project prototyping is insufficient. However, in a more agile projects, where you'd have developers on board who can build and test certain flows, leaving out documentation is generally a lot easier. The scrum/planning board would simply function as a checklist in that case.

Thanks for this article.

I have been creating documents and start questioning myself as the projects are getting larger. The static documents can not translate well enough with interactions and also the clients, stakeholders have a hard time to see the project as a whole. We miss things with the static documents, realize that when questions coming from the developers. 

I've been looking for the better ways to use combinations with document and prototype in our projects for a while.(softwares) Saying that changing the process with the established team may be much harder...:-)