Lukas Mathis - Designed for Use: Create Usable Interfaces for Applications and the Web

This is a book for visual designers and programmers. Its not, however, about visual design or about code. Instead, its about something much more important: the people who will be using your product.

The best product is of no consequence whatsoever if people dont use it. You can create the most beautiful, sturdiest, most elegant brush in the world, but if nobody uses it to paint a picture, your work was in vain.

This book helps you make productsapplications and websitesthat people will want to use.

There are two kinds of chapters in this book: technique chapters and idea chapters. Each technique chapter explains a specific technique you can use during the design process to make your product more user-friendly: storyboarding, usability tests, or paper prototyping, for example. Technique chapters explain concrete things you can dothe tools for your designers tool belt.

Idea chapters, on the other hand, talk about ideas or concepts in more general terms: how to write usable text, how realistic your designs should look, when to use animations, and so on. Idea chapters explain things to think about and consider while coming up with designs.

You can identify technique chapters by the cog on the first page.

All technique chapters follow the same basic outline. Since not all techniques work well in all situations, I start by quickly outlining the kinds of situations to which the technique applies. Then, I explain what the technique is and how to use it. I end many of the technique chapters with a specific example of the technique as applied to a fictional application we design as we proceed through the book.

Since Twitter apps are our generations Hello World example application, for the technique chapters well design a Twitter app. To make things interesting, were not designing a generic Twitter app. Our app is aimed at people who have to update Twitter accounts for their companies. We call this fictional application BizTwit.

Think of the technique chapters as recipes. Its OK to read the book from start to finish, but its also OK to delve into a specific topic. To that end, these chapters are typically short and to the point, and they contain references to further information both inside the book as well as in other books or on the Internet.

While technique chapters introduce specific techniques and explain how to apply them, idea chapters are less specific. They introduce concepts and are mostly meant as sources of inspiration, rather than as strict rules. Some of the idea chapters mention techniques or refer to technique chapters, but they focus on more general concepts: How realistic should design be? How can we use animation most effectively? What are modes? What can we learn from video games?

You can identify idea chapters by the light bulb on the first page.

The ideas in these chapters may not always apply to the projects youre working on, because to some degree, people are unpredictable. When using your products, they dont always behave as you expect them to behave. And they dont always act as your rules predict.

To illustrate how peoples behavior is often different than predicted, lets look at an example outside of user interface design. Lets assume you are concerned with public health and safety. Where do you start? Given that tens of thousands of cyclists are injured in traffic accidents every year, bicycle safety is a good place to start.

Studies show that helmets help cyclists avoid injuries. So, getting people to wear helmets should decrease the number of injuries, thereby increasing peoples health and safety. The predicted outcome seems obvious: people get into bike accidents, helmets prevent injuries, people who wear bike helmets can avoid injuries. Conclusion: force people to wear helmets.

Over the years, a number of bike-helmet laws have been introduced. However, these laws have not led to the predicted outcome.

In a 2009 study titled The Health Impact of Mandatory Bicycle Helmet Laws, Piet de Jong, from the Department of Actuarial Studies at the Macquarie University in Australia, evaluated the effects of such laws. He discovered that people really dont like bike helmets, so much so that many of them simply stop using their bikes altogether if they are forced to wear helmets while riding.

This outcome prompted de Jong to conclude that bike-helmet laws actually have a negative effect on societal health as a whole. Yes, the laws prevent some injuries, but for people who stop using their bikes entirely (and often use their cars instead), the health consequences are overwhelmingly negative.

The bottom line is, no one bothered to test the laws before enacting them. The people who were affected by the laws did something completely unexpected by the people who designed the laws.

You will often observe the same effect when designing user interfaces. Design changes dont always create the result you intended and sometimes have the opposite effect of what you expected.

When you read the ideas and rules in this book, I want you to keep this in mind. You can do your best to come up with a usable solution; you can follow all the rules and make what seem like obviously usable choices when designing your user interface. But people will still surprise you by finding creative ways of misunderstanding your applications user interface, getting lost on your website, behaving in unpredictable, seemingly illogical ways, and being unable to do the very tasks that seem most obvious to you.

Never assume you can apply a list of usability rules to a product and end up with something usable. Use common sense when designing user interfaces, but dont rely on it. Know the rules, but break them if it improves your product. The point is not to do exactly what I tell you to do but instead to take my words as a source of inspirationand to always test your designs.

The chapters in this book are presented roughly in the order in which they are applicable during a typical design process, which Ive divided into three stages: research, design, and implementation.

Its tempting to jump right in and start designing a product as early as possible (or perhaps even to start writing code if youre a programmer). In some cases, that may be OK, but its usually better to start by doing a bit of research. Who is your product for? What problems do you want to solve?

Think about how to solve your audiences problems. Design solutions and then test them before writing any code. Fixing mistakes on paper is a lot easier than fixing them in code.