Best practices are valuable in the UX field. However, often we use them without really considering the broader context.
Best practices are valuable in the UX field. However, often we use them without really considering the broader context. In this post Darko ?engija of UX Passion talks about best practices and their relation with best staring points in the user experience (and other disciplines).
Author: Darko ?engija, UX Passion
This is our first guest blog post by Darko ?engija, Information Architect at UX Passion. You can follow Darko on Twitter: @darkoche or contact him at darkoATuxpassionDOTcom
Introduction
Two weeks ago we were working on a client’s application interface. The client had approached us to make a complete review and rework of the information architecture and overall usability of his software product, specifically intended to be used in beauty salons.
We had an 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 did we realize 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 the concept of precedents, like in law. A precedent is usually defined as an example used to justify later similar occurrences. In simple words, we can make a decision about something today because someone else made the same decision about a similar thing in the past. And there lies the problem – how similar? How similar should my context be to the one observed in creating 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 the discussion. What we came up with seemed interesting and possibly useful, which is why I would like to share our thoughts with you.
The 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 the case?)
The first thing to do is to come up with as many variables that define your contexts as you can think of. Variables such as – how old are the users; what percentage of their working time will the users 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 minor 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 increased this percentage a little? Would this require some changes in how the application interacts with the user (hopefully not)? If not, let’s increase it some more.
When we get to the point where we should really do something different in the user-application interaction, we know we have hit breaking point. That’s the limit of how much we can stretch our context, regarding this variable, without being forced to make changes in the overall architecture. Now, just don’t forget to do this in the other direction as well – start decreasing the percentage to find the other 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 existing best practices. This time you know how you can evaluate whether 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 the 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 it was Patrick Frick who said at one point: Create solutions by design, not by default. I was thinking about that sentence for 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.