Best practices for interactive prototypes deliverables?

Question

I'm introducing Axure prototypes to a client for the first time. While Axure offers very detailed annotations and specs, I think it's overkill for this project—a scheduling application for internal use. The project manager is used to Visio flows and Photoshop comps but is as eager as I am to elevate the design/approval process. I want to find out what level of detail is recommended in the UI, annotations and specs. My question is not specific to Axure, but that is the tool I'm using.

Revised: I'd like to refocus the question towards deliverables. Which deliverables are important for the client to see, and how far do you develop them? For example, the Axure specs might be useful to the development team, but for the UX/UI design approval cycle, I don't think they're useful.

Answer 1

The reason why we do prototypes is to convey ideas/concepts/solutions that can't be conveyed through showing static screens.

I always use the rule that whenever you want to give a feel or an understanding of the flow in your application/web service you should do prototypes.

It is with the prototypes that you can simulate how something might feel like.

For instance if you want to show a search functionality that functions like google suggest and your client is unlikely to know what you mean just by the reference. Then make a prototype to show it.

I believe that the flow of any application is one of the blind spots of normal UX. Much of what makes an application is what happens between the clicks.

Answer 2

For prototypes I'd say that you need to get to the level of detail where you are able to explain and illustrate the functionality in a way that is easy to understand.

However, it is also of major importance that no-one believes your prototype to be a finished (or nearly finished) product. In that case you run the risk that your customer either thinks that you can deliver tomorrow ... or you'll find yourself stuck in a discussion over minor (cosmetic) details—in a prototype that is not necessarily meant to look exactly like the final product, that is!

---

In general, an unfinished / unpolished prototype or mock-up will invite user input, critique, and alternative solutions. It can make users see potential transformations of existing practice (Ehn & Kyng 1991, p. 652). Also, it will hardly be mistaken for a final product (Ibid.; Beyer & Holtzblatt 1998, pp. 372-3). (This is precisely why I love Balsamiq Mockups.)

A functional prototype, on the other hand, makes it possible for users to get hands-on experience in concrete usage situations (Bødker & Grønbæk 1991, p. 198).

In a prototype there is no question of an attempt at completeness; its function is to throw light on specific aspects of the information system. There will be particular emphasis on those aspects about which there is most uncertainty. ... Prototypes are used to verify the accuracy of the assumptions made about those aspects. In contrast to production systems, prototypes are typically incomplete, and are not intended to function faultlessly. (Vonk 1990, pp. 20-1)

---

References

Beyer, H. & K. Holtzblatt (1998). Contextual Design: Defining Customer-Centered Systems. San Francisco, CA: Morgan Kaufmann Publishers

Bødker, S. & K. Grønbæk (1991). "Design in Action: From Prototyping by Demonstration to Cooperative Prototyping", in Kyng, M. & J. Greenbaum (Eds.), Design at Work (pp. 197-218). New Jersey: Lawrence Erlbaum Associates

Ehn, P. & M. Kyng (1991). "Cardboard Computers: Mocking-It-Up or Hands-On the Future", in Wardrip-Fruin, N. & N. Montfort (Eds.), The New Media Reader (pp. 651-62). Cambridge, MA: The MIT Press

Vonk, R. (1990). Prototyping: The effective use of CASE technology (pp. 20-33). Englewood Cliffs, NJ: Prentice Hall Inc.

Answer 3

The nature of your deliverables honestly depends on the scope of the project, the work you're doing, and what kind of client you're dealing with. The biggest challenge you have to face is determining what the client expects and then providing them with that (or adjusting their expectations where necessary).

For instance, a colleague of mine recently created an interactive prototype for a client in the energy sector in HTML, CSS, and Javascript. The UI that needed mocking up (it was a redesign) was so complicated that the best avenue for talking about it with the client was very high fidelity. Because he took the client by the hand and led them through the process of iterating on the prototype, the client was also able to learn a lot about what their current UI was doing wrong, why our improvements were necessary and valuable, and it gave them good insight into the amount of work involved in recreating a UI like this. The job was just to deliver the interactive prototype - based on this work, the client would evaluate their next steps. (Suffice to say we have now been contracted to redesign and implement the entire next version of the app.)

Key takeaways from this process:

• Match the fidelity of your prototype with the expectations of the client. Good project management is all about managing expectations, and that's no different for a prototyping project. So figure out what your client needs to see, and then match the type of prototype with that to best communicate your work. In interactive prototyping, I interpret "high fidelity" to mean going beyond just grey-and-white screens and actually modeling colour, typography, size, etc. as closely to the final app as possible. The only thing we left out in the abovementioned process was application of the house style (eg. turning everything a horrible shade of green ;-))

