5 design tips for product managers

Interactive digital products can become very complicated very quickly. While just a few decades ago functionality of mechanical devices was the primary differentiator that contributed to their success, modern digital equipment tends to require more than an extensive feature list.

The incredible growth of the Web was the major factor in the focus shift towards 'ease of use', 'user-friendliness' and the like. However, it is not always easy to wrap our head around these ubiquitous terms. They now seem to find their place in the feature list of every other product and surely product managers would like to prevent software user frustration.

This series of blogs aims to collect the most typical mistakes made during software development and good practices related to functional and visual UI design, what we often just call digital design.

Don't overcomplicate

Many applications try to be too ambitious and provide an overly generous feature set to their users. Despite the noble intent, users can quickly become perplexed when facing a large number of options within the software application.

Users want quick and easy access to the main benefits of your product. Provide them just that. Too many features in a UI/application screen can lead users into a state of analysis paralysis and cause them to develop a negative emotion towards your application. Also, you can save a considerable amount of development time too by skipping unnecessary features. Go through your list of functions and think it over:

• ‍Is this a function that users will actually recognise?
• Do I require this input for a reason?
• Is this the most elegant, most automated way of doing this?

If the answer is NO, you are probably better off leaving out or redesigning those specific features. If the answer is YES, you might still try to:

• ‍Use progressively appearing controls as they turn out to be needed.
• Split your complex form into steps. Each should contain only a few controls.
• Hide your special cases under an Advanced tab

In any case, when the UI is getting overly complicated, time may have come to reconsider whether or not you are employing the best possible 'metaphor' to represent your data.

Don’t be smarter than your user

Have you ever clicked the wrong category under Google search? You wanted images, but suddenly a map popped up? You tried to get the news but all of a sudden you got videos? You probably blamed yourself: "Oh silly me, how can I always click the wrong button?”

This is how: You tried to use the tool based on your previous experience. However, Google "intelligently" rearranges the category buttons for each search. If you don’t pay attention, you will end up clicking the wrong category. The tool tries to make your life easier, but eventually it makes it harder.

The  task of the user interface is to help the user achieve their goal. For this to happen, it must be simple. As the well-known saying of Albert Einstein goes:

Everything should be made as simple as possible, but not simpler.

Computers are magnificent calculating machines. We like to think that we are on the verge of making them so smart that they know their way around the human world. But until that happens, machines just follow rules that WE teach them.

So should you make it smart or not? Absolutely, make it smart! Optimise away, but only as long as

• ‍It will almost always make the right decisions
• It behaves in a predictable fashion
• Mistakes are immediately visible
• Mistakes are reversible.

Stay consistent

Consistent interfaces allow users to develop usage patterns — they’ll learn what the different interface elements look like. They will recognise the same buttons, tabs, icons at various places and realise what they do in various contexts.

If you have repeating elements or blocks throughout your application's UI, it is best to use the same elements to achieve the same functionality, unless you have a really good reason not to.

Also, users will try to identify and use elements in your UI based on their previous experience with other UIs. For this reason, it is always a good idea to stay consistent with where the world is heading and build your UI out of familiar controls and design patterns. You will make your users quicker at achieving their goal, and at the end of the day, that’s what counts.

Of course I will not talk you out of innovation. Nope. Innovate to your heart's content if you are confident that your solution is so much different from the rest AND straightforward to use. Just don’t invent new patterns for problems that don't require it.

Who is my user?

My grandma has a bad hearing, so she got one of these $1000/pair hearing aids for her 85th birthday. It is as small as a fingernail. Guess what: she couldn’t use it at all. The device is so small that she was struggling to learn how to force the tiny earbud up in her ear canals, not to speak of replacing the microscopic battery inside. A complete waste of development effort and money.

An incredibly large number of developments just don’t care about actually who is going to use a product. This either leads to

• surplus functionality, 
• missing features,
• unusable features.

Don’t plan functions that nobody will ever use, but do cater (and even provide shortcuts) for functions that are frequently needed. This sounds obvious, but still it is one of the top mistakes that are made with many products. "Ok, but how do I go about that?" - you might ask. The way to achieve this is getting an idea of who you are developing for. Go talk to the real people in the domain, understand their goals and needs. If possible, make some ethnographic study in the environment they work. This way you will be able to build a profile of an imaginary person with real goals. Think about how he/she currently manages to achieve those goals, and how you could provide a better alternative. You may even give them a name, e.g. Mary Clerk. In design terms, we call this a ’Persona’. The main deal is that when the time comes to make a decision about how / whether to implement a function, instead of wondering ’what would the user want?’, you can ask yourself:

• "What would Chris want? Would he want to print this?”
• "Would Uncle Joe download this in .CSV format? Does he know about .CSV at all?”
• "How would Grandma Judy change the volume?”

When  you start to picture Grandma Judy fiddling with the 1mm-tall volume slider, you will immediately recognise that you are developing the wrong  product.

Don't let the implementation drive the UI

The user has no idea how your system works inside - and just as well, as this is not their business. They put their data into the UI, and that's their business. You use that to provide them results, and that's yours. Too many applications expose their dirty laundry, offering features that reflect the system's internal view of the data rather than users' understanding of the problem space.

In modern development, the tasks of system design and system implementation are separated from each other for a reason. This ensures that decisions about the user interface are not made based on how it is easier to implement, but how it makes sense from the users’ point of view.

If you liked this article, you might want to download our whitepaper 'Designing Intuitive and Lovable Software User Experiences' to share further design tips for product managers.