As difficult as it can be, you must give up the fantasy that you’ll get everything right in the first version of your application. You have to fight against becoming paralyzed because you’re unwilling to release your application until you make everything perfect.

Strike the right balance between accepting that you’re releasing an imperfect product and determining to get things right.

Jeff Weir explains this well:

Having developed applications and websites for some time now, I can tell you that it’s still difficult to hear criticism. As much as I pride myself on my thick skin, I still want to hear the user say, “It’s perfect. You don’t need to change anything!” To date, I don’t think I’ve ever heard that, and I don’t expect to any time soon.

A skill that I’ve crafted over many years is the ability to distance my personal value and self-worth from the outcome of my applications. At the risk of sounding like a psychologist, I’m going to state this again because it bears constant repeating.

We need to understand that if our design fails, it’s not a personal failure. We have to explore what we’ve missed or the questions we might not have asked. If our design doesn’t work, it’s because we failed at getting the right information; it doesn’t mean we failed at being a programmer and should consider another profession.

Having the right mindset will allow you to be less defensive when receiving feedback. It will also protect you from getting discouraged or feeling like a loser if you built something that users don’t like.

Users can be demanding, but my experience has shown that when we include them in the development process, they have a better understanding of how to communicate what’s missing. Additionally, they have a better understanding of what they’re asking for.

Users that have worked with me in designing an application end up learning the difficulties and technical limitations. We need to acknowledge that just because our users don’t have computer science degrees doesn’t mean they aren’t adept at helping us solve technical problems.

Developers have a tendency to be code hoarders, to fall in love with code and want to keep it forever. We leave it in our applications because we never know if we may need or want to repurpose it. Our applications become a virtual storage shed for all of our coding ideas.

Certainly, code repurposing has its merits, and there is no reason to reinvent the wheel for every project. However, it has its drawbacks. If we continually institute the same code for each project, we run the risk of implementing the same solution to every problem. It can become more difficult to provide new solutions to usability concerns. We end up sizing up each user request as an exercise to prove that “we’ve got code for that.”

If our application doesn’t meet users’ needs, we need to ask basic questions:

The immense challenge of building an application makes it easy to drift from these questions. Still, building a great application may mean we have to go back to the beginning. It may mean we have to start over and revisit our vision. We might have to reboot our assumptions.

I know how hard it is to throw away code. I know you’re thinking, “This code took me months to figure out! Now you want me to throw it all away because my users don’t need it?”

Yes. That’s exactly what I want you to do.

When we put our code before our users, we move away from the vision we had in the first place. Our job is to make great applications, not great code. If your code doesn’t support your vision for the application, then it needs to go. It’s as simple as that.

Challenge yourself and your team to revisit your project’s vision. Continually take time out of your development cycle to ensure that you’re heading in the right direction. Make sure that the choices you’ve made are best for your users and not because you’re afraid to delete code.

Be bold and willing to re-evaluate assumptions to make sure they still have merit in the light of new discoveries.

This is why it’s so important to have a team mission statement or manifesto for your project. By having a clear definition of what you’re trying to achieve, you save yourself the time of getting off track. Revisit your mission statement often, and don’t hesitate to use it while making difficult design decisions.

I’d like to make one final point before we conclude. Some of us developers tend to be an egotistical bunch. There’s a level of self-importance and power that comes with creating applications that users rely on. With a mouse click or stroke of the keyboard, we can change everything!

On the flip side, many of us have an incredible pressure to be experts and have it all figured out. Many times, we find ourselves alone, and it’s easy to get disillusioned or frustrated. In short time, your users become the enemy. They represent the riotous horde just outside your door chanting, “When will it be done?”

Take a deep breath; user-centered design requires soft skills. You have to patiently listen to your users and genuinely desire their feedback. I’m not saying you have to agree with what they’re saying, but you should, at the very least, value it. Remember that at the end of the day, our users have a lot to teach us.

I’ve had users give me suggestions that are so embarrassingly simple that I don’t know how I missed them. After all, I’m supposed to be the expert! The reality is that it’s impossible for me to see everything. Developing applications requires such an intense focus on the smallest details that I have to concede my ability to catch and think of everything.

To do it right requires help, and there’s no better group of people to help us than the users themselves.

That’s the beauty of the user-centered design approach. It protects us from the failed curtain unveiling, the point where we unveil our application to a dissatisfied group of users. It gives us a roadmap that maintains our empathy for users by continually focusing on their experience.

What I’ve offered in this book is a quick introduction. There is a wealth of knowledge in the usability and user-experience worlds. Follow the experts and learn from them. If you need help finding some experts, see the section Chapter 11.

Encourage your own creativity by taking time to explore new things. Create a plan to help you implement your user-centered design strategy. Gather feedback from your users and ask them specific questions about the problem space. Create prototypes to test early design considerations, and let your users evaluate them.

Finally, conduct detailed and organized usability studies. Measure your application’s usability by observing users as they try to complete tasks. Document their comments and use data to support your design decisions.

Implement the user-centered design methodology outlined in this book, and you’ll pursue the very best for your users. When users know they’re at the center of your application’s focus, they’ll continue to reward it with their preference and loyalty.