How to Create the (Almost) Perfect User-Centric App
Among the many problems in the design universe, one that has probably bothered people the most is the DDD: Designer-Developer Disease. Have you ever experienced it? The complication lies in that one cannot get vaccinated against it. And the interesting thing is that the sufferers are neither designers nor developers. It’s the end users.
I think you might be picking up the idea of what DDD is about. Simply put, it’s the designer chalking out the interface from his/her own POV, the developer then enhancing it from his/her own POV, both putting the user’s POV off the radar.
DDD (as a friend of mine calls it) has its symptoms spread across several interfaces, be it mobile or web. So, what causes this disease?
Lack of Understanding
Merely understanding the design tools, the fundamentals of design and technicalities are not enough to build a good user interface. These are, in fact, not even close to the basic requirement of a good design. The most important part is to understand the end user:
- what are they thinking?
- how will they react to an experience?
- why are they using the app?
- how does the app intend to solve their problem?
- what can be the environment in which the user is using the app?
It is interesting to know that there will be multiple answers to each of these questions. With proper thinking and analysis, the team can actually get itself in the users’ shoes.
Steps that can help here are:
- create user personas
- take real-time data from real people (not just from the internet)
- build a prototype and test it with real people
If there’s no time for all these, then try investing time in creating the user persona elaborately. Inclusive design is essential for building a good application.
Unfortunately, it is very common for the creative team to assume certain cases for the user, and design an app based on this tiny puddle of assumptions. It’s hardly any better than a puddle because it is, ultimately, a messed up theory of guesses that either applies to a small set of people or to none.
Too Much Knowledge
It sounds strange but it’s true, and there’s nothing wrong in it. When we go on doing the same work again and again, we kind of get stuck in the same pool of ideas, thoughts and knowledge. We tend to forget what it’s like to be outside the pool. It is common human psychology.
Sadly, our naive users stand outside this pool. And we, the all-knowing creative and technical teams, forget that they do not code, that they do not Google the same geek stuff that we do, that they have no idea what they’re supposed to do with those buttons we placed on the screen with the obvious output in mind: “C’mon! It’s simple. You know it sends you to the xyz page.”
There lies the difference. ‘We’ know. ‘They’ – the end users – may not know.
Quite often we tend to think that the person in front of us knows just as much as we do, or maybe more. So, when we put something before them and they raise an eyebrow, we raise one even higher, “Oh! Anybody would know this!” Not always, right? While creating something for somebody, we must keep them in mind, not us.
Let’s take it to the simplest level. When we buy a gift, we think about the likes, dislikes, needs, abilities etc. of the other person, not ours, right?
So, before putting that hard-to-comprehend button on the screen or designing an out-of-the-box menu, it is of utmost importance to ask ourselves if the non-technical user will understand our piece of genius.
Overflow of Ideas
Have you ever found the team’s efforts ending up in something really gorgeous to look at but of almost no use at all?
Trying to get out of the box often lands us up in some weird place like this where we find it hard to believe what we just did. Too many ideas can do this thing to us.
Let’s say, for example, the design team comes up with something wonderful. An absolutely never-seen-before UI. The development team is so excited to get their hands on the design that when they finally do, they start getting further enlightenment on making the app better. The end result looks great, feels great, but only to the team. When presented to the client or the user, you hear something like, “Wow! Looks great. What is this again??”
We don’t want that, do we? It is important to keep your creativity on the rise but also to take care that it does not exceed the level of comprehension of the general mass. Both design thinking and design sprints can be very helpful in these situations.
Plugged-in Ears
Remember the famous re-quote by Robert Downey Jr.?
“Listen, smile, agree., and then do whatever the f*** you were gonna do anyway.”
It sounds cool, but applies only in certain situation, and listening to a client certainly isn’t one of those. It’s true that everything does not always make sense but it is our duty and responsibility to make note of every word uttered. We can always filter, sort and arrange.
But.
We should ensure that the important parts do not get swept away in the process. The secret to a good and successful conversation is to listen to everything, and then to put our reasons and thoughts forward. When both parties understand each others’ views and come to a conclusion, only then can we find the wireframe to that perfect app.
Conclusion
To conclude, DDD is real but isn’t incurable. With the correct mindset, it’s not that hard to build an app that has the best ideas at its core, has the most engaging interface, and provides every user a memorable experience.