Where to start with UX design?

An introduction to how we design and build user-centered experiences

In this context of sharing economies, empowered users and the “Internet of ratings” (don’t google that, I just made the term up), we see a rise of experts, thought leaders and consultants talking about the ever-growing relevance of the User Experience.

This article is meant to give you an introduction to UX design: an approach to what takes place during the process of designing experiences; ones that take into account what we want our users to feel like when interacting with our products and services. But not just any generic approach to UX design: this is Manas.tech’s own way to tackle it. Paraphrasing the Rifleman’s Creed, “there are many like it; but this one is ours”.

If you’ve been working in UX for a while, this article probably won’t bring you any kind of epiphany, but I find it’s always nice to share how one does things as a way to maybe expand someone else’s knowledge, give them a fresh point of view, or get feedback that allows us to improve. So here goes.

User-centered design means working with your users all throughout the project.

- Don Norman

Often, when reading case studies, it’s common to find that they narrate the process of developing a tool or system like if things just magically fell into place. After reading those accounts, one is often left to wonder

“well.. yeah, but how exactly did they do it?”.

Usually, no answer is provided. This article strives to do just the opposite.

There are two basic principles to good design, as described by Don Norman, in his book “The Design of Everyday Things”:

1. Discoverability, which refers to the ability to discover the operations one can do.
2. Feedback, which is simply a signal of what happened.

In short, good design is intuitive and interactive: users shouldn’t have to wonder what to do next, or where to find things, and every time they interact with a tool, they should have a way to know that their action was received, and that something happened because of it.

Building a great User Experience (UX) requires understanding the users, their mindsets, what they are trying to accomplish (their jobs-to-be-done), and the environmental constraints they operate within.

Good questions to always keep in mind are “what is this for?”, “who is this for?”, and “why did we put this here?”. The first question helps you focus on the purpose of what you’re building, what it will do for the user; the second question one helps you keep the user in mind, how their experience will be affected by your intervention; and the third one is a reminder of the decisions that were made every step along the way.

This last question is also a way to ensure that whatever you are building stays as lean as possible, and that you don’t waste time or resources: if you ask “why did we put this here?” and can’t come up with a good, satisfying answer, maybe you should re-evaluate whether it should go there.

What goes into building the UX

The emotions that users experience when they interact with the thing you’ve built largely determine the way they think about it, and how they evaluate it. That is why it’s important to design and build the User Experience with intent. If you can manage to get that right, you can trust that your users will have a delightful experience, and thus they’ll be delighted with your product.

At Manas.tech, our approach to this is simple and straightforward: we start with a concrete user, who is affected by a concrete problem, and every effort we put into it is directed towards helping the user solve their problem or some aspect of their problem, with as little friction as possible for them.

User Research

The first mission is getting to know the user. It’s already been said a bunch of times and you’ve probably heard it before. But it’s never enough. Get. To. Know. Your. Users. There are two main ways to tackle this part:

• Interviews with stakeholders
• Interviews with real potential users

It may sound counterintuitive to hold an interview with stakeholders before interviewing actual users, but it is fundamental to understand the stakes of the project, and the change the team is trying to make in the world. Also, the stakeholders are the best source of information to get a grip on the project’s constraints: how much time, budget and support we can count on. This will produce a Findings Document, that will be of great use when we get to the user interviews.

Interviews with users will ideally be performed on-site, ethnographically, and there we will put our findings to the test, and lay the groundwork for the next step: building Personas. In case you’ve never heard the term, ‘Personas’ is a documentation tool. Though it may sound like one should attempt to depict users as accurately as possible, it is an exercise intended to understand and describe the needs, goals and motivations of a prototypic user.

Once we have our Personas in place, we can begin to craft short stories about them trying to achieve their goals or get a job done, by using our tool in their context. These are what we call Scenarios, and they are useful to imagine how each Persona will interact with our tool in real life.

User Testing

Once we have researched our users in depth, built Personas and had them play out in Scenarios, we can make some educated guesses about the way our tool will be received and used. Still, no guess is as good as the real thing, so the best thing we can do is build a preliminary version of the tool and have some users play with it.

Let’s see how this works in a real project.

Brium

Brium is a tool we built for ourselves, and it has a very simple yet meaningful mission: it tracks the time that each member of your team spends on different activities, by asking them, via chat, what they are doing. A couple of words a day is all it needs to provide accurate timesheets.

