Prototyping: input & output

"Prototyping translates findings from formative work into concrete designs that can be tested, revised and refined prior to implementation of the final system."

Basically it's taking everything we've learned from our research bringing it together to build a proof of concept, the prototype doesn't have to be a fully working end to end solution but one or a series of targeted POC's that can be shared and played with. The idea is to collect more information get more feedback and use that high value data to improve the solution.

Prototypes do not even have to be coded, they can be made of paper or a series of screens they are a medium to convey a more refined concept than just wires or screens.

When designing a system we can really think of our solutions as something that process input into output, input being what we provide to the system, output being what the system provides to us; there are other factors like data retention, but for simplicity sake let's focus on Input->Process->Output.

"Input: Data that needs to be entered into the program to enable it to perform a desired tasks"

As designers we need to understand what data needs to be entered into the system and what the most effective way to enter that data is. There are two basic types of data

• User defined input: input that is directly entered by the user via, textboxs, buttons, menus, date pickers, voice input, file upload, etc . input that is actively entered via UI controls.
• Passive data: input from background sensors such as location services, accelerometer, fitbit, picture library, rss readers, anything the user doesn't actively enter but is available.

When performing interaction design there are some basic questions that need to be asked

1. What is the granularity of data input that is required? 
• Do you really need first name, middle name, last name, or would just name suffice.
2. When and how often is the data needed?
• Ask for the minimum amount of input upfront then passively or progressively collect subsequent user input.
3. What is the state of the user when the data is required, is the user driving? eating? in a distracting environment? sitting in front of a computer on their lunch break? 
• the users state is key in deciding what kind of inputs are going to be effective
4. What is the value vs burden relationship of obtaining the data?
• Will the user be willing to supply the input to receive the output, if all i want is to know the exchange rate of Swiss francs to US dollars, am i willing to input more then just the value to be converted? how much battery life must we drain? what are the privacy implications? is the user willing to pay the battery life or privacy cost

Effective interaction design is fundamental to successful technology design, if users can't or aren't willing to provide the input required for the system it will fail. It is important to strike a balance between the effort to supply input and the value of the output.

Output is the information that the system presents to the user once it has processed the user's input. it can broadly be defined as:

"Output: Information that the system presents to the user in order to accomplish its intended function"

Output is made up of:

• Structure: The format in which information is presented to the user.
• Content:What information is presented to the user. 

when the output is presented to the user there are considerations that must be taken into account to best decide what structure to utilize when presenting the output to the user.

1. What exactly does the user need to know to perform the task?
• What is the user trying to accomplish, what information does the solution provide to support the user's needs.
2. When/how often will the user interact with the information?
• Does the user need the information weekly? daily? hourly? 
3. In what state will the user be when presented with the output data?
• will the user be driving? sitting at a computer? working in the field?
4. What is the users current knowledge base?
• Does the user have the expertise to understand the output.

Pull vs push content

Traditionally when users interact with a system they are presented with pull content, that is content that they request and are supplied with. However push content is delivered to the user based on predefined rules, the user receives the content when the system is programmed to provide it; this content needs to be simple and unobtrusive.

UX design involves designing inputs, outputs and the rules that translate the inputs into value added output for the user. When, where, and how the user will interact with both the inputs and outputs of a system must be considered for successful interaction design. The system must also convey why the solution is behaving the way it is, the user should know what value their input is providing; users' are far more likely to provide input or allow access to input if they see the value it will produce for them.

Prototyping

"Interaction design prototype is a representation of a design, made before the final solution exists"

the reason behind prototyping is that even after all of the formative work during UX research and creation of personas, wireframs, scenarios, and storyboards there often still isn't enough granular detail to really create an effective solution. Prototyping aims to bring everything together pragmatically and answer all the missing questions while keeping all the value added results form our research in mind.

A prototype aims to mitigate to major risks when building a system:

1. How exactly should the solution work, going from broad strokes to fine edges
2. Mitigate the cost of engineering and software development by

By building a prototype before beginning true development you can flush out a majority of the challenges that will be faced by the development team before they're faced with them. Prototyping enables testing and collecting feedback on:

• Overall design concept
• Functionality of different components of the system
• User interactions
• Layouts
• Fine-grain design details such as fonts and color schemes

"Each prototype is intended to answer one ore more questions intended to help designers make decisions that move the design forward"

Types of Prototypes 

• Storyboards: a sequence of frames depicting a visual story with descriptions providing context of use. they act as both a representation of the formative work as well as prototype in the sense that they allow the extraction of feedback about a concept as well as context of use.
• Sketches: Visual ideation around different approaches and options. Also used for early feedback to validate ideas and approaches to solving problems.
• Wireframes: Visual representations of an individual screen or view of a system. they are used to identify what type of input and output is collected and displayed as under what conditions. Used to map out a high level understanding of the system, not a polished product.
• Interactive prototype: captures multiple states of a design, transitions, interactions, look & feel.

