So I’m an “occasional” (nee terrible) blogger. Most of my time at Microsoft is spent in my role as User Experience Advisor – that means I’m working with our customers to help them produce product or service experiences that give their businesses a competitive advantage through great design.
That should give me a lot to talk about, right? Well, my ‘juice’ comes from the specifics of a project – general abstractions are useful, but often not interesting enough for me to want to spend time writing about it. This blog post is trying to change that.
Over the course of the last year or so, I’ve spent a lot of time building mobile applications. In addition, I’ve also led the building of larger-scale touch applications. What follows are some of the key elements I’ve taken from these projects. Call it my contribution to 21st Century Design.
- Wireframes are (usually) pretty but useless. At least as a tool for developing a design. Illustrator and Visio / OmniGraffle are fun, but you can indulge your info-graphic itch elsewhere. Wireframes are important for documentation, but don’t get that confused with the process of developing your design
- Visual Design is a part of User Experience design, not a parallel effort. As I’ve written in the past, design is a process for solving problems. One of the aspects of accepting this truth is that good design is driven by user understanding – Visual Design needs to work from the same set of understanding, just like Interaction Design or Information Architecture, towards the same goals – delighting users.
- Understand your user; Understand their context; Understand their goals. If you can’t define what makes your user happy, and what will make them tell their friends “you’ve got to try this,” you don’t know enough. If you don’t know where they’ll be using your product or service, you don’t know enough. See a pattern?
- Process is for solving problems predictably, not checking boxes. The point of any process is to get a project done – not check of elements on a list. There’s a phrase I’m fond of “have as little process as possible, but as much is as necessary.” Truer words were never spoken.
This means a couple things: First, if you’re part of a project with lots of people, or many moving parts, some process is inevitable, if for no other reason than there’s a need for predictability.
For small teams that are in close communication, you can skip some steps. Just remember: skipping steps introduces project risk, so you need to be careful, and experienced enough to know if it’s an acceptable risk!
- Make a decision. Eliminate unnecessary choices. Solving problems (Design) is about making decisions. If you’re not doing that, you’re pushing that complexity onto your user. At best, you’re annoying your user by making him / her answer something s/he thinks is extraneous. At worst, you’re confusing and instilling a lack of confidence in your user. If you’re really having trouble making a decision, try using a a different frame to evaluate the question from. Always remember #3.
- You aren’t the center of your user’s world. We live in a low-attention (and often low-information) world. It’s likely that you don’t have your user’s full attention, or at rate, not for very long – design for this.
- If you’re not prototyping, you’re doing it wrong. See #1
- Be polite and respectful, but be smart about it. This doesn’t mean asking permission for each step of a process. Be careful of intrusiveness. See #5 and #6
- Understand what you’re trying to accomplish. I call this a “Shared Thesis” – some have also called it Tenant-driven design. This is the single representation, across the project team, of why you’re doing the project. Everything you do should roll back to this statement.
- Transitions and motion are just as important as screens and end states. Don’t skimp on these. See #1 and #7.
- Satisfaction is nice, but Advocacy is the goal. Satisfaction is no indicator of loyalty to a product – advocacy, however is. Think about it: would you be willing to recommend (advocate) a product to your friends or family if you didn’t really love it?
- Blank sheets of paper are traps. As in, It’s a…! Design without constraints isn’t really design – it may be fun, and it may be a useful ideation exercise, but it doesn’t really do much to solve a problem. Remember your solution is always bounded by three questions: 1) what’s desirable to users; 2) what’s viable in the market; and 3) what’s possible with the technology.
- Inspiration comes from lots of different places. Parallel thinking, looking for patterns in related fields, is an important tool for creative problem solving. Don’t for get this. If all else fails, don’t forget the old adage from Picasso: Good artists copy; Great artists steal.
- Sacred Cows make the best burgers. Orthodoxy, tradition, and inertia all represent potential blind spots for your design solution. These traditions can hide the root cause of the problem you’re trying to solve. You won’t always be able to solve the root cause, but knowing about it is a lot better than not!
- Designing for touch is more than just touch target size. This is really a post in and of itself. Touch interfaces, NUI’s (natural user interfaces) – touch-driven interfaces are paced differently than mouse-driven / GUI experiences. There’s a symmetry between the resolution of input and the density of experience consumption – because touch input tends to be less precise, the density of experience tends to be lower (number of tasks on a screen, etc).