So, why did we put this (a chatbot) here (where there’s usually a timesheet)?

It all started out with a fairly simple problem: how can we improve the way we bill our clients for the work that we do?

On one hand, we need to know how people are spending their time, since that information is what we use to bill our clients. The usual approach to billing for worked hours is making people fill out timesheets. But, as we know, everyone hates timesheets: most times they don’t get filled out in the moment, but at the end of the week or the month, and that leaves a lot of room for error; how are people supposed to remember what they did 4 days ago, or how long they were at it?

So, improvement meant collecting this information faster, more accurately, and with less dependency on human action. Put in a few words, the problem goes like this:

You face great resistance to getting timesheets filled out, and when they do get filled out, a lot of it is probably just guesswork or simply made up data. In simpler terms: no data, or mostly fake data.

Let’s say you manage to get people to actually fill out timesheets, and by some miracle the data is complete and accurate. You still have one more hurdle to overcome: accounting still needs a way to keep track of billable, non-billable and billed hours. That’s a whole other headache!

Our approach to this problem was to take it apart into two major components:

• First, the issue of proactive action from users: how do we get people to fill out timesheets, and to do so in a timely manner.
• Second, the issue of consolidation: how do we put it all together so we can bill our clients for the work done

These two components respond to the two kinds of users that operate in this system: employees who log in hours, and accounting/administrators who use that input to bill clients. So any good solution had to encompass the needs of both. We came up with this:

A chatbot that can be easily integrated with messaging services like Slack, Telegram and XMPP chat clients.

How it works

The mechanics are beautifully simple: Brium asks people, a few times a day, what they’re working on. They respond using a keyword. And that’s it.

Administrators can then decide how activities should be reported, and how much or how little detail they need Brium to ask people to report. People can answer with messages like ‘email’, ‘training’ or ‘acme-bizdev: call with customer’ and Brium will understand and create an entry.

What was improved

Back to Don Norman’s principles, discoverability is addressed by making the system responsible for initiating the circuit, and by using a channel that users already use and are accustomed to: the bot talks to users via chat, and all they have to do is answer, like they do with any other chat. Along the same lines, feedback is provided with a message that simply and directly states “Got it” and, in case the user misspells the keyword or that a keyword isn’t recognized, Brium replies with a warning message that lets the user know that they need to check their answer or provide a new one.

As far as the two components we divided the problem into, proactive action from users is no longer an issue, since Brium gets the ball rolling by asking people what they’re working on. This brings another benefit: since users are no longer reporting every few days, trying to recall what they were doing 4 days ago, we get the highest possible accuracy in your reports.

And as far as the consolidation problem goes, administrators can see, at a glance, the status of the billing pipeline. Every entry has 3 stages in Brium: reported, allocated and billed. A simple interface allows administrators to quickly allocate entries to projects, and set them as billable or non-billable. Brium also has an interactive dashboard that displays the broad view of all entries per month.

Simple, easy, efficient. No more cumbersome spreadsheets, a lot less room for human error and missing or corrupted files, and oh, so much time saved!

That’s why we put a chatbot where a timesheet used to be.

What is to be learned

Years upon years of designing and developing custom software and complex information systems have earned us a very valuable body of lessons learned and knowledge about the workings of building experiences.

One of those lessons learned is that the best way to test discoverability and feedback is giving the thing you’ve built to real people and observing them while they use it to try and solve a concrete problem. The reason this works is that it puts together a winning combo: real people, in real settings, with real constraints, producing very real outcomes.

The User Experience design goal, then, should be an intuitive and interactive user interface (UI), one that creates no doubt in the users’ minds about how to operate, what to do next, and the results they should get from each action. UI and UX are often named as two sides of the same coin, and that is because a good interface makes for a good experience.

We also learned that it’s not so important to get it right on the first try; it’s actually much more important to build the smallest, most discardable version of the tool, while maintaining all the functionalities we want to test. And then, of course, test it. Why? Because it allows us to learn fast.

By understanding that whatever gets built, it won’t remain the same forever, it no longer makes sense to strive for perfection: the goal is to build something useful and delightful. And in the process, learning as much as we can, so the next cycle is always more efficient than the one before.