SE365 Human Computer Interaction Basit Qureshi

Topics Design Exploration Sketches and story boards Task analysis

Previously Assess needs understand client’s expectations determine scope of project characteristics of customers & tasks evaluate existing practices & products Discovery Design Exploration Design Refinement Production

Design Discovery Need finding Contextual Inquiry Documenting needs Look for customer needs How, what, why a customer does what he does Collect any necessary materials Contextual Inquiry Documenting needs Mixture of simple & complex tasks simple task (common or introductory) moderate task complex task (infrequent or for power customers)

Design Exploration Expand Design Space brainstorming sketching storyboarding prototyping Discovery Design Exploration Design Refinement Production

Iteration At every stage! Sketch Paper Video Gut Tool Crit Program Design Prototype Evaluate Sketch Paper Video Tool Program Gut Crit Expert Eval Lo-fi Test User Study

Sketching: A Quintessential Activity of Design Design and Innovation comes from sweat. From trying many ideas. Sketching them. Building prototypes. * Courtesy Bill Buxton

Trying literally dozens and dozens of ideas. Kicker Studio, www.kickerstudio.com

Trying them out with people and observing what occurs. Kicker Studio, www.kickerstudio.com Trying them out with people and observing what occurs.

Until you find ideas/products/services that evoke an emotional response with your customers. Ideas that give new experiences that people value. The differences of opinion are on how you might get to this point. https://www.polleverywhere.com/multiple_choice_polls/D26SMQGMKxQQO5n Kicker Studio, www.kickerstudio.com

Because investment is low in the early stages, this is the one time in the product pipeline when one can afford to play, explore, learn, and really try and gain a deep understanding of the undertaking. This is where YOUR TEAM WILL be for most of this quarter!!!! Courtesy Bill Buxton

From Sketch to Prototype Difference in intent rather than in form This is a continuum, not an either/or proposition [ADVANCE SLIDES] The difference between the two is as much a contrast of purpose, or intent, as it is a contrast in form Courtesy Bill Buxton

The Anatomy of “Sketching” Quick / Timely Inexpensive / Disposable Plentiful Clear vocabulary. You know that it is a sketch (lines extend through endpoints, …) No higher resolution than required to communicate the intended purpose/concept Resolution doesn’t suggest a degree of refinement of concept that exceeds actual state Ambiguous Courtesy Bill Buxton

There has to be enough room for the imagination. If you want to get the most out of a sketch, you need to leave big enough holes. There has to be enough room for the imagination. Ambiguity in sketches is VERY important Courtesy Bill Buxton

Design as Choice Elaboration (“Flare”) Reduction (“Focus”) Choice where there are two key places for creativity: the creativity that you bring to enumerating meaningfully distinct options from which to choose the creativity that you bring to defining the criteria, or heuristics, according to which you make your choices Design is both GENERATIVE and REDUCTIVE Courtesy Bill Buxton Laseau (1980)

Exploration of Alternatives … a designer that pitched three ideas would probably be fired. I’d say 5 is an entry point for an early formal review (distilled from 100’s). … if you are pushing one you will be found out, and also fired. … it is about open mindedness, humility, discovery, and learning. If you aren’t authentically dedicated to that approach you are just doing it wrong! Alistair Hamilton VP Design Symbol Technologies Design is NOT a straight path We must generate and discard much more than we keep All of these representations of the design process converge. Some of the ideas thrown out may be your’s! – you need to learn to embrace this [ADVANCE] Courtesy Bill Buxton

Exploration of Alternatives People on a design team must be as happy to be wrong as right. If their ideas hold up under strong (but fair) criticism, then great, they can proceed with confidence. If their ideas are rejected with good rationale, then they have learned something. … There are no dumb questions. There are no ideas too crazy to consider. Get it on the table, even if you are playing around. It may lead to something. Bill Buxton Sketching User Experiences pg. 147-149 bringing “design rationale” or reasoning for decisions is key to making this work well diverse teams help make this work better & that is why we created such teams in this class Courtesy Bill Buxton

User Interface Design User Experience Design UD UX

What does the customer want to buy? Design What does the customer want to buy? This clearly shows the DESIGN of the bike… [ADVANCE] But, What does the customer want to buy? The bike owner wants to buy [ADVANCE] Courtesy Bill Buxton

Experience Design “The experience of even simple artifacts does not exist in a vacuum but, rather, in dynamic relationship with other people, places, and objects” – Buchenau & Suri 2000 The EXPERIENCE of using the bike. The aspiration (and hopefully the reality) of the experience Experience depends on the bike, your equipment, the weather, the terrain, your skill, your current state of mind, etc. Courtesy Bill Buxton

Design Courtesy Bill Buxton This clearly shows the DESIGN of the bike… But what the bike owner buys is this [ADVANCE] Courtesy Bill Buxton

Experience Design Courtesy Bill Buxton The EXPERIENCE of using the bike. The aspiration (and hopefully the reality) of the experience Experience depends on the bike, your equipment, the weather, the terrain, your skill, your current state of mind, etc. “The experience of even simple artifacts does not exist in a vacuum but, rather, in dynamic relationship with other people, places, and objects” – Buchenau & Suri 2000 Courtesy Bill Buxton

