There's a dirty little secret that nobody in the design community wants you to know: it's actually possible to build and ship a software product…without designing it first! There. I said it. Now my time is short; even as I type, assassins with square-toed shoes and goatees are stalking my whereabouts.
But just because you can construct software products without designing them first, why on earth would anybody want to?
The analogies are endless: you wouldn't point a construction crew to an open lot and tell them to build a structure without giving them blueprints, would you? You wouldn't ask a doctor to re-set a broken bone without looking at an x-ray; you wouldn't storm the beaches of Normandy without a battle strategy and a good map; you wouldn't even don your shoes before putting on your socks.
Executives chuckle warmly at these analogies, and agree wholeheartedly that yes, it's always best to design products—the things that their companies sell for money—before building them and putting them in the hands of customers. Yet even though business decision-makers of all stripes acknowledge the merits of design, it's the designers and usability professionals who are the first to get jettisoned from a project plan when the going gets rough.
The top two reasons executives usually cite when they decide to short-change the design process are a Shortage of Time and a Lack of Money. However, companies have much more time and money to lose by not investing in design.
Several myths lead to the misperception that it's easier and cheaper to do without design. I'll walk through some below, then describe some ways to measure the design's return on investment within your own organization.
If we just hire more programmers, we can get to market sooner.
If your programmers know exactly what they need to build, this strategy makes sense, but only if they know what the product should look like and how it should behave…in which case your programmers will still be doing a designer's job and will require the time and resources to get it done. Yet programmers already have a full-time job just to create bug-free production code within tight deadlines. Now we are going to ask them to design the product, too? The results can be dreadful: programmers wind up choosing the path of least resistance while they design as they code, which leads to complex, hard-to-use interfaces.
Why not spend the money on actual designers? With clear, well-defined design specifications in hand, your programmers will be more efficient, and their design decisions won't get second-guessed in ways that result in re-coding, which takes more time and costs more money.
If we don't get it right the first time, we can just fix things in the next release.
Your customers will really appreciate this approach, won't they? Maybe this strategy used to work in the rare case where you were bringing water to the desert, but nowadays most software products are getting launched into relatively mature markets where users have already developed sophisticated expectations for their interactions with products.
There is no erasing the first impression your product makes in the marketplace. Adding time for true requirements definition and design doesn't mean postponing your product launch indefinitely. What it does mean is making sure that you get the important things right the first time, and that you block out the time necessary to get the job done right. Then, your subsequent releases can be about sanding off the rough edges rather than hitting your first wave of customers with yet another fundamentally new user interface because the previous one was broken.
Design takes too long.
So does coding the same product twice because you got it wrong the first time. Enough said.
Well, maybe there is one more thing to say on this subject. Sometimes when people object to the length of time it takes to do design they are really saying that they have never experienced a design process that was worth the time. Fair enough. But all the more reason to insist on a design process that provides everyone visibility into and appropriate influence over the product definition and development process.
We need to ship a new product version every month/quarter/year/lunar eclipse.
But why? Hyper-cyclic release schedules are often simply running cover for management's inability to determine the future needs of users, and to create a plan (i.e., a design) that answers those needs. Yet in fact you can doom your product from the start by assigning an arbitrary ship date.
Certainly, there are many valid reasons for having an unmoving, cyclical shipping cycle. Showing the market something new before the big industry trade show each year can make sense, as does the need to refresh static web-page content. Adding features that better serve vertical markets can also argue for a cyclical schedule. Even still, if regular updates are part of your business plan, be sure that you spend adequate time designing the first release. This will enable you to fold in new features later with a plan in mind, and in a way that doesn't break your existing structure.
There are other less-convincing reasons for shipping on a tight cyclical schedule: "It looks good to our investors that we're shipping four times a year," or "users like to know that we are frequently innovating," or (my personal favorite), "my agile programming process dictates that we release new versions every 90 days no matter what." These don't seem like sound business decisions to me, because there's nothing inherent in them that speaks to the goals of customers, much less users.
Rather, why not identify a product development roadmap with objectives based on real market analysis, business requirements, and user goals, and then set a release plan that ties to those objectives? Short, rapid release increments don't allow for the opportunity to discover innovative breakthroughs; you will only have time to iterate on what you already have.
Making the case for design
What other arguments can be made to allocate time and budget for design activities? Unfortunately, there is no single easy-to-compile metric that can tell this story for you. Here are some things you can measure to help you communicate why investing in design is good for your company in the long run.
Measure the usability of your current product.
Conducting a formal usability test is a great way to confirm suspicions that your current product needs improvement. The most effective usability test analyses combine qualitative observations as well as cold, hard statistics about how users performed on tasks; this is a powerful way to communicate with business decision-makers. Later, after you've designed improvements based upon the needs revealed by your usability tests, you can conduct follow-on tests with the new version and compare the results.
Measure technical support costs
How much money does your company spend on technical support and customer service? Building products that don't encourage your customers to pick up the telephone and call you for help can lead to significant cost savings. Some call centers distinguish between bugs ("this is broken") and usability defects ("I don't know how to use this"), and can give you statistics about the number of person-hours they spend on each type. These numbers are easily converted into dollars, and represent potential savings for your company.
Identify other costs that could be trimmed if your product was easier to use
Does your company send out a human with every new customer installation to manage setup and configuration? Do you provide training as part of the system package? Reducing the number of hours that people from your company spend at customer sites will result in big savings. It also instills confidence in your customers that your product is so useful and easy to use that there's no need for constant attention from a specialist.
Assess the accuracy of your internal product development plans
How many times have you seen design time reduced to the point of uselessness in order to meet a deadline…only to see the rest of the development schedule slip by several months mid-stream?
Usually, project plans slip because product requirements are vague, poorly understood, or just plain inaccurate. Vague requirements make it difficult for the development team to accurately assess how much time they need to build the product. The product definition also becomes a moving target; decision makers keep adding features and requirements during development as they find holes in the product vision. Pinning down product requirements and making an explicit blueprint are just the sort of tasks carried out by designers.
But how can you make an argument for designers to do this work? Do a post-mortem assessment on some recently completed projects, and compare the initial planned project-completion date with the actual completion date. Chances are you'll find the amount of time the project slipped would have been a good amount of time to put towards design. Even if substituting up-front research and design activities would not have saved time in the long run, wouldn't the reduced thrash and increased visibility be worth it?
The best measuring stick: building better products for your customers
These measurements are examples of ways to build your case for spending money on design by pointing out how design can increase profitability by helping you manage costs. However, the best way to improve your company's bottom line is not to reduce costs, but to increase revenue.
Designing your products first will result in better products. Better products are more desirable to your customers, which leads to more revenue for your company from increased sales. An increase in sales lets you increase your pricing power, which also adds to your bottom line. And don't forget the impact that customer loyalty has on stimulating additional sales and reinforcing positive brand awareness in your market.
The value of good design is not restricted to the impact that the actual product has when it's finally in the hands of users. In fact, with a vivid product blueprint in hand, sales and marketing staff have a way to demonstrate to potential customers the value of upcoming releases. This approach is far more convincing than hand-waving a bullet-list of product specs under a customer's nose.
Unfortunately, these benefits of design are harder to quantify. The strongest brands out there, however, don't ask what the ROI on design is—they know that the cost of not doing design is enormous.
Sure, it's quite possible to build a product without designing it first, but is it worth the risk?