Prototyping 3: What is a prototype, part 2 other dimensions

In Part 1 of what is a prototype we discussed many dimensions of what a prototype is, but this covers only part of the story, actually half there are many more layers of complexity and if you do not understand them, instead of controlling a prototype, the prototype will control you or worse victimize you. So let’s begin with some prototyping characteristics, for lack of a better term.

Prototyping characteristics

Prototypes have many more important characteristics than just content and fidelity. Knowing what these characteristics are will also help you plan and execute the prototype to the right level of effort. Too numerous to name them all here, here are just a few examples:
Longevity -- what is the lifecycle of the prototype. Is it something to be presented and thrown away, or is it part of an evolutionary prototyping design cycle? How long a prototype will continue to haunt you, should effect how much effort you are willing to put into it.
Stage -- what stage of development is the product? Usually, the more mature the more detailed the prototype should be.
Speed -- how much time do you have? If you have one week, it probably isn’t enough time to make as thorough a prototype as you would like, you may have to adjust your content-fidelity ambitions based on how fast you must work.
Style -- will the prototype be narrative (e.g. demo’d) or interactive (e.g. used). Interactive prototypes are more difficult and time consuming than narrative ones.
Medium -- will the prototype be in a digital media or physical, if digital will it be on the web, mobile or a desktop application, etc.
Being aware of the characteristics of a prototype, empower you to make much more professional judgement as to what kind of prototype you can make.

Defined audience (s)

Audience -- who is the the prototype for? Unlike the end product which is meant for an end user a prototype is meant for certain stakeholders, which may or may not include end users. The prototype should be designed to communicate clearly with the stakeholders. For example, this usually means that a prototype meant for the CEO of the company, will probably look different than a prototype meant for a domain expert

Prototyping tool(s)

Prototyping tools are like tools of the trade, the more you know the better. Likewise for many the simplest software tools suffice for most purposes.
There is no one single prototyping tool that can do everything. Prototyping tools are as varied as there are types of prototypes. Prototypes can just as easily be made in Excel, Powerpoint, Visio, even Word as they can be made in Axure, Dreamweaver, Visual Studio etc.
The point is to match 2 things: First, match the prototyping characteristics with the right toolset. Secondly, of those tools, use the tools you know best. Chances are, your talents in software you know well will outstrip the added functionality of other software tools.
Personally, I no longer use a single tool, but quickly jump between Graphics editors, html editors, scripting tools, layout tools, and yes the occasional prototyping tool.
...but having said that there are some types of tools

• dedicated prototyping tools
  
• Programming tools with prototyping capabilities
  
• graphical tools
  
• layout tools
  
• presentation tools
  

Dedicated prototyping tools, tools that are only for the creation of prototypes not working software or any other purpose. Examples:

• Axure
  
• Denim
  
• Balsamiq
  

Programming tools with prototyping capabilities -- tools that can create full functioning software, but due to their efficient interfaces can allow users to also create prototypes. The theory, or rather myth is if a designer uses one of these tools, a programmer can take over the design and implement it without recreating it. This is rarely true as the html code, or programming code used by a designer (focusing on visualizing something) is completely different in nature to that of a programmer (focusing on implementing something). Examples:

• Dreamweaver
  
• Visual studio
  
• Flash
  

Graphical tools -- tools that help you create the visuals of an interface, ideal for wireframes. Sometimes these tools can also mimic interaction making them suitable for a variety of prototypes. Examples:

• Photoshop
  
• Fireworks
  
• Paintshop pro
  

Layout tools -- tools that help you layout content. Sometimes these tools include interactivity such as hyperlinks or programming scripts that help create a variety of prototypes.

• Word
  
• Pages
  
• Excel
  
• Numbers
  
• Visio
  

Presentation tools -- tools that have some built in narrative capabilities that make it particularly (though not exclusively) suited for narrative prototypes.

• Powerpoint
  
• Keynote
  
• Acrobat
  

Method

Prototyping is much more than just wireframes or a ‘dumbed down’ version of real software. The Methods are many, and in addition to the methods below, there are all sorts of hybrid methods which combine features of other methods. Just to give you a flavor here are some examples of some of my favorite methods:

• Wireframe Prototyping -- A wireframe is a narrative prototype, usually created in the beginning of the design process. This prototype shows high-level sketches, visualizing conceptual assumptions about the product structure and general interaction.


• Storyboard Prototyping -- A storyboard is a narrative prototype, usually created in the early stages of the software-making process to articulate business and marketing requirements in the form of a usage scenario or story. These stories narrate the user actions needed to perform tasks as specified by marketplace, customer, and user requirements.


