Lecture 7: Storyboarding, Paper Prototyping, and Mock-up Interviews

Remember the following when drawing the storyboard frames

- rough user interfaces -manual actions - draw pictures -sketch documentation used - draw cartoons of people interacting for interpersonal steps - if system takes over, draw what it does and describe any data that it relies on - user does a series of actions, draw separate step for each action with rough layout of UI - annotate role names for each tasks - annotate business rules, implementation notes, constraints, hardware/software expectations -include descriptions about whats happening, state assumptions, and anything where pic isn't sufficient - basically creating documentation of the process in the storyboards so someone that's o in the design meeting could read the storyboard and understand whats happening

Types of Storyboard Frames

-Manuel steps -user interacting with product -screen or device close-ups -system or behind-the-scenes

Creating a storyboard

-Number each frame -If there are branches, label each branch (e.g. 1A, 1B, 1C, etc...). -Once finished, combine the frames in order and name the storyboard. tips: -worry about overall structure and function -if stuck, go back and low level vision that part -Keep generating new cases? ask yourself if these appear in user's work or are logically deduced cases. get known user cases first

Walk storyboards to identify components

-Using storyboards, abstract out function based on their content. -Review the storyboards looking for core components and their function noting that some may span multiple storyboards. - not major parts of the new system that are relevant to the users along with key functions, automations, or business rules -don't create components wit overlapping function (merge them) -You should now have a list of UI components with the initial layout and function taken from the storyboards. -This is not your interface design, it's simply ideas for the UI which you may still need to update Ask yourself: -does each component hang together to support a coherent task or role? -are there too many components? should you combine some? -are the links between components clear? -overly complicated? simplify it -make sure not to add extra functionality

Paper Prototyping: Preparation

-gather storyboards and all other data just in case -supplies: cardboard, pens, stickers, scissors, boxes

Change the design based on user feedback Build subsequent prototypes to test with users

After completing an initial overview, consider turning things into (reconfigurable) wire frames.

The interview proper

Choose a starting approach: -Some users want to explore (limit this to < 10 minutes) -Others will start their tasks right away Observe, discuss, and make design changes: -Don't focus on the details -When asked how the system works, respond with: "Well, what do you think it does?" -Redesign to address implied knowledge since others may not have it Some potential issues: Something's missing -If it's not there, sketch it in. Something's in the wrong place -If the user wants some functionality from a different component/part of the prototype, simply move it. A minor design element is bad -If something minor is undesirable, change it. A major design element is bad -If a major part of the design isn't working, pull out an alternative (if you have one) or draw a new one.

Share all the UIs and build the prototypes

Make sure your prototype is reconfigurable. Create "links" for major UI components to create a flow. Avoid hidden functionality - everything must be visible. Include (removable) example data...especially for websites/forms. Create stimulus areas for new content in case something's missing...gather feedback to fill it in.

Conducting the interview

Make it clear that the mockup interview is not a demo -"Whatever you do, do not demo the prototype, or go into "do you like our product" mode. Give the user only enough information [to get started]." -The user will be doing some real work, interacting with the prototype, reconfiguring things if needed, etc... When you introduce your prototype: -If it's complex, introduce it along with its major components. -If it's easy to understand, let the user play. -Use related systems and/or web sites.

Brainstorm and define UI concepts

Now it's time to start sketching out your UI: Brainstorm systems components. Develop multiple alternatives, where appropriate, pick the best to prototype and save the others. Do pluses and minuses for each idea...fix the minuses. Once the overall function has been finalized, make a rough sketch of the UI. Remember: this is not your official paper prototype. It's a rough sketch intended to guide you in making your first prototype. Don't focus on the minor details...only capture the major components and features of the design.

Finalize the Design

Once the interviews (and their analysis) are done: -Finalize the design -Verify all UI design issues have been fixed -Ensure that any/all issues are resolved Now document it, write up the specs, or throw it to the devs!

Set up mock-up interview visits

Set up interviews with people that have job roles for which you have designed a solution. You can use the same people from the contextual interviews, but try to find new people if possible. Explain that paper prototype interviews are a pretend situation and that little, if any, real work will get done by the user. Take prototyping supplies in case you need to make changes.

Preparation and Review

Start with core work sequences Include materials for: -Different cases -Divergent strategies -New process design plans Doesn't have to be a straight path -you can go in multiple different paths (flashbacks/forwards)

Storyboarding

Storyboards are step-by-step pictures of how people will work in the new world/system that you are creating. They include manual steps, rough user interface components, system activity/automation, and documentation use.

The wrap-up

Summarize what was liked/disliked... ... then address any misinterpretations. Test the value of the system by asking: -"Do you like it?" -"What would you pay for it?" -"Would you recommend it to others?", etc... Prioritize the functions of the prototype by asking: -"If you could implement three things, what would they be?" -"What if you could only have two things....how about one?".

Paper Prototyping

The process of creating a pre-implementation, paper representation of your product.

Mock-up Interviews

Two-on-one interviews conducted in the user's workspace that focus on observations of the user using the prototype to do his or her work. One team member interviews and dynamically makes changes to the prototype while the other takes notes.

Wireframes

is a graphical representation of a UI element with -Everything positioned as it would be in a real UI -Relative sizes that are reasonably accurate -No worries about typefaces or color except to the extent that color carries semantic meaning -Minimal or no aesthetic appeal -Simple aspects of visual design that reinforce function/content