UIE Web App Master’s Tour – Seattle, Washington – May 24, 2011
Jared Spool, CEO & Founding Principal of User Interface Engineering and co-author of Web Anatomy, started the session by showing examples of web sites that had serious usabilities. Some of the designs were attractive, but did not serve the users needs. In most examples, the user had to click multiple items or jump back and forth between pages or flyouts (a process he referred to as “pogo-sticking”) to find the information that would help them make the decision they were supposed to make to allow them to continue with the process. The takeaway was that when we encounter a problem in our application that hinders users, we should strive to help people make a choice in the easiest way possible.
Dieter Rams
Dieter Rams was the first person to create a standardized set of design principles, which are as follows:
Good design…
- is innovative
- makes a product useful
- is aesthetic
- makes a product understandable
- is unobtrusive
- is honest
- is long lasting
- is thorough, down to the last detail
- is environmentally friendly
- is as little design as possible
However, the problem with generic design principles is that they don’t help us to actually make individual design decisions. Good design helps you to decide what to say “no” to.
Look at IBM.
Microsoft created desktop design principles based on the failure of Vista.
- Reduce concepts to increase confidence
- Small things matter, good and bad
- Be great at “look” and “do”
- Solve distractions, not discoverability
- UX before knobs and qeustions
- Personalization, not customization
- Value the life cycle of the experience
- Time matters, so build for people on the go
Windows 7 Design Principles video online
Design principles, rubrics, heuristics, guidelines, philosophies don’t necessarily make better design. Many times they are created and then never referenced again.
How do we tell if our designs are getting better?
Research-Based Principles (Generating Principles from Research)
- Go out and meet customers – quick field research
All team members, stakeholders or anyone who has influence over the design visit 12 customer sites, with an average of 29 participants for half-day visits
Not every member of the team will go to every site
One facilitator and the rest are observers - Create a list of top-priority projects (team members who did not participate in the field research can attend, but they can’t contribute)
Let them tell you what they think is most important - Create Personas for each project – who will be affected by this change? Who’s life will be made better?
- Create Scenarios (actually more important than personas, but can’t be created without personas)
- Create Principles (they come out of personas and scenarios – look at the problems and figure out what you’re going to strive to do differently)
A lot of times there will be no overlap from project to project, but sometimes something sticks out.
Using Principles to Explore Design
Create the Mini-Project Creative Brief (strive for a half-page), which includes:
- Project Statement: What’s the goal of this design?
Make rescheduling a hair appointment easier for receptionists - Select Personas: Who are we designing this for?
Luanna – receptionist who works every weekday afternoon
- Select Scenarios: What does the design have to do?
Customer calls up on Wed needing to reschedule a cut & color for Fri. - Select Principles: How will we know when we’ve done great?
Focus on simplicity over exception cases; polish – make sure it works great
To start every meeting about the project, read the mini-project creative brief so that you can focus on the true needs. If you realize that the design is not matching the brief, you can have the discussion about whether or not the personas or the design are still valid.
Using Principles to Critique Design
Critique is a process (not criticism)
- What are we trying to accomplish? (What you’re trying to accomplish)
- Does this design do that? (How you’ve chosen to accomplish it)
You need to have the conversation about what you’re trying to accomplish before you have the conversation about the design. Do not bring up elements about the design that have not been discussed in the first part of the process. You cannot have “bring me a rock” design elements. (Fairy tale about king who asked for a rock)
You cannot bring up criteria for design that was not discussed as part of what you’re trying to accomplish.
Test #1: Does the design principle come directly from research?
Test #2: Does the design principle help you say ‘no’ most of the time? (Is the design ‘clean’? is not a good design principle.)
Test #3: Does the design principle distinguish your design from your competitor’s designs?
Test #4: Have you evaluated the design principle for this project?
Test #5: Is this design principle something you might reverse in a future release?
Test #6: Is the design principle’s meaning being constantly tested?
If you’re designs are testing your design principles, they’re probably not good design principles. Don’t shy away from semantics when it comes to your design.
The Essential Principles behind Great Design Principles
- They are specific to your projects
- They are derived from your research
- They are influential in design exploration
- They drive your critiques
- They define your vocabulary of good design and bad design
What do YOU think? Let me know...