Designing the Obvious, Part 2: Knowing What to Build and Why
- Meetings, Meetings, Meetings!
- What Is the Site Supposed to Offer?
- Who Gets Final Say?
- Who Will Use the Site?
- Moving On
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Whether or not you want to believe it, the vast majority of software projects fail. They fail to live up to their customers’ expectations, fail to sufficiently support the activities they were conceived to make easier, and fail to gain the ever-elusive customer loyalty earned by companies like Apple, Google, and Amazon.com.
Why does this happen? Well, many factors can be blamed for the ultimate failure of a product, but they tend to fall into the same few camps. Sometimes it’s because your product has fewer features and doesn’t stand up against the competition. Sometimes it’s because the market isn’t ready for your product. And sometimes products fail because users just don’t "get" what you were trying to do.
Of course, none of these complaints are the real reason. You see, sometimes the failure of a product doesn’t seem to make any sense at all. Sometimes your product has all the same features as the other guy’s product—and then some—and still fails to capture the market like its competitors. Sometimes, users understand completely what the tool is supposed to do, but choose another one anyway. And you ask yourself, over and over, "Why?" Why can’t your site do every bit as well as your competitor’s?
There is no single reason. But some of the causes go like this:
- Typically, users latch onto the first site or tool they find that they can tolerate, and they stick to it. Most of the time users spend on the Web isn’t in visiting new sites and discovering new things. Most of that time is spent going to the same sites over and over. And you haven’t given users a good enough reason to switch.
- Your product isn’t actually better than the competition’s just because you crammed more features into it. Your long list of features may make for good marketing material, but it adds up to complicated software that confuses and frustrates users. Most users never become the experts who will benefit from the more advanced features. Instead, the majority of users become intermediate-level users quickly and stay at that level as long as they use the product. I’ll discuss this point further in future articles.
- The difficulty of finding the information they truly want means that users don’t stick around to try to fight their way through your site, and don’t bother coming back.
Whatever the reason (and there are many more), the most important point is that, at the very beginning of your design process, you need to take some time to understand exactly what needs to be built, and why, so your site or product can serve its audience effectively and the potential causes for failure can all be overcome.
In the first article in this series, I discussed the notion of designing sites and Web-based software tools that are obvious to users, in the context in which they use them. I also listed some of the approaches and solutions to be covered throughout the remaining articles in this series. Today, it’s time to jump into the deep end and define your product’s requirements so you can begin to meet them.
Meetings, Meetings, Meetings!
Meetings are actually somewhat...well, bad for you, according to a report by Alexandra Luong and Steven G. Rogelberg, professors of psychology at the University of Minnesota and the University of North Carolina at Charlotte, respectively. These ever-unfocused, rather annoying gatherings contribute to burnout, anxiety, depression, and the perception of an increased workload. And while you probably knew that all along, it doesn’t change the necessity of holding meetings. When it comes to designing sites, meetings are essential. Meetings are the time and place to nail down requirements for a project by determining what’s important, why it’s important, and how to provide a solution for it. Meetings are a fact of life in this business. So how do you balance the need for meetings with the need to stay motivated?
Use the need to avoid meetings as an excuse to start practicing the art of embracing constraints, a skill that will eventually make all of your products better. Having fewer meetings means that the ones you do have need to be as productive as possible, so you need to keep them short, focused, and infrequent. In doing so, each meeting will produce better results, which is exactly what you want.
Come into each meeting organized, and be prepared to stay on task. If the conversation starts going sideways, reel it back in. If the point becomes lost by obsessing over minutiae, verbally announce that such details can be worked out at a later time, and get things back on track. The more effectively you stay on task, the faster you’ll be able to get on with the business of creating great Web products.
During these meetings, it’s important to find out exactly what the business hopes to gain by creating the product or site, who might use it, the estimated or expected timeline, the budget, and what factors play into determining whether the project is a success. Is there a market for the product? Does the information the company wants to put out fill a need? What is the need and how can it be met? These questions help bring to light which features are necessary—and, more importantly, which ones can and should be cut. Creating a concise list of vital features, stripped of anything that isn’t absolutely necessary, is the first step toward designing "the obvious."
Once these factors are determined, you won’t need many more meetings, and you’ll be free to start creating the great user experience everyone quite desperately wants.