The first question I ask myself before starting work on an application, before touching a single key, and before I even brew a cup of coffee is, “Who is using this and how can I make them enjoy using it?” User-experience is centered throughout development.

To some, this might seem like a very silly routine for a simple website or service. However, at the end of the day, the most useful function software can provide to the user is the function of being useful.

To elaborate this seemingly obvious statement: The first thing an application must be, before it is wrapped in a beautiful interface, before it is full of awesome features and before it can even launch is useful to the people who will use it. I’ve spent many years in my field making this argument, to almost immediate backlash from various sources, but software that is usable is the best software. Period.

Keeping that in mind, let’s get into why user-driven development is so important to me and why it should be important to you.

The MUVP

When I’ve discussed with my clients developing a new product, often the term ‘minimum viable product’ is dropped here and there. This is an application that, if not anything else, is functional. This ties in directly with my earlier statement that an application must be useful before it is anything else.

However, I’m going to make an argument for something more. I’m going to say that the ‘minimum viable product’ isn’t good enough, and that there is a step above that should be considered. ‘The minimum user-viable product.’

“What does that mean exactly?” you may wonder. It’s a step above just being useful. It means being useful to the people who will use it, regardless of whether they fully understand all of the problems it solves. An application that is useful to the people who commissioned its development simply is not enough.

A lot of people ask me to develop products just to get them out to the users. This way of thinking is flawed. The things that many people consider “nice to have” in the next release are often deal breakers when it comes to usability of the first release. Never sacrifice the user experience on the initial release simply to make it available sooner.

Know Your Users’ Wants (And What They Don’t Know They Want)

Getting user feedback is important, but sometimes, the user doesn’t know exactly what they want. It’s also our job to give the user what they don’t know they want.

For example, no one knew they wanted Facebook until it was created. Few people thought posting filtered photos was going to be successful until Instagram. The user cannot always be burdened with giving you ideas. As a developer, it is my job to create a mental proxy to the user. I prototype new ideas until one jumps out at me and says, “If I was the user, I’d loved this.”

Now, that doesn’t mean you should ignore a user who does have an idea. Just remember that for most projects, the end-user will not be available for every step of the development process, if they are even available at all. New ideas and feedback fuel great applications. Your user will be thankful you thought of them.

Make The Problems Of Your Users Your Own (And Fix Them)

Linus Torvalds, a personal hero of mine is the man responsible for Linux, an operating system that may be powering everything from your Android phone to your TV to your Microwave.

A few years ago Linus was addressing an issue with Adobe Flash failing to work properly on a version of Linux called RedHat. When someone told Linus that the issue was with Adobe’s software and not RedHat’s, he made the following argument:

“How hard can it be to understand the following simple sentence: THE USER DOESN’T CARE. Pushing the blame around doesn’t help anybody. […] Saying “not my problem” is irresponsible when it hurts users.”

– Linus Torvalds, 11/30/2013 RedHat bug report #638477

I idolize this quote because it’s as genius as it is straight-forward. Why should the user be concerned? Why can’t it just work? Proactive solutions, no matter how difficult to implement, are better than no solutions regardless of politics. A developer understands that giving the expected result to the user, at any cost, is time and effort well spent.

Don’t Fix It If It Ain’t Broke (Unless You’re Making It Better)

Keep in mind that if the user is experiencing your application, and the application is meeting the expectations of the user, then there is no advantage to causing disruption to change that functionality. If the user is happy, let them be happy.

As applications grow and provide more solutions to users’ problems, the aspects of their functionality will need to be modified. Your end user will expect that if they know how to do something effectively with your software, they won’t ever have to relearn those methods. Remember this when you make changes – forcing the user to relearn things creates frustration.

Your application is like a restaurant. If you accommodate for selling fish by stopping sales of steak despite the fact that steak was your best seller, the customers will become very frustrated the next time they visit you.

Be Verbose

Problems happen in software development. Even the largest and most well known software has a bug or two. However, that doesn’t mean that the user needs to feel lost or upset when something does go wrong. The application itself needs to be proactive in helping resolve problems just like the developer is.

When dealing with problems in the application it is important to tell the user what is wrong and why this may have happened, and firmly assure the user that they are not at fault. Offer the user a way to contact someone and let them know that because they have experienced this error someone will be notified.

Remember to be verbose about the issue, but not too verbose. The user shouldn’t concern themselves with what exactly happened and they don’t care about stack tracing or heavy debug output. Give the user information that is meaningful to them (such as links to get help) and log the heavy stuff for the developer to reference. Building applications that handle errors properly is as important to the user as any other functional aspect.

Communicate With Your User

Always give an end user a way to communicate with you and your team. The feedback may help you plan your next steps. Even if the application is working just as you designed, you may find it time to consider how it can be simplified if you receive too many of the same question about how it works.

Allow the end user to report bugs and be proactive about it as well. Always remind them that if they are having the slightest bit of trouble, there is always a way for them to talk to someone to get immediate answers.

Proactivity compliments productivity. Supporting your applications should be considered just as high a priority as launching the application itself.

Pretty Is Great – Usable And Pretty Is Even Better

One of the biggest things to consider is how quickly and effectively a user can find the things they are looking for. Even if your interface is full of cool buttons and fluid animations, it’s still useless if your users cannot find what they need.

Tailor your interface to be redundant and simplistic. For more complex interfaces, offer users a tour or tooltip on each button with an explanation of what it does. This keeps the interface uncluttered while being extremely verbose about the functionality presented in it.

Now, this doesn’t mean you shouldn’t consider design important. Design is always important. However, it is even more important that the design speaks to the functionality of the application. The application’s design should compliment what it does, never the other way around.

Create Applications With A User-Driven Process

Users drive applications, users drive computer programming and users drive business. We understand that, in most ways, how the user will interact with the software is more important than the initial vision we had for it. So plan for how your audience will want to use your application.

I’ll leave you with one last Linus Torvalds quote:

“[…] Why? Because _users_ are the only thing that makes software useful. Software isn’t useful on its own. You cannot say “this is the right thing to do” unless you take users into account.[…] “

– Linus Torvalds, 11/30/2013 RedHat bug report #638477