As a long time product manager I have had to develop many new applications and features. Over the years I have learned many lessons. The below guidelines will help you design a good user interface (UI) by focusing on developing a successful user experience (UX).

This article will not focus on specific points of style. Whether you are building a consumer or enterprise product style is very important, but that I’ll let the UX designers cover that topic in more detail.

These 10 guidelines should apply to all features, large and small.  Whether the feature is simple or complex a product manager should think through the guidelines I have listed. I have learned the hard way that even small tweaks to an application can benefit from these guidelines.  Something as simple as whether to use “Close” or “Cancel” can make a big difference.  (see a Cautionary Tale: Cancel is not Close).

#1 Understand the Original Pain Point

It is important to understand why this UI/UX feature was requested (e.g. problem is it trying to solve). If it was a customer request then discover what the original reported problem was (note: this is not always what has been escalated).

Once you know the original pain point ask yourself “Are there any other related problems that can be solved?” Often one thing leads to another.  While you want to be careful of mission (and feature) creep you also don’t want to stop short of thinking through an issue. For instance when I was asked to add Active Directory (AD) keywords to the user profiles of my last product I could have easily added the keywords to help admin’s sort their users, but stop short of solving the real pain point of  providing AD based permissions .

#2 Get To Know Your Users

Understanding your users helps and what they are looking for help you solve a user’s problem in a way that they would expect them to be solved.

Don’t stop with just the persona that is requesting the feature, where a persona is a fictional stakeholder (e.g. user). Ask yourself if there are any persona’s that might object or be confused by the new feature.

Note: A persona  may include a name, picture; characteristics, behaviours, attitudes, and a goal which the product should help them achieve.

Find out as much as you can about all the personas that use your product before you start.

#3 Define the User Story

Do not assume that others on your team have your same understanding.  Ambiguity can easily slow development, irritate the team, and produce lots of bugs.

Whether you are using Agile or not you should always have a user story for every features and thus every UI element.  A user story goes like this:

“As a <role>, I want <goal/desire> so that <benefit>.”

See other alternatives to this format here.

Whether it is a simple button that needs to be added, or a complex user experience you need to be clear on the user story before you begin the design.

If you are working with a UI/UX designer review the user stories with them.   Let them ask questions, and give them answers.  Debate those answers.  Often this debate will result in a better understanding of the pain points and the persona’s involved.  This will also test a user story’s merits, if you can not convince the designer that the user story makes sense you may need to reprioritize.

#4 Develop An Initial Wireframe Workflow

So, now that we know who our personas are and what problems they are experiencing, we can start creating a wireframe, right?

Wrong.

One of the common mistakes I see in many applications and websites is poor workflow.  A feature is technically available, but it is hard to find, or it is found in one location, but not another.  It is always useful to walk through the user stories and see if there are any alternative workflows that make sense.  For instance:

• Are all your users going to start from the same place?
• Is the feature available if a user is not logged in?
• Is the feature different when a user is not logged in?
• Is the UI different for different users types (admin, user, guest, etc.)?
• Does (or should) this feature require permissions?
• Is this current UI the real problem?
• Should this new feature be applied to similar functions?

Really think about the last two question. It’s tempting to want to not over complicate things (e.g. use the KISS principle); however, sometimes fixing a bug or adding a feature is just scratching an itch and the real problem won’t go away.  Adding something will inevitably lead to new user expectations. For more read a Cautionary Tale:   Unexpected Consequences and  Permissions Permissions .

#5 Develop A Successful User Interface

It is time to start thinking about how to simplify the user experience so that users know how to find and take advantage of the feature. It is very important to communicate effectively to the user.  I have been shocked how many times a simple UI mistake has ruined a new feature.

• What language should you use?
• Is there a need for an icon?
• Does user need confirmation?
• Would a pop up / guide message help new users?
• Should you have a link to more information?

Word choice can make a big difference.  A clear and short title helps users understand features. Icons can help users find features, and often can assist in understanding.

Complex features may have different options that require a bit of explanation.  Sometimes that can be handled inline, but too many options or text might overwhelm or confuse the user.  Offer too many options and the user will probably do nothing. So choose wisely. Be sure that everything you add has a valid reason for being there. If it doesn’t solve a problem remove it.

Read  Attention To Detail for an example.

#6 Review Usability

Now that you have solved the user story, and started to develop a solid UI it is time to analyze your UI for usability. You have hopefully already looked a It is your job to ensure that your users not only understand the feature, but that i want in the quickest, most effective way possible. Problems might include:

• Not optimized for mobile
• UI too busy or font and icons too small
• Not accessible to screen readers or color blind people.
• Load time is too long
• Too many steps in sign up flow
• Is there help?
• Do you have examples?

