Skip to content

Latest commit

 

History

History
103 lines (70 loc) · 5.25 KB

5-2.md

File metadata and controls

103 lines (70 loc) · 5.25 KB
Raw

Design Process

CS 349 - User interfaces, LEC 001

5-30-2016

Elvin Yung

Slides

User Centered Design

How do you build software for people who aren't you?

You have to talk to the customer, figure out:

  • what they need
  • what problems they have with current solutions

You need to think about the people who use your software, and to test your ideas with them.

Developers are not people. You are not the user - you can't just build it to your specifications.

History

Started with the original Macintosh team at Apple.

The original process: bring in users, show them stuff, and iterate.

(citation needed. I can't seem to find any source that actually supports this claim; the closest I could get to was Andy Hertzfeld's story about demoing a Mac prototype to Microsoft.)

(Addendum: This seems to have been something developed at Xerox PARC, and then adapted for the Lisa project when Larry Tesler went to Apple.)

Principles

  • Understanding users' needs
  • Design the UI first - not the architecture. Choose the technology to fit the needs, not the other way around. (This isn't exactly a hard and fast rule - sometimes you need to figure out if something is technically feasible)
  • Iterate!
  • Use your own software - "Eat your own dogfood."
  • Look at other people using it - and in real life, not some sort of lab.

Iteration Cycle

(Caveat: this diagram assumes you won't change the architecture, which isn't always true in real life.)

Understanding the User

  • Observe existing solutions. It's important to see how the user uses the software. You need to design the scenario that you're working with, and meeting the requirements that they want.
  • List scenarios. e.g. for an email client, figure out what the flow for sending an email should be like, replying to an email, forwarding an email, creating a mailbox, etc. Scenarios are great because they're a natural place to talk about what the user is doing, in the context that they're doing it. Collect data from a bunch of users - catch a wide range of use cases.
  • List and prioritize functions. Figure out what scenarios need what, and prioritize.
  • List functions by frequency and commonality. Common functionalities should be accessible with few clicks, more obscure use cases hidden in menus.

Designing the UI

  • Temporal distribution: steps in the flow

  • Spatial distribution: where components appear on a section

  • Use storyboards to mock up the basic flow for (typically) scenarios.

  • Describe interaction sequences: plan interaction paths like a flowchart

  • Testing the design: quickly prototype, test with users, and iterate.

6-6-2016

Testing with Users

  • AKA: Prototyping
  • Iterate, refine.
  • Specifically, let people interact with the design, and explore its sustainability.
  • Goal: Maximum feedback for minimum effort.
  • Example: testing the first PDA prototype by making a wooden model of it, and then writing on it in front of people, and testing reactions
  • Build software last! It's super expensive and time consuming.

Prototype Objectives

  • Needs to answer this question: Does it work for this scenario?

What to prototype?

  • You can prototype anything: concepts, navigation, mental models, layout, technical feasibility, usefulness, etc.
  • This is the same thing as an experiment!

Prototype Fidelity

  • The level of detail/care you put into the prototype.
  • Low fidelity: Prototype doesn't look a lot like the real thing; the operations might be simulated or slower.
  • High fidelity: Prototype looks and acts like the real thing.
  • Even if you're confident in your design, you want to build a low-fi prototype first!
  • People are way too nice to give real feedback. If you show people a high-fi prototype first, people will feel bad giving you more work.
  • If you start with a low-fi prototype, you get more objective/higher level feedback because they know you haven't invested any time or effort into it.

Paper Prototyping

  • Building a paper version of the interface, with a person playing the computer.

  • A really good (and probably overkill) example: Hanmail.

  • This is a concept called the Wizard of Oz technique or Wizard of Oz experiment, where you have a software interface, but a human acting as the backend to simulate the response.

  • Stripe does this!

  • The interface should be as minimal as possible - just enough to get feedback. Speed is of the essence!

  • Get feedback immediately.

When and How to Prototype

Breadth vs. Depth

  • You probably won't have enough time to test every flow - be able to cherrypick and prioritize which scenarios you want to test.
  • Your interactive prototype will probably have spotty coverage in terms of features/scenarios.

MIDTERM MATERIAL ENDS HERE