Build for the User


As software developers, we have an incredible opportunity to build products that can impact the world. That opportunity starts with empowering users and making sure they find value in our products.

When you build for the user, you avoid your own bias and assumptions, and focus on what works best for the user. Ask yourself the following questions to make sure you’re building a product that is valuable to the user

Is the user able to achieve their goal?

Your software should do what you built it to do. Actions in your software should be clear, and results should be expected. Unexpected side effects of actions can confuse and frustrate the user.

It’s also easy to get caught up in assumptions of what the user could need in the future. Once you have validated an idea, stick to it. Avoid customization until you get feedback from the user. It’s often better to get the intentional and straightforward idea out and then revise it over time.

Does my software support different user personas?

It’s essential to be aware of what user personas are using your software. Is it another engineer, a non-technical user, an international user? Understanding your user base and shaping your software to their needs and perspectives will ultimately provide them value.

Does my software fit into the workflow of the user?

Your software can fit into the user’s day in numerous and unexpected ways: at a specific time in the day, after particular actions, in batches, etc. It is vital to be aware of the prominent scenarios and make sure your software supports them.

Is the user able to use my software without my involvement?

Your software should self-serve as much as possible. The user should be able to find the information they need and understand what actions do without your involvement. It gives freedom and autonomy to the user and, importantly, makes your software do the work for you.

Is my UI consistent?

Your UI is how you communicate with the user, making it crucial to pick clear and consistent components. Believe it or not, users are great at picking up patterns and become familiar with them over time. Thus, components from one part of your product should look and behave the same way from another. This will lead to a more natural and frictionless experience for your users.

Is progress visible and easily understood?

Whether your software takes seconds, hours, or days, it is essential to let your user knows what’s happening.

For example, if your software is a script, it’s helpful to know what command is being run, when it starts and when it finishes. Additionally, if the script were to fail, the user is told what step it failed on and why it failed.

While this isn’t an exhaustive list, it has often helped me uncover areas I can improve for the user. I hope this list makes you ponder what you’re building, how you’re building it, and, ultimately, help you provide value for your users.