October 6, 2019
How do we determine the viability of our ideas? How do we visualize them? What do we need to make them? How do we implement them?
Unlike a natural gas line, the consequences from an improperly repaired water line (provided there is nearby shutoff valve) are minimal. Dry fitting the pipe and ensuring the needed measurements were taken and confirmed to match the original prior to sweating and installation ensured this repair did not flagrantly present incompetence. The above is an easily implementable physical prototype. It satisfied the primary criterion: fit. I could have simply sweated the pieces in place and subsequently having the risk of bending the pipe to fit in a hole with little clearance. If I time allowed, a paper drawing of the full installation would have been created. Physical systems are far easier than interactive systems to prototype. This weeks entry will discuss what one needs to effectively prototype.
Also will summarize:
Designers must understand what users can and cannot contribute. I've often observed the mistaken concept of sacrosanct requirements gathering. The BA spent 6 months with the users and we will now design the system. Few iterations occur and often, the delivery is delayed or someone highlights a glaring omission.
Design is not a natural science: the goal is not to describe and understand existing phenomena but to create something new. Ideas for the design space come from many sources: existing systems, other designs, other designers, external inspiration, and accidents that prompt new ideas. The process is iterative: more cyclic than reductionist.
Clever ideas, half-finished ideas, silly ideas, and impractical ideas all contribute to the richness of the design space and improve the quality of the final solution.
Exploring a design space is the process of moving back and forth between creativity and choice.
Prototypes require details.
Prototypes often make it easier to evaluate design ideas from the user’s perspective. They provide concrete representations that can be compared.
Prototypes help designers think: Prototypes can also be seen as artifacts for design, as an integral part of the design process.
Prototypes reveal the strengths as well as the weaknesses of a design.
Prototypes, because they are concrete and not abstract, provide a rich medium for exploring a design space.
Fallacy: programmers believe it will be faster and more useful to write code than to “waste time” creating paper prototypes. Off line prototypes are easy to create and do not constrain how designers think.
Prototypes force designers to show the interaction: just how does the user open the file and what are the specific results that appear on the screen?
Online prototypes introduce an intermediary between the idea and the implementation, slowing down the design cycle.
storyboard or cardboard mock up requires no particular technical
skill. This is a very salient point as it allows other stakeholders to successfully contribute to the design of the product.
Prototyping is an iterative process and all prototypes provide information about some aspects while ignoring others.
Although it may seem contradictory, a detailed representation need not be precise.
The level of precision usually increases as successive prototypes are developed and more and more details are set.
What the prototype states is subject to evaluation; what the prototype leaves open is subject to more discussion and design space exploration.
Rapid prototypes be they on-line or off-line, are especially important in the early stages of design.
Prototypes can be represented across four dimensions:
- Representation describes the form of the prototype, such as sets of paper sketches or computer simulations;
- Precision describes the level of detail at which the prototype is to be evaluated, such as informal and rough or highly polished.
- Interactivity describes the extent to which the user can actually interact with the prototype, such as “watch only” or fully interactive.
- Evolution describes the expected life cycle of the prototype, such as throwaway or iterative.
Interactivity and precision are orthogonal dimensions.
Unfortunately, designing effective interaction is difficult: many interactive systems (including many websites) have a good look but a poor feel.
A critical role for an interactive system prototype is to illustrate how the user will interact with the system.
Wizard of Oz Prototyping:
An interactive prototype that has a human actor or some other subsystem providing some functionality components that cannot easily be implemented with the existing prototype.
Fixed prototypes are often used to illustrate or test scenarios.
Open prototypes support large sets of interactions. Such
prototypes work like the real system, with some limitations.
They usually cover only part of the system (see vertical prototypes)
and often have limited error handling or reduced performance
relative to that of the final system. Open prototypes allow
designers and users to explore a wide range of possible forms of interaction with the system.
User-centered design places the user at the center of the design process, from the initial analysis of user requirements to testing and evaluation. Prototypes support this goal by allowing users see and experience the final system long before it is built.
Users are not simply consulted at the beginning and called in to evaluate the system at the end; they are treated as partners throughout.
A common misconception about participatory design is that designers are expected to abdicate their responsibilities as designers, leaving the design to the end user. In fact, the goal is for designers and users to work together, each contributing their strengths to clarify the design problem as well as explore design solutions.
Brainstorm in a group: the quantity of ideas is not the only important measure: the relationships among members of the group are also important.
Brainstorming is an important group-building exercise for participatory design.
Designers must stop and reflect upon the choices available to them.
Good scenarios involve more than a string of independent tasks; they should incorporate real-world activities, including common or repeated tasks, successful activities, breakdowns, and errors, with both typical and unusual events. The designer then creates a prototype that simulates or implements the aspects of the system necessary to illustrate each set of design alternatives.
Vertical prototypes: Vertical prototypes are often built to assess the feasibility of a feature described in a horizontal, task oriented, or scenario-based prototype. Vertical prototypes are generally high precision software prototypes because their goals are to validate ideas at the system level.
Task oriented prototypes: Task-based prototypes are organized as a series of tasks, which allows both designers and users to test each task independently, systematically working through the entire system. Task-oriented prototypes include only the functions necessary to implement the specified set of tasks.
Scenario based prototypes: Scenario-based prototypes are similar to task-oriented ones, except that they do not stress individual, independent tasks, but rather follow a more realistic scenario of how the system would be used in a real-world setting.
- Paper and pencil
- Mock ups
- Wizard of Oz
- Video Prototyping
- Non interactive simulations
- Interactive Simulations
- Scripting Languages
User interactive Toolkits:
One limitation of widgets is that their behaviors are limited to the widget itself. Interaction techniques that involve multiple widgets, such as drag-and-drop, cannot be supported by the widgets’ behaviors alone and require separate support in the UI toolkit. Creating an application or a prototype with a UI toolkit requires solid knowledge of the toolkit and experience with programming interactive applications.
A fair number of ideas mentioned above are mentioned in Li's paper See the mockup example: This was written when the HP iPAQ was the most performant pda and the need for prototyping software was essential to quick delivery. Most of the techniques used in the paper are applicable to modern iOS or Android delvelpment.
- We spent two months iterating on paper prototypes, getting feedback from researchers familiar with location-enhanced applications and prototyping tools.