• Paper Prototyping -- A paper prototype is an interactive prototype that consists of a paper mockup of the user interface. The interface is usually fully functional, even if all the functionality is mocked up on paper. Paper prototypes allow you to test a design with many different stakeholders, including end users.


• Digital Prototyping -- A digital prototype is an interactive prototype that consists of a digital mockup of the user interface. The interface is usually partially functional, even if the functionality is implemented by hyperlinking, screen switching and other methods of mocking up actual interaction. Digital prototypes like paper prototypes allow you to test a design with many different stakeholders, including end users. Unlike paper prototypes, digital prototypes can be tested remotely.


• Blank Model Prototyping -- Blank models are low-fidelity prototypes produced quickly by user study participants using readily available arts and crafts materials to represent their notions about what an intended hardware/software design could be like. This method is used in the early stages of product design to elicit user perceptions and mental models about hardware form factors and interaction controls in conjunction with a software user interface.

And with the prototyping methods that covers the definition of a prototype. Now was that so painful? Now you understand at least to some degree the richness of prototyping. Instead of being victimized by these dimensions you should be wielding them like a weapon. So hopefully know you can understand the basic concepts of effective prototyping: that a prototype is:

• purpose
  
• content
  
• content fidelity
  
• requirements and assumption
  
• prototyping characteristics
  
• defined audience (s)
  
• toolset
  
• method
  

If any of these concepts are still not clear, I can discuss them in subsequent postings. Next week I will discuss the so-called benefits of prototyping, which probably could better be labelled: the myths of prototyping.

Prototyping 2: What is a prototype, part 1

In my last post I discussed what a prototype does. Now here comes a far trickier question: what is a prototype. A prototype turns out to be quite complex, and rightly so. Because to get the benefits of prototyping (the subject of my next post), a prototyper must understand these vital concepts, otherwise you are just shooting arrow into the air.

A prototype is deservedly complex since it is by definition the coming together of many different disciplines. Whether you like it or not every prototype has an either implied or explicit:

• visual design
  
• interaction design
  
• technical implementation
  
• information design
  
• editorial content
  
• and my personal favorite: a reason to exist

But those are all vague terms and do not really help you get control of your prototype. And getting control is the point of the definition of a prototype that I want to discuss. This definition will provide you with everything you need to control your prototype, so it does not control you. Likewise, for you non-prototypers, this will also give you enough information to fight what I call the razzle-dazzle effect: a prototyper who over-delivers a slick prototype and uses the wow factor to cover up a paucity of good ideas.

To begin, we need a prototype definition that covers what are the parts that make up a prototype and not what a prototype does (that was covered in the last post).

The Effective Prototyping definition of a prototype

A prototype is a model of a design that is:

• utilized for a specific planned purpose
  
• illustrating specific content and fidelity
  
• articulating defined requirements and assumption
  
• specified with prototyping characteristics
  
• customized for a specific audience(s)
  
• created with a specific tool
  
• performed in a specific method

Here is a less verbose but more specific version of the same definition:
A prototype is a model of a design with:

• purpose
  
• content
  
• content fidelity
  
• requirements and assumption
  
• prototyping characteristics
  
• defined audience (s)
  
• toolset
  
• method

Below we will discuss them briefly, for more thorough details, you can always consult the full book, Effective Prototyping for Software Makers .

Purpose

A prototype will be created for a specific purpose. Whether it is a proof of concept, or a demonstration of a product’s interaction or a visual direction, it is important to know what the purpose(s) is (are).

Content

Based on what the purpose of the prototype is, you will want to prioritize the content in the prototype.
A prototype consists chiefly of 4 different types of content:

• Interaction -- how a user will interact with it
  
• Visual design -- how the prototype will visually appear
  
• Editorial content -- what information will be on the prototype
  
• Information Design/Architecture -- what will be the structure of the information

Fidelity