Experience vs. Interface Design He loved his first juicer every morning… complained he didn’t have it at the cabin Then got the gift of the second for his cabin. Quiet!!! Loved the experience and now no longer liked the original! Complained… then got a gift of the 3rd for home… Same interface as the second… but DIFFERENT experience. Easy at end of pulling down lever. USER EXPERIENCE was partly the UI but also the situation and environment And the relative experience to what had come before! CitrusMate Plus Mighty OJ Manual Juicer OrangeX Manual Juicer

Experience Design for a Phone App? Draw my phone Draw my app’s interface Draw the experience of using my app Which is the true object of design? What is the experience design for our phone app? http://www.listmeapp.com/ Courtesy Bill Buxton

Minimal Detail Include only what is required to render the intended purpose or concept Abstract it http://www.smashingmagazine.com/2013/06/sketching-for-better-mobile-experiences/

Scott McCloud’s Understanding Comics People think focusing is about saying “yes.” But… “Focusing is about saying no.” – Steve Jobs

Design Thinking is Iterative

Sketches and story boards

Sketches & Storyboards Where do storyboards come from? film & animation Give you a “script” of important events leave out the details concentrate on the important interactions

Sketches & Storyboards

Sketches & Storyboards

Ink Chat Starts to tell a story, but still describes the design combination of the two Starts to tell a story, but still describes the design

Picturing Time Ron Bird

Informal UI Prototyping Tools Outpost Suede Denim Topiary SketchWizard We don’t have the tried and true theories of other fields. Can’t follow a book, build it, and expect it to work. The best tools let you enter a design, create an interactive prototype, & support testing it This is the philosophy that our work supports!

Informal UI Prototyping Tools Support advantages of low-fi paper prototypes brainstorming consider different ideas rapidly do not require specification of details incomplete designs need not cover all cases, just illustrate important examples Add advantages of electronic tools evolve easily support for “design memory” transition to other electronic tools allow end-user interaction Unlike designing a computer program, you do not need to consider all cases this early. present several designs to give the client an idea of what I as the designer am thinking about.

Designers’ Outpost: A Tangible Interface for Designing Information Architectures Combines physical & virtual physical post-its, virtual feedback Supports existing practice affordances of paper collaboration large, persistent representation Adds advantages of e-media editing, reuse, distribution hand-off later to other tools two cameras: one high res for ink, one behind for tracking to avoid occlusion by users Informal UI means it stays OUT of the designers’ way

Task analysis

Task Analysis Task Analysis questions? Who is going to use the system? What tasks do they now perform? What tasks are desired? How are the tasks learned? Where are the tasks performed? What’s the relationship between customer & data? What other tools does the customer have? How do users communicate with each other? How often are the tasks performed? What are the time constraints on the tasks? What happens when things go wrong?

Selecting Tasks Real tasks customers have faced collect any necessary materials Should provide reasonable coverage compare check list of functions to tasks Mixture of simple & complex tasks simple task (common or introductory) moderate task complex task (infrequent or for power customers)

What Should Tasks Look Like? Say what customer wants to do, but not how allows comparing different design alternatives Good Bad Tony is visiting London and wants to find the pub that his friend told him about. He is walking down the street using his phone to navigate to the place that he has previously looked up (good) TASK Vs. Tony clicks on the Charing Cross Pub icon and selects “directions to” as he walks down the street (bad) SCENARIO

What Should Tasks Look Like? Say what customer wants to do, but not how allows comparing different design alternatives Be very specific – stories based on facts! say who customers are (use personas or profiles) design can really differ depending on who name names (allows getting more info later) characteristics of customers (job, expertise, etc.) forces us to fill out description w/ relevant details example: file browser story or dentists forms Some should describe a complete job forces us to consider how features work together example: phone-in bank functions “Wixon and colleagues were developing an interface for a file management system. It passed lab tests with flying colors, but bombed as soon as customers got it. The problem was that it had a scrolling file list that was (say) twenty characters wide, but the file names customers used were very long, and in fact often identical for more than twenty characters (the names were made up by concatenating various qualifiers, and for many names the first several qualifiers would be the same.) Customers were not amused by needing to select from a scrolling list of umpty-ump identical entries that stood for different files. And this wasn't an oddball case, it was in fact typical. How had it been missed in the lab tests? Nobody thought it would matter what specific file names you used for the test, so of course they were all short.” – from Chapter 2 of TASK-CENTERED USER INTERFACE DESIGN A Practical Introduction by Clayton Lewis and John Rieman.

What Should Tasks Look Like? This design works fine when 1 “sub-task” is tried at a time, but when they are combined there is excessive up and down traversal of the phone tree

What Should Tasks Look Like? This design allows checking each account and then form an account, immediately transfer funds

Using Tasks in Design Write up a description of tasks formally or informally run by customers and rest of the design team get more information where needed

Using Tasks in Design (cont.) Rough out an interface design discard features that don’t support your tasks or add a real task that exercises that feature major screens & functions (not too detailed) hand sketched at least 30 sketches Produce scenarios for each task what customer has to do & what they would see step-by-step performance of task illustrate using storyboards sequences of sketches showing screens & transitions

Scenarios (cont.) Scenarios are design specific, tasks aren’t Scenarios force us to show how various features will work together settle design arguments by seeing examples only examples  sometimes need to look beyond Show users storyboards get feedback

Summary Sketching allows exploration of many concepts in the very early stages of design As investment goes up, need to use more and more formal criteria for evaluation Selecting tasks ? real tasks with reasonable functionality coverage complete, specific tasks of what customer wants to do Informal prototyping tools bridge the gap between paper & high-fi tools