• Be as transparent as possible about your design process. As several others have mentioned, one danger during the prototyping process is that the client will somehow start thinking that the prototype is the same as the final product. In the example above, my colleague didn't focus on maintainability of the codebase or anything like that - he just hacked it together for the specific use case he was designing for. But because he communicated his design process well with the client, explaining each step of the way what was happening and underlining the fact that none of this was final, the client was able to understand what they were getting. It's an important pitfall to avoid, but good expectation management can do a pretty good job.

• Document what you're doing and why. An interactive prototype isn't enough. You need to present it in a way the client will be able to understand - not only the product owner you're working directly with, but all the stakeholders up the chain who won't have been involved in the design process. My colleague created a miniature website presenting aspects of the screens he'd worked on, and wrote simple code to highlight various parts of how things worked. This metadata was invaluable in making sure that as the prototype deliverable was passed around within the organisation upon completion, wires didn't get crossed or confused.

So, best practies for interactive prototype deliverables? Honestly, it's all about good communication and expectation management. You need to figure out what the client expects to see. Once you've done that, the hard part is behind you - now you can go forth and do your design work!

---

PS. Not to plug our product, but my colleague used it during this process and a lot of advantages of the tool came to light. For instance, the fact that all our prototypes are instantly shareable online made it a snap to keep the client updated on progress and we could even walk the client through things over the phone. That was a big improvement over old situations where clients either had to be at our offices or they couldn't see what was going on.

Answer 4

I tried Axure and a few other tools to make prototypes and came to the conclusion that prototypes were an utter waste of time with a terrible ROI. I went back to a much more successful method, using PowerPoint to make storybaords.

I use the slide master to paste a vanilla blank of my app..the skin as wallpaper. Then I have a few controls saved on a final slide, like combo boxes and such. Finally, I have a picture of a cursor that I animate to show where the user would click.

Vry fast, very easy, everyone has the ability to open it and modify it. And best of all, it communicates the design vision very clearly.

I hope this helps.

Answer 5

The answer might also depend on what kind of prototype you were trying to deliver. If it was just for one (static) web page, you would be left with many options e.g. design tools such as Photoshop or Illustrator, and even hand-drawn sketches. For a more complete / complex story that might include multiple-state web pages, user flows, and/or customized user interface, I typically use a combination of Balsamiq, PowerPoint, and Word.

1. Balsamiq to create the mockups.
2. PowerPoint to compile the mockups and/or screenshots; and add callouts to add necessary details. This is very useful esp. when illustrating about flow.
3. Word (or any word processor) to document the more thorough background and design decisions. From my experience working with several great product people and designers, I find this a good habit to develop because we often can't remember about what we had decided in great detail.

I know that the question was more about finding the effective tools but, IMHO, nothing beats the chance when you can talk through your design decisions in person (or, can be via virtual means too).

Answer 6

"Which deliverables are important for the client to see and how far do you develop them? "

A deliverable that fully communicates the interaction and intent of the UI is important. You develop it as far as you need to to accomplish that. The specifics of that answer are entirely dependent on the project and the client.

As an aside, this is what Agile development tries to help with. The idea is that you get 'touchable' deliverable to clients faster so that the inevitable tweaking happens sooner than later.

Answer 7

I'd use Balsamiq www.balsamiq.com or Mockingbird gomockingbird.com for rapid prototyping. If you're required to provide a more detailed interaction plan, go for Axure.

I've had pretty good results with combining artworked designs (in Photoshop) and Axure to produce a very realistic demo, to sell design ideas in to (more senior) stakeholders who don't have the ability / desire to interpret wireframes.

Answer 8

As others have indicated, it depends on what is being reviewed. If like Balsamiq mockups for getting structure and interaction down. Balsamiqs imagery does a good job of conveying what the mockup is (a proposed structure) and is not (a design comp), and let's you focus on structure over graphic design. It's only after that part is done that I move on to visual design, and if the structure is already agreed upon, you can use flat files for the design approvals. What you really want to avoid is getting into a discussion about the proper shade of green to use when you haven't yet decided how the application should work.

Answer 9

To recap:

Best practices for interactive prototypes

• Show the flow between screens
• Keep the UI unrefined to set expectations that the application is not completed and invite feedback.
• Use Agile methodology and provide multiple iterations to the client to work out design problems before coding starts
• Complete the UI and annotations only to the level of completeness that the client needs to understand the interaction; Level of completeness will vary by client

These are my major takeaways. Anyone with anything else to add?