AP UX Week '07: Sketching in Code: Using Prototypes to Visualize Interactions
[Live blogged from Adaptive Path UX Week 2007. Sketching in Code: Using Prototypes to Visualize Interactions by David Verba ]
With the Measure Map project they were able to build working prototypes right away. This enabled them to rapidly iterate with functional pieces.
An engineer should never be more than a stones throw away from a physical product. Kelly Johnson, Lockheed Skunk Works
A design/development process should never be more than a stones throw away from a working prototype. David Verba
Sketches
From rough to detailed engineering graphics. Designers use this to deliberate effect. Developers can do the same thing. They start with a rough code outline and sketch as they work away in code.
Advances in the last few years have made this easier. Two developers in an afternoon can produce profound results.
For the context of this session we are talking about interactive screen based prototypes.
Low fidelity or high fidelity.
Why prototype?
Wireframes just don't cut it any more. As we build more Ajax applications, wireframes can't document this.
It is cheaper to build prototypes than to design wireframes and pass them around. You are trying to figure out why things don't work in the wrong medium. This is expensive.
The goal of the process isn't to produce perfect documentation, it is to build a rapid working prototype.
Prototypes can contain the magic, the emotion, of the real thing. A wireframe just can't give this to you.
Where can we prototype?
- Exploration into divergent ideas.
- Collaboration & development. See what you are building come to life every day.
- Deliverable. Give your working prototype to your client for them to build out.
Who is the audience for a prototype?
The design team can work around a prototype with the development team. But there are other audiences too.
Internal stake-holders and users can also see in prototypes the character of the application and give useful feedback.
Advantages
Prototypes let you see problems clearly right now. You don't see things coming down the road that you can't do anything about. Instead you make them happen right now and deal with them. Prototype the issue and the solution to keep evolving your project.
Reveal problems that typically don't emerge until much later. Prototyping helps you avoid being blind-sided.
Prototypes can get you buy-in from stake-holders. Show how it works now and then show how it should work.
Use prototypes to foster collaboration between disparate groups. The traditional divide between designers and developers is unhelpful. Building working prototypes breaks down these barriers.
This all helps everyone understand the whole project and what is possible.
Challenges
If you don't have access to front-end and back-end developers that will limit your approach. It is not a deal-breaker.
Low-fi is hard to sell. No matter how functional it is, people don't understand why is looks like that. Hi-fi is hard because people ask about the wrong details. Sketch for what you are trying solve.
Think about the amount of effort and resource you are going to put into polishing your prototype.
Annotation is difficult, you have to be careful not to lose the history of the application and the decisions you've made. Map this out the best you can.
Solve the right problems. Don't waste time setting up your prototyping framework. Focussing on the prototyping methodology misses the point. Just get started, grab a pencil and go.
Techniques
HTML and javascript are a great way to get started. Build simple click-through prototypes. Think about Tiddly-wiki. You can do amazing stuff with HTMl and Javascipt. You do need a front-end developer to help with this.
This can be hard when you need to be modeling a large amount of data. Use JSON and XML on top of your HTML/JS prototype.
MVC frameworks (Rails, Django, and catalyst) are great for prototyping. These allow you to build web applications very very quickly with code that you can use in production.
Flash and flex are very useful for rendering rich interactive interfaces in prototypes. We are not talking about overly animated interfaces. This is a question of discipline to model what you actually want to build.
Open Laszlo is another framework. It is a widget framework. There are drawbacks because of a limited number of interactions you can model. It is easy to visually style and can easily point to XML data sources. You don't have to be a front-end developer to learn it. The biggest downside to this is that your code will not be reusable. It is a pure prototyping framework.
Aure and Irise are also out there but they are PC only and they are very expensive. However, people that use these in corporate environments tend to like them. You can drag and drop interactive elements to build a prototype. These frameworks also generate documentation.
Closing thoughts
So what about the distinction between prototyping and agile development. If you can get to a working application early on it can keep everyone focussed. You see the impact of your decisions right away. This is THE best approach.
There isn't one monolithic approach to this, so just play with the tools.
What do you do to get started? Start asking about the resources you already have. Do you have access to front-end developers? Feel free to start small and build from there. Model a page or two and see how that goes. Get buy in and pull in resources from outside your immediate environment.
0 TrackBacks
Listed below are links to blogs that reference this entry: AP UX Week '07: Sketching in Code: Using Prototypes to Visualize Interactions.
TrackBack URL for this entry: http://www.samfelder.com/mt/mt-tb.cgi/310
Who is this guy?
Leave a comment