If you are developing a product that is web based you need to think about mobile. Even if your target market is not mobiel you need to consider that  54.34% of web browsing is now done via mobile devices (source: W3 May 2017). With the majority of users on mobile even if your niche of users is not mobile heavy there is likely going to be some crossover.

Another point to consider is that if your product is not mobile, maybe you should add a mobile app to compliment it.

Whether you are using mobile or not you need to think about how visually friendly the UI is for the average users.  Icons are great, but are they big enough to see clearly (or too big)?  Are there too many icons? ¹ Are you including too much text? Are the icons obvious to the color blind?

When a user opens your UI they should immediately see how it can benefit them.  If they do not then they will likely leave and won’t come back anytime soon. To help with this you can add some guides that explain the user interface.  Having user guides is extremely important if you are:

1. Introducing a new UX
2. Using a UX that might be new to your audience

When “swipe right” was first introduced it needed to be explained.  Once it had been in use for a few years with trend setting apps like Tinder many people thought that swiping was obvious to everyone and started to add it to all sorts of apps including enterprise applications. The problem was that many enterprise users were not Tinder users. Not only did users find the application difficult to use, but enterprise users were not happy to find out that they were not hip enough to use the new UX.

Bottom line: A good UI does not need to be explained.  This was pointed out to me a few years ago by a customer.  I had redeveloped a complex UI and had added a whole bunch of tool tips and popup guides. I thought they were necessary due to the complexity of the UI; however, how could I argue with the statement “A good UI should be obvious”.  I had a lot of room for improvement.

¹ Many years agoMicrosoft Office switched from having multiple independent tool bars to a single ribbon menu scheme. I believe the idea was to avoid the problems with multiple toolbars taking up so much space. The new ribbon also allowed them to increased the size of some of the more important icons. Both problems were important to fix; however, I was irritated myself since I was comfortable with the old system and had created custom toolbars that were no longer available. Worse, I noticed that most of my coworkers were confused by the changes. My coworkers were simply overwhelmed with the choices and often could not find the features they were looking for.  The ribbon was a new UX concept and took awhile for users to adjust.

#7 Find Ways To Encourage Users

This often leads to frustration, and for the user to blame you and to instantly lose trust.

#8 Add Rewards and/or Gamification

Gamification does not apply to every feature, but give it some thought.  How can you reward your users for using the application, using the feature?  Is there a reward that you can offer? Can you at least congratulate them in a human tone?

Reward your users and they will feel compelled to use your product. Make them feel loved. In turn, they will love your product.

To be clear “Gamification” does not mean that you turn your application into a game. It simply means that you are trying to use the principles of gaming to encourage the continued use of your application.

#9 Consider Analytics

Whenever possible add analytics so that you can determine in the future if you have made the right choices.  You are not always going to make that right choice.  Worse, users are not always going to tell you when you got it wrong.  In fact, most of the time users will never tell you they have a problem.  They just won’t buy, or will stop using your product.

You want to be able to analyze what features, and options, are being used.  The more feedback you can gather and analyze the better you will be able to refine your application.

If you have already added analytics to your product then you need to review what the analytics is telling you as far as the importance of the feature.  I’m sure analytics was considered as part of step 1, but now that you have moved forward it is a good idea to check again.  Based on the current analytics is the feature still worth developing? What are you hoping to gain?

#10 Define the Scope and Roadmap

Now that you have developed the user story(s) and workflow(s) and considered the UI you need to determine if the feature should be developed as a whole or in increments.

After fully analyzing a feature request, developing the user stories, and considering all of the unintended consequences you may discover that you have an Epic and not a feature.  You then need to consider if you have the bandwidth to handle the whole feature set in a sprint or two.  You might even need to span a feature across releases like I had to when I implemented AD based permissions.

If you have slid down a slippery slope and can’t figure out how you are going to climb out of the hole you dug, don’t worry. Start reviewing the stories and placing those that are needed first (the predicates) at the top.  Sometimes this means that stories that solve high priority pain point will be lower on overall priority because they are dependent on the other predicates stories.  Make sure that you link the issues together. It is important to note that as you build a ladder of features that some of the features at the bottom rungs  won’t be obvious advantages.  Often they are backend changes that development needs to make before the real pain points are made.

It is important to be as transparent as possible and communicate to everyone what is going on. Let development know the end goals, let sales know where you are headed,  and when appropriate let customers know that back end changes are happening.  Sometimes you won’t be able to show immediate progress, but as long as you keep communication going you should be good.

Bringing it all together

Whether you are fixing a UI bug, adding a small feature, or creating a brand new UI take the time to pause and think about the long term effects and goals of your product roadmap. In many cases you will be able to run through the above steps quickly- after all not ever problem is complex. When you do encounter a pothole in the road then take the time to explore fixing it. While often you will chose to delay filling the pothole, your analysis will help avoid passing by potholes that grow to upset the customer experience or those that grow into sinkholes that might swallow your forward progress.

