Articles

Eric Goldman for KTi

Introduction 

As UX designers, we’d all like our users to say that our apps are intuitive, easy to learn and use, and powerful without being overwhelming.

The problem is that these statements don’t convey anything to you, the designer, on how to actually achieve them. Just how do you make a UI intuitive? What makes an app easy to learn and use versus difficult, and precisely how do you give an app the power it needs to satisfy all its user’s functional requirements, without overloading them with detail and instruction?

This article attempts to answer these questions by presenting you with a process to follow, to design your next project’s UX. The article is a summary of Step 3 in our COVID Response’s course on how to launch and grow a Startup: Seven Steps to Independence ©. The course is free and available here without registration, if you’d like more detail.

The answer to the question how do you design an intuitive interface, is easy: you make the app behave the way its users expect it to, and show them what it can do and how to do it, in ways they can understand at a glance.

Easy answer, but understanding the users heads well enough to know what they expect and how they will interpret the UI, is where it gets tough. Let’s see if we can make this easier. We’ll start with a definition of a UX.

The UX you are designing must begin with the first touchpoint your users encounter, and encompass every touchpoint for every possible interaction. Obviously, this varies greatly depending on your specific situation:

If you’re developing in-house apps for your organization’s users, their first interaction with you is likely to be during the requirements analysis phase. If you’re a Microsoft Teams apps developer like we are, the first touchpoint is when the prospective user finds our app, Kippa’s listing on AppSource, the Microsoft app store.

Regardless of the cycle your users traverse to become a user, the key is to make it as easy as possible for them to move to the next stage of interaction. This means making it as easy as possible for them to:

• Acquire your solution. If its sold as an app, this means making it easy to try, install, and buy it. For in-house solutions for users inside your own organization, it means making it easy for them to find the app, install it and then onboard.
• Use your solution. This is the heart of the intuitive problem and we’ll cover it in more depth below.
• Get support and help.
• Get inspired, if your app or solution is one they use to create something. To do this, you need to be an expert in the problem domain, so that you can literally show the user how to do a better job.
• And ditto for every time they interact – positive, enjoyable experiences, every time, is the goal.

The 3 Laws of great UX’s

Designing something for others to use, requires you to get two fundamental things right:

1. The functionality you users need, to solve their pain.
2. The form of your solution. The shape and style, or, as it’s more traditionally labelled for a UI, the look and feel. 

Sad to say, today, most designers focus on the surface glitz, often producing a beautiful but often useless product.

Consider the iPhone. It’s beautiful, and yes, it changed the world with its incredible functionality. There is, after all, an app for everything today. But Jony Ive designed a hand-held device that’s so slick and slippery, you can’t hold it in your hand! The device itself, the hardware, is a total failure as a functional design.

We all hide our phones’ sleek and elegant design in cheap plastic cases, to protect them when we drop them. A few finger-shaped contours in the sides would have solved the problem. Ive must have understood the need to hold the thing in one hand, but he is, IMHO, the King of the form follows function school of design. Until he messed with it, Apple’s UI design was brilliant. He turned it into something which may look better, but is definitely harder to use.

You’ll have to work hard not to fall into the same trap. Your solution must provide its function in a way which pleases its users, and appeals to their tastes. And if you have to err on the function side, if that makes the solution look a little less classy, go for the function.

As you design your user experience, follow these three laws for each touchpoint:

1. Always work from the user’s point of view and never your own.
2. Make everything as easy as possible, even if it means you have to do a bunch more work. And it does mean that, which is why so many people don’t do this.
3. Make what the user can do, and how to do it, obvious.

1. The User’s POV

It’s extremely difficult to put yourself into someone else’s headspace. You have to keep reminding yourself that your users know nothing about your solution or you. The pain they are experiencing is related to their job. Its personal. It often produces strong emotions. All of this is tied up in the way they do the job.

And your job is to understand how they do it, and why they do it this way. Only then can you start figuring how to simplify it, speed it up, and improve their performance.

There really is only one way to learn enough about the task to do this. Observe them at work. For days, to make sure you see everything they do and how they go about it. As I said, it’s a great deal of work.

But when your bosses carp about the time and cost, tell them that solutions with quick learning curves which are easy to use, dramatically lower support costs. They significantly boost productivity, almost instantly. The cost savings and increase in performance are worth it.

When you’re performing this initial observation of your users, try not to think about any possible solutions. Just try to understand why the user does things, and in what order. Pay particular attention to the information they need while doing the task. Every time users refer to a document or look up a data value, you have the opportunity to predict what they need next. Imagine the pleasure and surprise you’d generate, if when the user reached this point in doing their job, the needed information filled itself in on their behalf, and all they had to do was click submit.

A common piece of advice given to all would-be authors, is to show, not tell. In literature it means using words to paint pictures, not to describe the action. Compare: Her heart was racing, she couldn’t breathe and her sweat stank of fear… versus she was scared.

Your UI must show your users what they can do and how to do it, not tell them in words. When your UI needs a text explanation, it’s failed the intuitive test. The app’s functions and controls must be incorporated in the UI itself. Some people call this surfacing; your users can see what the app offers and how the feature works. I prefer the word, Articulate. An articulate interface, is, literally, one that talks to your users in a way they immediately understand.

2. Make it Easy

