How to take care of UX even when you don’t have the resources to have an expert UX designer on the team.
At Datafy.it we’ve managed to start taking good care of UX, regardless of not having the expertise or the resources. It doesn’t take a lot, contrary to what some people think. By devising and using some simple tweaks we’ve managed to make a big difference. I wanted to share what we’ve learned through the things we’ve messed up on the way.
I address the two issues that make teams forget about UX: lack of resources and knowledge. Not having enough resources or knowledge is no excuse for putting UX on a side-track.
This usually happens to small teams. The reason being that in big teams it is scarcely a problem to hire a specific person (or a whole team) devoted to UX. Small teams or startups can’t afford that. On top of that, when it comes to web and mobile apps, teams usually consist of mainly developers. Overly-technical developers that are sometimes just a bit too clunky. I know the feeling because I am a part of such a team. The good news is that designing pretty good UX is not hard at all.
Mistakes made and lessons learned
Before the version of Datafy.it available today, there were countless others. When we developed the first version it was so complicated to use that people were reluctant to do it. And when they did, they were constantly asking for help. Most of our calls and emails were customer support related. That meant spending a lot of precious time.
Today, the one thing users point out is the ease of use. Needless to say, we are not spending any more time explaining how to use our app.
Through the process of developing Datafy.it we also learned a couple of things about developing user experience. And the way these things usually go, we had to make a few mistakes before learning the important lessons. Here is a list of 7 mistakes we made that made us learn 7 valuable lessons.
1. Forgetting about UX because of lack of resources
A common pitfall is that no one on the team is in charge of UX. If no one is assigned, you can’t expect that it will magically be taken care of. Teams don’t assign anyone because it’s not possible to get a UX expert right away. Unfortunately, that’s what makes them think that UX can wait. Because in an ideal world, you would have a person (or even a team) that would focus exclusively on UX. In real world, you can’t afford that, so you simply ignore it all together. Our problem was that we didn’t even think about it. And it was easy to miss it because it’s not like all we did was bad. Yet, what happened was that anything that was done well, UX-wise, happened more by chance than anything else. At one point, I took over UX. It proved to be incredibly helpful to have one person assigned to UX. It didn’t matter that I couldn’t devote 100% of my time to UX. It didn’t matter that I was no expert. I took over and started to get the wheels moving and it filled a void.
Lesson: Someone needs to be in charge of UX. Assign someone right now.
2. Forgetting about the user
When you don’t have anyone focusing on UX it’s easy to forget about the user. When any kind of debate regarding our app came up, it usually looked like this (a very simplified view): CEO was defending the big picture and marketing point of view, CTO considered the technical stuff and that was it. What was missing? Someone constantly putting themselves in user’s shoes and defending their point of view. When that’s missing, it’s easy to make a decision that’s not friendly to the user. Once we assigned someone to UX, thinking about the user in every debate became a second nature. Now, whenever we start discussing a feature or part of our app, I am constantly thinking about the user — how will they perceive it. What will they gain? Is this in any way bad for them. The debates are now more balanced which means our decisions are finally well-rounded.
Lesson: Someone should always consider and defend user’s point of view.
3. Lack of communication between developers, sales and customer support
Here’s the thing. When thinking about UX you have to know what the actual users think, what their pains are and so on. Not guess it, but hear it from them. Our team at the time was 4 developers and our CEO, who was taking care of sales, marketing and usually customer support. This is not unusual since developers are often quite content in their own bubble and, therefore, don’t really communicate with the customers. “It’s not their job”. Well, maybe that’s the case, but the consequence is that you can never really know what the users want and need and where your app is failing in the real world. You make guesses and speculations. If you want a decent UX, this won’t do. This was a problem for us. For most of the time, we (developers) were developing and CEO was selling and doing his stuff. Although there was plenty of communication, it was not enough. I first noticed this by chance. I started talking to the CEO about a customer support call he just had. He told me about it, and I immediately realized one of the problems of our app. I would never have caught that, if I hadn’t heard a customer had had a problem with that. So the next step was obvious. I asked to be included in all customer support related emails and calls and I partly took over that part. This simply meant CEO forwarding me emails and telling me about any customer support calls he had. Even today, this proves to be one of our most valuable sources of information for UX design.
Lesson: Include developers to customer support. Sales and developers should be in constant communication.
We have to constantly focus on not falling into the trap of overcomplicating. The first version of Datafy.it had a lot more features than the current one. Most of them unuseful, which we didn’t realize at the time. Instead of having a simple search engine, we offered features like scheduling, starting and pausing, different kinds of export. This meant a lot of work for us as well as the users — they couldn’t focus on the task at hand because of all the distraction.
The scary thing about complicating is that it is so easy to achieve, without even realizing you are doing it. This is true especially for developers. At any given moment we have 30 ideas for new features regarding any aspect of the app. They all sound great in your head, when in fact most of them are ridiculous. This can be an issue, because if you follow all those impulses you end up with an unusable app. What we’ve learned is that we need to be critical of ideas for new features (as well as existing ones). For each one we have to ask ourselves whether anyone will use it. It is important to assume no one will use it and move forward only if we have evidence that says otherwise. The same goes for existing features — if no one is using it, then just cut it. You’re not doing anyone any favors by supporting too many features.
Lesson: Simplify. You don’t need that many features.
5. Use of technical language
At Datafy.it our fundamental feature is searching, so we charge based on the number of searches. Today we call them searches, but when we first started we called them queries. To us, it made perfect sense and it didn’t even cross our minds that there is anything wrong with that term. Eventually, we realized that most people didn’t understand what we mean by ‘query’. And that’s something that happens way too often. It makes sense — we are a group of 5 IT guys and a lot of technical terms sound completely normal to us, simply because we are used to them. The problem is that we don’t know when we are using technical terms. We are deaf to that. It’s only natural, but it can be problematic when developing an app that’s meant for non-tech people. It’s surprisingly difficult to do, especially when you are surrounded by other engineers, but we found that it is crucial to use simple, plain English. This goes for all the communication/texts you deal with — buttons, features, notifications, alerts, emails and so on.
Lesson: Use plain English.
6. Not listening to the users
As mentioned earlier, we can never really know what the user experience of an app is like, if we don’t communicate with the users. We’re simply in the dark. So when we develop, we rely on our assumptions and guesses. Make no mistake, we are confident in our gut feeling of what works and what doesn’t. We feel we know what the user needs and wants. But at the end of the day, without including the user these are still just wild guesses. That’s why listening to the users is so crucial. Users are the best source of information regarding UX of your app! Both in quantity and quality. If you are not using that you are making a mistake. Listening to users means many different things. It means asking them for their opinions — users are phenomenal at pointing out the pain points of your app (directly or indirectly). When a customer talks about a problem, a concern, an uncertainty, a complaint, there is a deeper problem hidden behind it almost every time. It’s probably something everyone has been struggling with, but didn’t bring it up. By listening you can unveil it and do something about it. And don’t forget about user testing. It is extremely effective and you can learn so much from it. And again, it doesn’t matter if you can’t do it perfectly. Ideally you would be doing user testing all the time on, on different people and on the actual users. In real life you can’t afford to do that always. We can’t either. But we still test our app before we release a new version or a big new feature. And we don’t necessarily test with the actual users — we get help from friends and colleagues.
Lesson: Listen to your users. Test new features/designs with actual people.
7. Failing to adopt basic heuristics
Surprisingly, sometimes we fail to follow the simplest rules. Following some basic principles is no rocket science — all it takes is being critical and disciplined. But with all the other concerns it is way too simple to forget about the basics. We keep reminding ourselves (because it is so easy to forget) to follow the two basic heuristics: consistency and feedback.
Lesson: Follow some basic principles — consistency and feedback.
User Experience matters
After going through all those mistakes, it’s always so rewarding to get a positive feedback about the ease of use of our app. Seeing people using it the way we imagined, without having to explain it, makes me feel like we did a good job. And more importantly, it empowers our users to really focus on the task at hand.
All it took were some simple tweaks to the way we work. Anyone can (and should) do the same. Your users will be grateful.
Author: Žan Anderle