The Framework for Obvious Design is like a 12-step program for people who produce Web-based software, but there are no steps and the number of things to remember is much lower. In fact, there are only three parts.
OK, so it's really more like a three-layer cake.
Each part of the framework is discussed in different contexts throughout this book. The framework isn't broken up into three major sections, each focusing on an individual piece, because it isn't that clear-cut. Each part ties itself up into every aspect of application design, so don't expect to read this section of the book while standing in the bookstore and walk out a genius. You really need to take the book home and read it all the way through.
That said, you may notice the three elements that make up the framework are, in fact, pretty darn obvious.
The three parts are as follows:
It doesn't take a rocket surgeon to realize that knowing these things will result in better products, but for some reason, it can take a long time to see the obvious. It took me about six years.
A key point about this framework is that it will still apply in the future. Not an Ajax guru? Doesn't matter. Don't know the difference between DHTML and XHTML? No biggie. Don't know your JSON from your XML? Fret not. The framework will carry you through. When all these things have come and gone, replaced by bigger and better flavor-of-the-week technologies, the framework will live on, guiding you down the path of Web righteousness.
Also, it's important to understand that nothing in this book related to the process of application design is mandated in any way. You can use whatever methods are most effective for you. This book is about the qualities of good Web applications and how to create them. In support of achieving these qualities, I'll tell you about several process-related solutions that work for different people, but you shouldn't feel obligated to adhere to them, nor should you expect to learn about a specific development process in this book that outlines exactly how to create great Web applications any time, any place. Nothing works for everyone, no process works for every application, and no process in the world will tell you what makes applications great. Even the best development processes do not guarantee an application will be good. It's up to you to come up with the million-dollar ideas. I'm just here to tell you how to make them work.
To get things started, let's take a quick look at the three major elements of the Framework for Obvious Design.
Know what to build
Knowing what to build requires understanding the purpose of the application and its scope.
With this knowledge, you can build the right tool for the job, whatever that job might be. An application that does a good job of filling a need will be desirable by potential users. Heck, it doesn't even have to fill a need. It could be aimed strictly at having some fun or providing a new approach to an old problem. Whatever the case, knowing the essential ingredients that will allow the application to do its job well will result in a design that is more obvious to users.
To start, the aim is to create an "elevator pitch." When you have 30 seconds to get the attention of your boss or a new client and present a new idea, you have to communicate the idea in a meaningful and attention-getting fashion, with very few words. From there, as long as the initial idea is clear and worth some extra attention, you can elaborate and talk about the target audience and feature set, and try to nail down the essence of the application and how it will work.
The knowledge of what to build, what not to build, and the underlying rationale for the application make up the conceptual element of the framework. The conceptual element creates desirability, because applications with a clear purpose that fill a void in an effective manner are always welcome.
Know what makes it great
You already know what makes Web-based software great because you read the list earlier in this chapter.
The list is by no means limited, however. If you discover something else that makes software really good, add it to your list. Just make sure it's a quality of the software and not a detail.
For example, drag-and-drop interactions cannot make a Web application great. What makes it great is that the application offers real-time feedback based on user input. (In fact, maybe we should add that to the list now.)
Google Personalized features drag-and-drop content pods that provide a real-time preview so you always know where the pod will land when you let go of it.
These qualities may be hard to spot, so you have to look closely for them. When an application is designed badly, it tells you at every opportunity just how bad it is. But when it's good, you usually can't explain why it's good. You can't put your finger on it, but you know it when you see it.
All these qualities make up the application element. They help create a sustainable and positive user experience.
Know the best ways to implement it
This part of the framework is the biggest variable. As we've all seen, the best way to do something usually changes over time.
At one point in history, for example, the best way to have a conversation with someone 100 miles away was to, well, walk there. Later, phones came into play (OK, much later). Now, it's as simple as typing a message into an instant messaging program and waiting a moment for the recipient to reply.
Regardless of the best way to implement a particular feature, these tools make up the interaction element, which enables the usability of an application and creates what many people call the "X factor." This is the part of the application with which people actually interact.
Throughout this book, I'll discuss ways to implement application elements in such a way that they make operations obvious and effective. I'll also provide some practical examples by showing you how to redesign several typical implementations of Web interface elements so they are more meaningful, more helpful, and more effective.