How do you know when you have a User Experience problem with your web application? I sat down with our UX lead Mariana Lopez and asked her to talk about some common Red Flags to watch out for. You can see the video of our skype chat or read the transcript below. What sort of common UX problems do you run into? Tweet us at @ArinSime and @nanalq and we’ll be happy to retweet you!
(Edited for brevity and clarity)
Mariana Lopez (UX Lead for AgilityFeat): We’re goign to talk about red flags. The important thing to keep in mind here is that UX is not an exact science – it depends on your application and users. If you find yourself saying these things, you need to consider it.
UX Red Flag #1 – “It’s just a training issue”
If you ever find yourself saying “It’s just a training issue” when someone comes back with an issue, it’s worth considering why you are saying that.
Sometimes when we design our applications, we want users to come up to them and use them right away, and other times we design for expert users and we make compromises in usability in order to allow more efficient use.
If you are designing applications that require the user to learn how to use it on their own, then this is a big red flag.
Arin Sime (AgilityFeat CEO): This reminds me of a client that I have been doing some agile coaching for. We were talking about changes that they needed to make in the product. I’ve heard it a couple of times in a meeting with them where they say that “we have this bug, but we don’t need to fix that, it’s just a training issue.”
Now if they were here with us right now, they would say that “but our users are expert users” like you were saying, but their users do still need to learn how to use this app themselves, so how do you know where that line is?
Mariana: The line is when you are creating something and allowing it to be harder to use, the benefit or reason for that should not be that it is easier to develop. There has to be some benefit to the user. For instance, allowing them to use F-keys is ok because they are probably expert users. But just saying “we’re not going to fix that, it’s a training issue” is being lazy with your UX.
UX Red Flag #2 – “We have so many cool features … but users don’t use them!”
Arin: Let’s talk about our next red flag, somebody who has way too many cool features in their app.
Mariana: This is something you get a lot from clients when you start assessing their app. People are very proud of what they’ve developed, but it’s followed by a statement that users are not using them. This can be a really big red flag.
It can mean that two things:
1) You are building things that people don’t want
2) Your information architecture is hiding away important features
Both of these are usability problems. In the first one, you are wasting time building things that people don’t want. You can solve this by doing user validation beforehand. This is where validating the concept before building it is very important.
Write down a list of prioritized features that you want, and just build the first five. Archive the other ones and if they’re still very important features to you after the next release then go ahead and build them.
In the second case, if you are building very important things and people are not finding them, then you need to spend time on your navigation and giving people hints of what they can do with your application. Think of how a door gives you hints to push or pull it. You can do the same in software.
Arin: That makes sense, so this is a really good example of how incorporating Lean Startup, Customer Development, and Agile techniques into your UX is so important because we’re not just going to throw out to users all those features up front. We’re going to just build the most important things first, and then we’ll wait to build the rest until we have some kind of evidence from our customers that they want them.
Mariana: Exactly. This is where validating your ideas and iterating over them really becomes important for the usability of your tool.
UX Red Flag #3 – “The screen is not cluttered … we just have a lot of information to show!”
Mariana: This happens a lot when you start designing and building things, people tell you “we need this” and “don’t forget about this”, and at the end of the day you have a very confusing screen.
There’s a tradeoff: You can show everything on one screen and save users time, or we can choose to separate things out and use our information architecture. It’s true that if you put everything on one screen that it’s all there for the user, but it’s also true that people might miss things.
It is important to structure your pages to have a hierarchical structure. Visual design and elements help a lot to make it not look cluttered. What information is truly essential to the user, and what information is just making noise?
Arin: I think this is a really interesting red flag to consider because everybody talks about “Big Data” and having massive amounts of data and analytics about their customers. I was in a meeting today with a customer and I heard them talking about mashing up data in their system with a 3rd party API. They were talking about what data to display, and stakeholder was saying “I want it all, just give me everything in that API!”
I think we’re tempted to do that because we have so much data these days, and we are tempted to say “Let’s just throw all that data out there and let the user make sense of it.” It’s like we think that having all this data makes us look like a more comprehensive product. You’re saying that’s a red flag.
Mariana: It is a red flag, and I’m going to tell you why. You can show a lot of information, you can make things complicated, but they have to look simple and they have to be easy to use.
I’m not saying you can’t show a lot of information at the same time, I’m just syaing it needs to be structured. When you say “the users need to figure it out”, that probably means the designers didn’t take time to figure it out for them.
You can show analytics, you can show graphs, you can make combinations of data. The important thing is the screen doesn’t look cluttered, that it doesn’t look impossible to dechiper, because then we push our users away. They may not be able to use the application to its full potential.
Maybe what we are trying to show in one page can be shown in two, maybe it can be shown in tabs, maybe it could have had options to hide away things.
Sometimes when screens are too cluttered it’s because we’re translating too much of the decisions that users have to them and we’re not using the proper defaults. It does take a good designer to make decisions for users, but it also simplifies their lives if you make the right decision.
I’m not deterring people from showing lots of information, but it has to be structured.
Arin: So in that meeting that I had the developers probably were going to just throw everything in the API on there. We should have pulled a UX or design person in there to think it through. That’s a great red flag for us to end on.
Mariana: Exactly. Why is that piece of information so crucial that we are going to spend that space on it? If you can convince me why, then we will include it!