Cautionary Tales

Cancel is not Close

When redesigning QMetry Test Manager we decided focus on providing a multi-tasking UI/UX. Users had been consistent in complaining that the old UI did not allow them to view multiple asset at the same time. To solve this problem we developed a desktop like UX that allowed users to open windows. ¹ The standard window template had an OK and Cancel button to allow users to close the window. This template worked well in almost all cases; however, we had a subset of windows that allow users to take multiple actions. Each action had a separate confirmation so those windows had the OK button removed; however, the Cancel button remained. This consistency was correct, right?

Wrong.

Because we chose to use “Cancel” users felt that it should cancel the previous actions. Many users were confused and afraid of clicking on the cancel button. When the user base was small the problem and was easily explained away and was unfortunately ignored. Eventually a large enterprise customer’s not only complained about the UX, but submitted a “bug” that the Cancel button needed to be fixed– they were requesting the Cancel button to Cancel all previous actions. ² Changing Cancel to Close was no longer an easy text fix, and the relationship with our largest enterprise account was strained.

¹ Many criticized the use of windows UI framework for the new UI as “old technology”. Some of the fiercest critiques came from UX specialists who wanted to use the latest technology and make the UI “mobile friendly”. The reason we chose a windows framework was A) it solved the main UX pain point of multi-tasking B) All our potential users were very comfortable with it which improved user on boarding (another pain point) C) after multiple trials with a separate mobile application we had concluded that our user base was not interested in using our service on mobile phones (Note: Our windows based web interface did work with mobile browsers if needed).
² The request for Cancel to Cancel all previous actions was actually greeted by development as “a feature request not a bug”. The feature vs bug debate is common between development and product managers and is worthy of its own article. For now I’ll just say that I agreed with development. Not only was this a feature, but it was actually a very complicated feature that involved a few technical challenges. To the user the problem was small and simple; however, the solution would be difficult, take a long time to develop, and would not produce a value add.

Providing AD Based Permissions

One of my largest customers requested us to add Active Directory (AD) keywords to our application. They were using AD to keywords to organize their thousands of users and wanted to use the same keywords to organize the users in our application. Since we already supported AD the import of the keywords was actually very simple to add. We could also easily add a column to the user list for the keywords to allow the admin to sort and filter by keyword. Unfortunately, the real pain point was not sorting or filtering. What the admin really wanted to do is assign permissions to our application based on the AD keyword.
This was a problem for many reasons too technical to go into here, but suffice it to say that had we moved forward with only the original reported pain point we would have not pleased the customer. As it was we had to create an Agile Epic issue which we broke down into separate features that we implemented incrementally.

Unexpected Consequences

When I took over product management for cloud based test management software I discovered that the the development team had added the ability to delete requirements.  This was based on a customer request; however, the customer had only asked for requirements to be deleted and not to delete the core data type used: test cases. The button was placed in an unusual location which made it hard to find.

After the initial release few customers were pleased and more customers were actually upset with the limitations. Instead of the new feature showing our users that we were listening to them, they took the new feature for granted and wanted more. Due to the complex nature of our SaaS application and the database schema we could not add the ability to delete test cases without considering a host of complex use cases- some of which were technically unfeasible.  Too late, we were headed down a slippery slope…

Moral: If you are going to do something, then do it right.

Permissions Permissions

A second problem that was created when delete was added to the application was that the original customer just wanted the delete feature.  They had a small flat organization and didn’t care who had the ability to delete an asset.  This did not work for our other customers who either wanted no one to be able to delete items, or wanted the feature limited to specific users.  Adding a user permission for delete had to be considered a requirement for the delete- and many other features.

Attention To Detail

One of the last bugs I solved with QMetry Test Manager was to unify the dialog boxes so that the escape button would always close the dialog box.  Believe it or not this was a big problem for us.  Why?  We had tens of thousands of core users that preferred navigating with the keyboard for speed.  We added keyboard hotkeys to improve the UI for them; however, this caused a bigger problem.  We started to field complaints from our enterprise users- the management team – because users were complaining of inconsistent behavior.    The original spec had defined the dialog boxes to have a close button; however, after v1.0 the original spec was rarely referenced and many new team members had never seen it.  Since a dialog box was so simple it was rarely mocked up which led to many new dialog boxes were created without a close button.  So, when we added hotkeys many dialog boxes would not close with the escape key and our power users complained.

Why was this a bigger problem?  Before the users were making a feature request- hotkeys.  Now they were reporting bugs and telling their management about an inconsistent UI.  To make matters worse other inconsistencies started to be highlighted!  The fix was simple, but finding all of the dialog boxes was a chore for development and QA.

Note: In case any of you think that development should have kept following the original spec.  Yes, in a perfect world that is true; however, if you expect a perfect world, and don’t want to take responsibility for the imperfections then don’t become of a product manager.