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.

I'm getting a lot of answers about prototyping software but my main focus is on the best practices for interactive deliverables. I think which software is used for creating the prototypes is irrelevant when it comes to "best practices". Software is just a tool. The only reason I mentioned Axure is because it provides click-able demos which elevates it above Viseo in my opinion.
–
JK HudsonDec 6 '10 at 5:01

This makes the most sense of what I've heard so far. Interactive prototypes are necessary to show flow in a way that static screens can't. Now I have something I can sink my teeth into that's for the customer's benefit. Thanks!
–
JK HudsonDec 7 '10 at 5:32

1

@JK Hudson This answer seems to answer a different question, namely of what the purpose of prototyping is. Perhaps you should change the title of your question to something like "What purposes do prototypes have?" as opposed to asking about deliverables?
–
Rahul♦Dec 7 '10 at 8:58

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)

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.

+1 This is far closer to a list of best practices (as requested) than the accepted answer. You didn't plug your product because you didn't even mention quplo.com at all. But I just did! ^^
–
Bernhard HofmannDec 7 '10 at 11:11

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.

Would you be willing (and able) to share an example of such a PowerPoint file? I am a developer who is just getting her feet wet with mock ups and prototypes. Most approaches for this feel like overkill for what I want to do, and your method sounds like a much better fit for my needs...
–
Marjan VenemaDec 2 '10 at 7:34

Yes, i just have to remember when I am at my desk. :)
–
Glen LipkaDec 3 '10 at 21:06

1

commadot.com/public/sample.pptx - This is a 3 year old doc, with an early rev of our product. Originally it was 50 slides, but I trimmed it to just a few to demonstrate the method. Hope its helpful. :)
–
Glen LipkaDec 4 '10 at 1:34

I understand your frustration with Axure. It seems very labor intensive to me. Why doesn't it support imported CSS is a complete mystery to me. I could actually create the interface in HTML and CSS faster. The annotations and specs seem to be more useful to the development team than the customer/stakeholder.
–
JK HudsonDec 6 '10 at 5:09

1

I wish people with negative votes would say why
–
Glen LipkaDec 9 '10 at 15:22

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.

Balsamiq to create the mockups.

PowerPoint to compile the mockups and/or screenshots; and add callouts to add necessary details. This is very useful esp. when illustrating about flow.

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).

Actually my question is more about deliverables and not software. Why do you use PowerPoint to compile the mockups? Why not use the Balsamiq prototype?
–
JK HudsonDec 2 '10 at 16:41

I find that PowerPoint is useful and easy to use when I want to add some colorful callouts and need to communicate about user flow (you get a sense of backward / forward motion when you navigate through the slides). Colors are useful as complements to the mostly black-and-white Balsamiq prototype.
–
moeyDec 2 '10 at 17:45

SikuSikuCom, I'm redesigning a 12 year old Powerbuilder application from the ground up. The application flow and the ui will be completely changed to take advantage of a more powerful back-end. I need to convey to the customer/end-user that they can still accomplish all their tasks without all the manual hoops they've been doing for the past 12 years.
–
JK HudsonDec 6 '10 at 5:13

"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.

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.

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.