prototyping maximizes the number of times a solution can be revised and refined before it is committed to code.

Prototypes

A prototype is a representation of a design before the final solution is decided upon, that is a prototype is a living representation of our idea and as our idea evolves to meet our challenges so does our prototype. Sometimes we drop our prototype and start fresh but we should always learn something from our prototypes, if not what works then definitely what doesn't and with these lessons we improve or build new prototypes that get us closer to a resolution or solve our problem becoming our finished product.

Reasons for prototyping 

• Reification: is the process of taking an idea or concept and making it real, by creating our prototypes we create the opportunity to verify our ideas are going to resolve our problems.
• Reflection: by createing a prototype it gives us a chance to reflect on our design to ensure that they are meeting the design goal or taking us in a different direction
• Communication: Prototypes communicate our design ideas to the stakeholders to validate that our solution is going to solve the right problem.
• Assessment: allow us to run user tests on our ideas to verify that they are going to satisfy user needs.

Various forms of a prototype

• Verbal description
• sketch or wireframe
• storyboard
• Navigation/flow diagram 
• Physical model
• Video
• Formal specifications 

any of the above are valid prototypes however in user experience we usually mean a depiction of the system as a user will experience it. there are vaious levels of prototype

• Low-fidelity
• Addresses
• Functionality of what needs to be done
• Organization of how the UI is going to look, grouping
• Task flow & Coverage: Solve the tasks users need and how many of them
• Ignores
• Graphics: colors, fonts
• Programming: no programming done on paper to keep costs down
• Real Data: don't wory about actual data
• Mid-fidelity
• Addresses
• Layout: how are the fields and controls going to be layed out
• Interactivity: How does it feel to interact with the system 
• Navigation: from one part of the system to another 
• Ignores
• Graphics: colors, fonts
• Programming: no programming done on paper to keep costs down
• Real Data: don't wory about actual data
• High-fidelity
• Addresses
• Graphic design: colors, fonts, images
• Interaction details: animations, transitions
• Realistic data: actual data for system 
• Ignores 
• Background programming: services, security, etc
• Complete functionality coverage: focused on task trying to resolve 

KISS (Keep it simple stupid)

The best prototype communicates the design idea in the simplest most economical way possible to the stakeholders or the team, the idea to prototype to most minimal level is to save time and money to let the needs of the product guide the design and not the prototype fashion the needs.

Low-fidelity prototypes will also receive more open and honest feedback, stakeholders are more likely to challenge a design when it's on paper than if significant resources where put into constructing it.

the iterative design process

Assess	Design	Build	Assess
Asses current needs Understanding current problem Establish guidelines & constraints Personas, scenarios, user stories, requirements	Ideation Sketching Selection Synthesis	Develop Prototype	Assessment redesign More prototyping

Sketching 

sketching is one of if not the most valuable tool in a UI/UX professionals box, sketching allows designers to workout problems quickly and cheaply. sketches have the following characteristics 

• Quick: to produce
• Timely: can be inserted in multiple ways
• inexpensive: cost is low
• disposable: you're not committed to them
• plentiful: you can make dozens if not more
• minimal: very little detail 
• ambiguity: let you evolve them

sketching is an activity it is central to the design process, it is not just the product of sketching it is also the process, it gives us an opportunity to: 

• reflect on our designs 
• explore directions they may lead
• communicate our ideas

What to sketch?

Problem: sketching what's wrong gives insight to what we are trying to solve

Resolution: what would it look like for the problem to be solved 

System: to solve the problem

Sketch		Prototype
Evocative	→	Didactic: try to explain
Suggest: possibilities & opportunities	→	Describe: a paticular idea
Explore: ideas	→	Refine: initial explorations
Question: raise questions about solution	→	Answer: try to answer questions
Propose: ideas	→	Test: ideas
Provoke: ideas push boundaries	→	Resolve: problems
Tentative: possibilities	→	Specific: testing potential solution
Noncommittal: no investment	→	Depiction: committing idea for testing

Sketches are used for generating ideas and creating options whereas prototyping is narrowing down ideas for problem resolution. sketching is used to come up with ideas and strategies whereas prototyping is used to narrow those ideas down to the ones that work best.

when sketching it's very common to get stuck, where as there are many ways to try and get unstuck there is one simple method known as "The worst idea" this is the processes of sketching the worst solution to your problem, the idea is that by understanding what not to do it may give you new insight on what to do.