Generally, only in late stages do you want the content all at a high fidelity. Consequently, a prototyper will strategically set the fidelity of any given content higher or lower depending on what they want the prototype to focus on. The higher the fidelity, the more prominent the content. The lower the fidelity, the more the content will fade into the background.
Setting the wrong level of fidelity is the most common error. It results in discussions getting bogged down on visual design, when in fact the interaction design was the only intended goal of the prototype.
Contrary to what most prototyping texts state you can play with fidelity within a content type. For example you can raise the fidelity on the visual design for the chrome of an application and lower the fidelity of the content in order to discuss the visual structure of a given. You can also de-emphasize a content type completely, for example by showing all text in greeked text format you for your audience to concentrate on the visuals or interactions instead of trying to read editorial content which usually grabs their attention.
However, the issue is more nuanced than it appears. For example, let’s say you want to test the interaction design. Then, if you set the visual design level to lowest and editorial content to lowest fidelity, it will be impossible to really test the interaction: you need just enough editorial and visual design content to test the interaction. Likewise, say for example, the visual design is already finished and agreed on by stakeholders, then there is no real reason not to use a high fidelity visual design.
In general, the rule is, lower the fidelity of the content you are both less sure of and do not want to evaluate. At any rate a professional prototyper should be able to justify their choices.

requirements and assumption

The whole point of a prototype, when used as part of a digital product or service creation process is to validate requirements, or rather separate the requirements from the assumptions. Requirements are some function or feature that is necessary for the success of the product or service. An assumption is something that is presupposed to be a requirement, but has never actually been proven or tested. A prototype usually consists of proven requirements, requirements to be validated in the current iteration and assumptions. In general, the higher the assumptions the more risky a prototype is. Whether something is a requirement or an assumption will help prioritize content and set its fidelity.
I see know the post is over 1,000 words, so let’s stop here and resume with prototyping characteristics next week.

Prototyping 1: What does a prototype do

A series on prototyping
In the 4 years since our book on prototyping first came on the scene there was precious little written about the professional way to prototype. Today prototyping seems to be the hot topic, unfortunately most of the current stuff available on the internet only give an isolated tip or trick. What is especially harmful is that most of these articles rush into how to prototype without really understanding what it is. These works are rife with unquestioned assumptions and and uncritical approach to prototyping.

The book I co-wrote with Michael Arent and Nevin Berger remains still the only thorough attempt to understand prototyping. In the coming series of posts on prototyping, I want to make a compact discussion of what a prototype is and how it works from our book Effective Prototyping for Software Makers . This post will it a little more approachable and if you want the full details, by all means you can buy the book

In this series of posts I want to address 3 broad topics:

1. What does a prototype do
2. What is a prototype
3. Raising the bar in prototyping

In this first post I want to discuss what a prototype does. For that I want to use a definition of prototyping that restricts itself to what it does not what it is. For that I turn to a definition from the book “Universal Design Principles” by William Lidwell and others:

A prototype is “The use of simplified and incomplete models of a design to explore ideas, elaborate requirements, refine specifications, and test functionality.”

For ease of discussion, I will break this definition down into its components. First, I will throw out the models business because that goes into what a prototype is, which will be the subject of the next post. That leaves us with the following uses of a prototype:

• to explore ideas
• to elaborate requirements
• to refine specifications
• to test functionality

All prototypes attempt to do at least one of the above purposes and usually more than one simultaneously, often without the prototyper even being aware of it. What is essential to know is that the prototype is first and foremost a communication medium. A prototype communicates the above 4 concepts.

Explores ideas

Here the accent is on if the idea is desirable. Prototypes are at their best when they explore abstract concepts or ideas and makes them concrete. It is easy enough for a group of technocrats to discuss their new idea for a killer document registration, yet being able to both rapidly and interactively visualize with a prototype makes the idea come alive and often inspires and informs the whole ideation process. Any software idea can be visualized with a prototype. But here are just a few examples (a fuller list comes in a future post discussing prototyping content):

• Interactions design
• Application functionality
• Visual design
• Information design/architecture
• Rough concepts and ideas

Among the many means of using prototyping to explore are:

• a single prototyper visualizes the idea
• a group prototypes through participatory design practices
• members of a group each sketch out their ideas as a group
• a group brainstorms a prototype with a designer as facilitator

Elaborates requirements

Here the accent is on, whether the prototype is possible. A prototype elaborates requirements by often illustrating what is necessary to actually put an idea into action. For example, and idea of having a running total in web interface when illustrated will make a developer realizes they need Web 2.0 technology. Or it could make the business analyst realize that discounts or other items that effect the total also need to be known upfront or somehow communicated to the end user. Once an idea is explored, software makers often look at a prototype differently. Among the types of requirements that are elaborated by a prototype include:

• Business
• Organizational
• Functional
• Technical
• End user

Refines specifications

Here the accent is on, whether the prototype is feasible and if so how. One the idea is desirable and deemed possible, then the detailed design comes in. A prototype is often a superior form of specification than a large paper document with lots of verbiage where the requirements are difficult to ascertain let alone visualize. Furthermore, the prototype speaks in the visual language of the product itself and cross cultural and language concerns are not so big an issue with today’s global development teams.
A prototype can be stand alone documentation if it is a totally complete model. Otherwise, often some form of annotation or some lightweight document is needed to accompany it.

