3 principles of UI design for developers

Last night, I had a bit of a Twitter rant because I was pissed off with Keen.io’s signup/login process.

I’d also just listened to Samuel Hulick and Patrick McKenzie’s podcast episode on user onboarding.

This made me realise I have picked up a few principles for avoiding common frustrations in software UX.

Most programmers, including myself, are not very good at designing user interfaces and interactions.

But there are 3 principles we can follow to make our software less frustrating for users, and maybe even delightful:

1. Remove steps

Make your user accomplish what they want to accomplish with your software in as few steps as possible. We all theoretically know that fewer clicks and shorter forms are generally better.

But we don’t practice it enough. So, look at the most common task people use your app for and literally list down the exact steps you have to take to do that task. Then remove the unnecessary steps.

Nate Kontny wrote an excellent post about this.

2. Design for giving users what they want, not for using features.

It’s so tempting to show off our clever and powerful features. But, wait for the right time to present those to the user. If the timing is right, the user will be delighted. If it’s not, you’re just getting in their way.

Look at your software as a way for the user to do jobs they want to do, instead of a collection of features.

3. Prioritise features by frequency of use

As soon as you have any users, you will probably need to start adding features. But where do you put them on the UI? I know, use lots of little icons! Or put it in a File menu. Or a hamburger menu?

The mistake we make here is to treat every feature as equally important. Instead, list out your features as collections of use cases and place them in the UI based on how often a user needs them.

Jason Fried explains this in a beautifully simple and clear way in The Obvious, the Easy and the Possible.


These are not new ideas. They are simple and obvious once we stop to think about the issue. The difficulty is in doing what we already know. We must force ourselves to build good habits for software design.

Originally published at hrishimittal.com.