Category Archives: prototyping

If anyone has used Axure for prototyping, I’d be interested in hearing about your experience. I’m particularly interested in the ability to use a library of templates (like protokit) as a base.

Luke Wroblewski discusses the benefits and drawbacks of “mockups” (or we could assume “prototypes” as well) in his latest article on UX Matters, Live by the Mockup, Die by the Mockup. The article is a nice summary of ideas many of us have been discussing about the benefits and drawbacks of prototyping. But his conclusion is great, tying these ideas back to the real role of the UI designer:

When interface designers focus too much on mockups rather than product solutions, the design profession may suffer. This type of dilemma already exists for visual designers, who are routinely called upon just to “make things pretty.â€? As a result, every interface designer should focus on building a reputation as a problem solver and communicating that through the language of design and business. The presentation medium will change, the need to solve problems will not.

I often use this quote from Elizabeth Boling at Indiana University because it’s the most consice phrase I’ve found to dispell the too common misconception:

“Designer” does not mean “artist” — though lots of people want to think it does. The job of a designer is not self-expression, it’s problem solving. 

A powerful portfolio then for a UI designer/architect would include business problems with the designer’s solutions. I hope to have such a portfolio posted sometime soon.

Glenn passed along this link to a paper on a new technique for researching end-user functions for complex applications. Their focus seems to be on adding functionality to an existing complex application, but many of their findings support the need for the likes of protokit to develop rich prototypes quickly.

Unlike classic Wizard of Oz, Champagne Prototyping gives the user access to a rich interactive environment that genuinely can be executed on the computer—but the core feature of interest is not actually executable by the computer or even by the researcher. The rich executable context allows the user to interact with the system in order to understand the circumstances in which the new feature would be applied and the effects it will have, but finesses the fact that the feature itself has not been implemented.

Read the Champagne Prototyping: A Research Technique for Early Evaluation of Complex End-User Programming Systems by Alan Blackwell, Margaret Burnett, Simon Peyton Jones for more details.

Prototyping has been a popular topic on web-design blogs this year. Many designers and developers have shared how prototypes have helped them improve the quality of their deliverables from design through implementation. The best summary and introduction to the topic I have found so far was written by Henrik Olsen at GUUUI in his article “The promised land of prototypingâ€?.

Prototype is still an ambiguous term in the web-development community. A prototype could be a very rudimentary model created on paper. “Wireframesâ€? are also a popular approach to prototyping. Both of these methods focus on functionality and scope while ignoring the form, look and feel.

We use many kinds of prototypes often at Navigator. Our most successful stories usually involve a prototype that represents the final application user interface design—a “high-fidelityâ€? example of how the final application will look and behave. We represent every screen and most basic behaviors on each screen. The colors, fonts, and images all match the exact look and feel that we intend to implement.

There are numerous benefits of a high-fidelity prototype. The most obvious is an accurate representation of the final deliverable that all parties (clients, developers, project managers) can understand and use to set appropriate expectations.

While the benefits are numerous, there is a substantial cost for creating a “high-fidelityâ€? model that paper prototypes and wireframes do not require. Developing a framework of required code takes time (usually more time that the project plan allows).

Over the next few months, Aaron and I will be working on a “starter-kitâ€? for prototyping. The basic goal is to create a library of XHTML, javascript, and css pages that will enable designers and developers to skip the up-front investment in code can get right to producing screens that the client understands. Hopefully developers inside Navigator, at our clients, and elsewhere will find such a tool useful.

Introductory articles on prototyping from other places on the web are listed on the right. More in-depth articles and tools are listed in my del.icio.us prototyping links.

To follow our progress on the hi-fi prototype starter-kit, subscribe to the RSS feed for the my prototyping category.