Best practices OR Best starting points in UX

Best practices are valuable in the UX field. However, often we use them without really giving it a thought and considering broader context. In this post our new guest blogger, Darko Čengija of FatDUX, talks about best practices and their relation with best staring points in the user experience (and other disciplines).

Author: Darko Čengija, FatDUX Zagreb

This is our first guest blog post by Darko Čengija, Information Architect at FatDUX Zagreb office in Croatia. You can follow Darko on Twitter: @darkoche or contact him at dcATfatduxDOTcom

Introduction

Two weeks ago we’ve been working on a client’s application interface. Client approached us earlier last month to make a complete review and rework of information architecture and overall usability of his software product, specifically intended to be used in beauty salons.

We had this internal discussion about how to position some elements and what interaction should be designed. Every one of us defended their opinion by referring to best practices. Only further into discussion we realized that we had a more fundamental issue here.

What are best practices, really?

I do value best practices. They can save you a lot of time by keeping you safe from mistakes you would otherwise make. But I also look at best practices as having many similarities with a concept of precedents, like in law. Precedent is usually defined as an example used to justify later similar occurrences. In simple words, we can make decision about something today because someone else made the same decision about the similar thing in the past. And there lies the problem – how similar. How much similar should be the context that I have and the one from observed best practice?

I heard someone saying that precedents tend to kill innovation. I tend to agree.

If we are really using someone else’s best practice as our own, how confident can we be that we’re doing the right thing?

The first thing that comes to my mind is that you can’t be 100% confident that their best practice will work in your situation.  The only way you can have that level of confidence is if your two situations are identical – not very likely.  The more dissimilar the situations, the lower the absolute certainty that their best practice will work for you.

First step – know your context

Strangely, we had some free time that day so we got further into discussion. What we came up with seemed interesting and possibly useful, which is why I would like to share our thoughts with you.

Process that I am about to describe can be time-consuming so it’s really up to you to find the best balance between time you will invest and what will you gain from it. But, let’s see what you could do if time is not an issue (is that ever really a case?).

First thing to do is to come up with as much variables that define your contexts as you can think of. Variables such as – how old users are; what percentage of working time will user spend looking at this application; what’s the noise level that is surrounding users; and so on. Just start brainstorming and think about everything that comes to your mind. Nothing is stupid; it can just be of little influence.

Before moving on, let me just briefly explain what I want to achieve here: first we should know our context; then we want to know how far we can stretch that context to satisfy the similarity issue (how much similarity makes it similar enough?).

Let’s move on – take one variable; let’s say percentage of working time user will spend looking at this application. What if we would increase this percentage a little? Would this require some changes in how application interacts with user (hopefully not)? If not, let’s increase some more.

When we get to the point where we should really have to do something different in user-application interaction, then we know we have hit the breaking point. That’s the limit of how much we can stretch our context, regarding this variable, without being forced to make changes in overall architecture. Now, just don’t forget to do this in other direction as well – start decreasing percentage to find another breaking point.
Sometimes these breaking points can be very far from where you’ve set your “normal” context, and sometimes they can be very close and you may not have much “breathing room” at all.

Second step – find best practice

Once you are familiar with the context, start searching for the existing best practices. This time you know how you can evaluate if a certain best practice is good for you. Any best practice you encounter is only applicable for a certain context. Analyze that context and see if it falls within your breaking points. If you find even one case where this context you’re analyzing is beyond your breaking point (e.g. application intended to be used with too much surrounding noise), you should consider either completely abandoning this best practice or adjust it to your context, but only if you are certain that you know how to do it.

Know this, even when you find the best practice, it’s probably just within your margins (breaking points) but not perfectly aligned with context that you have at hand. So, even when you find the best practice, think of it more as the best starting point, on which you can design your own solution.

And now… reality check

I am aware that maybe you don’t have enough time to think about every single project this thoroughly. But, on the other hand, it might just be that one thing that will differentiate you from your competition. It’s all about learning to balance between precedents and innovation. This takes time, of course.

I was at the TEDxMunich conference not long ago where, I believe, Patrick Frick said at one point: Create solutions by design, not by default. I was thinking about that sentence for a quite some time. Sure, there are very good default solutions, but some of them are nothing more than best practices.

However, if you think about Patrick’s idea and this post in general you’ll understand why we need to consider best practices as best starting points. That way, hopefully, we won’t be just creating very good default solutions but designing excellent ones.

21 Responses to “ Best practices OR Best starting points in UX ”

Trackbacks

1. Vibor Cipan
2. Hrvoje Gazibara
3. Cigdem Patlak
4. FatDUX
5. Jeff Parks
6. Rav Panchalingam
7. 4ORCE Digital
8. Square One™
9. Eric Reiss
10. Borislav Kiprin
11. IROAI
12. Marc Poulin
13. Callon Campbell
14. UXfeeds
15. UX Feeder
16. Brian Brown
17. Velora Studios
18. UXfeeds
19. Gary Davis
20. User Experience SE
21. Vivek Arockiaraj