Design for Software: A Playbook for Developers

Chapter 1: Planning

“It works, but nobody uses it”

SO YOU JUST finished your latest digital creation, and you managed to squeeze in every last toolbar, pop-up menu, banner, button, tooltip, and scrolling marquee. It’s awesome . . . right? I’m sure it is. But sadly, more features rarely mean better software.

Well-designed software doesn’t start with a functional requirements list, pretty pictures, or a slick algorithm. It starts with people. People use software as a means to an end. Whether it’s a website, MP3 player, or utility, users have distinct needs and motivations for using the digital product. It’s your job to cater to them.

How many times have you found yourself using, say, a GPS unit or kiosk and thinking, “That doesn’t make any sense” or “Why did they design it that way?” Chances are, the people who built the software weren’t thinking about you. Tragic, I know.

Seriously though, all too often we approach building software solely in terms of functional requirements. We approach every problem by looking for the best technology solution, rather than focusing on what’s best for the user. After all, that is how software development is typically taught in school and how most projects are structured.

I’ll let you in on a little secret. Creating successful software is not that complicated. In fact, all you must do is understand what users need, and then give it to them in the clearest, least cluttered way possible. Simple, huh? Well, not exactly. But, by using the techniques ...