The importance of making things easier cannot be over-stressed. The only time we enjoy using a product or service is when it both does what we need it to do (functionally solves our pain), and does so in an easy, fun way. You don’t sweat to make it happen—you open the box or launch the app, and from there on you use it, without much thought, to do everything you want to do. From the moment you began to interact with it and it said: Start Here, you just seemed to know what to do and how to do it.

If you doubt the importance of making it easy, consider automatic transmissions. One of the earliest automatics was the Hydra-Matic Drive that Cadillac announced in 1940. The car cost around $800 and the automatic was an extra $60—about 8% more than the column-shift. It used more power than the standard transmission, and thus made the car slower in both acceleration and top speed. It used more gas and was thus more expensive to run. The automatic transmission required more frequent and more expensive maintenance. All told it sounds like a terrible idea. But it made it easier, and today most cars are automatics. Yes, modern automatics are more fuel efficient than the average driver, but they still rob some of the engine’s power and are more expensive to purchase and operate. It’s the ease we’re all after.

The way you make your solution easy to use is to anticipate what your users are trying to do and give them all the information they need to do it. It comes right back to getting inside their heads.

Make it Articulate

The ways you do this are:

• Surface the controls so that they are visible.
• Make their icons meaningful to the user and if you don’t know how to do that, ask your users!
• Make the ways your solution provides the function obvious to its users.

Keep reminding yourself that the broad range of UI controls available these days, ensures that some of your users will not recognize your symbols. Just because you know what the control does, doesn’t mean your users do.

For example, look at this sample of a Graphic User Interface or GUI, window.

The function of the little box, the elevator, which slides up and down as you scroll the window (Title 2) is reasonably obvious: it shows you where you are in the document relative to the whole document, and it allows you to grab it and scroll to a place in the document. 

Good design here, for this grab and scroll feature, would be to pop up a little dialog to show the page numbers as you scroll by, and the headings of the document as you roll past them. This way you know when to stop scrolling. That’s making it articulate, and much quicker to find your place.

But still…It is all only obvious, provided you understand GUIs and scrolling and documents which extend beyond their visible portion. Which is to say it’s not obvious at all to a first-time user of a GUI. You will have to work very hard to overcome this issue because the parts of your solution you are designing are very obvious to you, and completely obscure to your user.

A UX Design Process

Getting to MVS

Your Minimum Viable Solution is a phrase borrowed from Eric Ries’s book, The Lean Startup. He called it your Minimum Viable Product or MVP, but as our course was aimed at either a product or a service, we called it a solution.

The Lean Startup is a brilliant approach to designing and building anything, and is embodied in the Agile Sprint development methodology. It suggests that you build the least possible amount of the function you are developing, and then hand it to your users to explore and provide their feedback. You use this input to shape the next sprint. And you keep doing this until your users tell you they want to start using it.

To decide which features and functions comprise your MVS, you begin by picturing the whole solution in your mind. Let’s call this big mental picture, your Best Possible Solution, or BPS. This is the version which completely satisfies your requirements or functional specification. Don’t make this vision too detailed on this first pass, you don’t know enough yet to do that. Omitting the details for your BPS now is good because you are trying to see the forest—the view from 50,000 feet.

Once you understand the total scope of what you have to do to solve your user’s pain, you take each touchpoint you have considered as the BPS and determine if its essential in the MVS. Can the user use the solution without it, albeit in a less than optimal way?

The mind map below depicts the process you cycle through to accomplish this type of design. A few words of clarification before we get to it:

• A solution consists of one or more touchpoints,
• A touchpoint consists of one or more functions,
• A function consists of one or more components,
• A component consists of one or more artifacts. 

A Solution Design Process

You begin by finding a quiet place in which to sit and think. You’re going to picture yourself using your solution as your users will do: the Walk through Solution, in the map’s first step.

In the second step, you imagine every Touchpoint (every interaction). Try to think of every time your user touches some part of your solution, or interacts with you, and list them all. We’ll call this list your Touchpoint Catalog. The format you use is optional—here’s a sample of one in Excel.

Using Excel can be a little cumbersome as you when you add entries you sometimes have to shift cells around. That’s why I often use a map:

For each touchpoint, determine the functions your solution needs to perform for this point. Then for each function, list the components and artifacts they need—screen UI layouts, printed forms or reports, etc.  Repeat the process for each function and its components, for each touchpoint. Then repeat the whole process for the next touchpoint.

The map  below depicts the process for designing components. The steps for how to think about each component begin with Type? In the top left. This type is obviously the form the underlying format of its component/artifacts.

Ask the 5 questions as you think about each component. For example, you start off by asking yourself what the user’s pain or need is at this precise moment. This may well have nothing to do with your solution yet! If the user is exploring your solution with a view to deciding whether or not to use it, for example, the need at this moment is for information only.

The components are the parts of your solution which provide the required functions: all the website pages, the screens of your app, the user guides, etc. 

The reward for following a process like this is that your users will love using your work. They’ll recommend it to others, they’ll give you enthusiastic feedback on how to make it even better. They’ll be loyal fans.

This is obviously a high-level overview of the process. If you’re interested in learning more, go ahead and download the course. It’s free and you may find the Steps on marketing and selling useful, too.

Have you joined the ERP Community yet?

Membership is free! 

JOIN HERE!