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.
5 comments:
Isn't it nearly impossible to test the interaction design properly without editorial and visual design content being included completely as intented?
I mean, style and visuals as well as editorial content and interaction components and patterns make the complete interaction experience/UX. Leaving parts of the prototype in lower fidelity will allways effect the way people interact with it.
Put it in another way: when testing the interaction design with lower fidelity editorial and visual desgn content it will give you less clear or even a false insight in how the interaction design works (efficient, effective and the like).
This would suggest that you can only test the interaction design with complete high fidelity prototypes. Especially with the current persuasion techniques, small details in either level off the design make a huge difference in how the requirements or assumptions are met.
Nevertheless it is absolutely best to prototype as early as possible, without having every level of the design complete set out yet. My statement than is that you should be really carefull in how to interpret the results. A false assumption is made easily which leads to non converting designs what so ever.
How to overcome this? Leave it to the experts only? Do more prototype test iterations?
@Anoushchka, thanks for your post you make some great points. But these are points about prototyping strategy, how you wield the prototyping tool.
In general I agree with you but that is more a strategic question. In a previous post I mentioned how different prototyping aspects affect each other they are iterative not summative: one effects the other.
But the reality is you develop them incongruently and your prototyping practice needs to take that into consideration.
For example, if there is no visual design yet and you need to test your interaction design and say you will leave the project before the visual design in known, it is far worse to make up a visual design than to test interaction with as neutral or low a visual design fidelity as possible. Of course you still need to analyze the results based on your view of how visual design will or can augment your particular interaction design.
Ah Jonathan, thank you. Didn't read the previous post obviousely;-)
An other thing from this post than what has been bugging me a bit. What the prototype exists of, which layers/disciplines involved... I miss the concept design.
Don't know exactly how to pinpoint it but it is more than the interaction design, visual design, content design ...
Example: a design with a very user interactive and high visual experience versus for the same purpose/assignment a design in a complete opposite standard approach of inteactivity and visual experience.
Does this make any sense?
I think it's possible to isolate different aspects when prototyping - e.g. if the aim of a prototype is to test the navigation, then the overall structure and menus are more important than the visual design. Similarly if you're trying evaluate drag and drop vs some other solution, for instance.
This is not to say that visual design can't influence interaction design or navigation, or vice versa, only that you can still get meaningful results from something that's not 100% true to the intended final design. But I think that's what the section about fidelity in the post already says. :)
@Anouschka I would say the Conceptual design is one of many strategies you can apply to prototyping, but prototyping itself is a tool or rather a tactic that can be wielded for good or ill. About my views on conceptual design, you should see the earlier posts on UX Strategy (if that helps?).
Post a Comment