Tests functionality

Here the accent is on evaluattion, for example whether the prototyped design is usable for the end user.
A working prototype (paper, digital or whatever form) can be shown to stakeholders and they can test it to see if they can work with it. If it works the way it should or they way it needs to. This way corrections to the design will cost no redevelopment costs.

Summary

So in a nutshell, this covers what a prototype does. In essence it communicates four things:

1. to explore ideas -- is it desirable?
2. to elaborate requirements -- is it possible?
3. to refine specifications -- how do we do it?
4. to test functionality -- does it work?

How and what it communicates will be discussed in my next post on what a prototype is. In that post I will discuss the characteristic parts of a prototype. Understanding these characteristic parts allows you to control how your prototype will come across to your audience.

UX Strategy III: The UX Declaration of Independence from Engineering

(Co-written by Thomas Jefferson, I hope my non-American friends will indulge an American metaphor of the declaration of independence.)

When in the course of human events, it becomes necessary for one profession (UXD) to dissolve the bonds which have connected them with another profession (Software Engineering), and to assume their own powers, separate and equal from other professions to which the Laws of Nature entitle them. A decent respect to the opinions of software engineering requires that User Experience should declare the causes which impel them to the separation.

We hold these truths to be self-evident, that all products are endowed by their creators with user experiences with certain unalienable Rights, that among these are usability, satisfaction, and business feasibility. Furthermore the user has a right to a user experience which is derived from the entire company/organization not just what is technically feasible at a given moment.

That to secure these rights, User Experience professionals are engaged by companies and businesses. These professionals derive their just powers from a professional integrity that must not be compromised, otherwise the User Experience design loses whatever rights they have to exist.

Software Engineering as a process has had a tyrannical effect on the User Experience professional, forcing them to shorter and shorter deadlines with less and less available resources that the point is reached that UX Professionals often find themselves going through motions rather than truly designing professional products the way they are truly capable of creating them.

The history of Software Engineering processes are a history of repeated injuries and usurpations of UX terrain, all having in direct effect the establishment of an absolute Tyranny over this profession. To prove this, let Facts be submitted to a candid world:

• Development methods are continually shortening their design process and their delivery deadlines


• This makes it impossible to do a thorough and adequate design process, forcing us to take all kinds of irresponsible and inappropriate short cuts.
• Specifically, Agile development processes attempt to preclude any upfront design or research as good UX processes demand
• Development do not use UX metrics as a measure for their success
• Consequently there is no business case for following UX best practices
• Development keeps the UX bar purposefully low so that UX accountability is
• non-existent -- even when it is clear that products are failing because of their poor user experiences
• an afterthought -- the product is a success or failure and after the fact UX is blamed or ignored
• an anecdote -- the arbitrary story or urban legend of use becomes definitional for the user experience
• unprofessional -- as long as the bar is low, poor UX design will yield equal results making the establishment of UX best practices very difficult
• Development’s near fetish-like fascination with a release puts artificial blinders on the UX processes, resulting in:
• assuring structurally sub-optimal results
• cutting corners when it really is not necessary
• giving undue credence to an artificial argument against UX additional processes
• obscuring the value of user experience design by forcing it into the release focus of software engineering.
• UX quality is now reliant on the kindness of strangers, that will say the extent to which a Software Engineering team is or is not enlightened to the value and processes of User Experience Design.

We, therefore, the Representatives of the united User Experience Designers hold that instead of working under the hegemony of engineering, User Experience activities should work in coordination, not in tandem with Software Engineering.

Among the ongoing process which User Experience should be working on independent of Software Engineering include (partial list for the longer list of UX processes see the previous post in this blog):

• User Research
• Design Research
• Requirements gathering (SE’s are needed for technical requirements but that is only one part of the whole requirements picture
• Product design
• Conceptual design which may cover multiple products/channels and multiple releases.

Places where software engineers and user experience should closely together is

• translating a conceptual design to a specific product release cycle
• product definition
• product detailed design
• product design reviews and iterations
• mentoring developers through a product release
• evaluating software engineer work for fidelity to UX concept using appropriate UX metrics
• release planning

Software engineering in turn should act as mentors in the UX processes assuring technical feasibility for short and medium term are tracked and noted. In this way Software Engineering, Product Management and User Experience are truly equal partners in the creation of great products and product experiences.

Signed 2 March 2010