If you’re a client, starting a software project can be daunting. There’s just so much to think about. At best, it’s overwhelming. At worst, it’s paralyzing and the project grinds to a halt.
It doesn’t have to be like that. I’ve found an easy way to simplify the process for you: Think of the software as a person who handles tasks. It’s a simple premise, but it’ll completely change the way you approach software projects.
Anytime I draw the comparison between software and people, clients instantly “get it.” They start thinking about the software differently. In the past, they would have thought, “How would the software do it?” And they would get too hung up on functionality, sitemaps, and scope. Now they think, “How would I do it?” And suddenly, they’re focused on what matters most—the user’s end goal.
Here’s an example. We recently helped a client build an app that allows users to get home and auto insurance quotes online from local insurance agents. Users submit their information one time and the best rates come to them.
If we had taken the “how would the software do it?” approach, the app easily could have been a long one-page form requiring lots and lots of scrolling. Would it have gotten the job done? Yep. Would filling out the form have been boring, tedious, and devoid of personality? Absolutely! It wouldn’t have been user-friendly. And it wouldn’t have been something I would have liked to use, let alone build for someone else.
Instead, I encouraged the client to use the “how would I do it?” approach. I said, “Explain to me how you would do it if there wasn’t a thing such as software. We’ll worry about turning those steps into a user-friendly app.”
Without software, the client said, users would speak to an insurance agent. So I asked, “What’s the first question the agent would ask? What’s the next question?” And so on. We began to treat the app like a conversation between a user and an insurance agent rather than between a user and software.
What’s a conversation like?
- You ask one question at a time and there’s back and forth. Rather than making people fill out a long form with one question after another, we went with 15 pages (or screens) of short questions. We ask. You answer. We ask another question.
- You transition from one topic to another. We included transitions so there wasn’t an abrupt change of subject. For example, one transition says, “Now we need to collect some information about your home” followed by a “continue” button. So the user is like, “Oh, yeah, we’re going to talk about homes now.”
- It’s personal. Instead of a form asking for “Name,” we asked, “What’s your name?” We wanted users to feel like they’re talking to a real person, not a robot.
When you approach software from a human standpoint, rather than a software standpoint, everybody wins. It’s easier for clients to think through complex software projects. It’s easier for software developers to identify the steps those projects need. And the people ultimately using the software enjoy a more user-friendly experience.