You may be thinking, why am I even writing a blog post on this topic? Isn’t there more than enough information available on User Experience and Product Usability for most people to figure this out.
Yes! It’s true that there is lot of information available on the topic and its also possible that you will figure this out on your own. But the question is, do you really want to figure this out after finishing your project?
Or do you want to have a leg up by knowing this upfront so that you can focus on transforming the UI rather than trying to learn from the process?
I have done this for 4 UI based technology products over last 10 years. Every experience has been different.
Except in one case, where we succeeded, every experience was unique – why? Because teams, products, and types of users were different. I wish I had read some blog like this before starting every transformation. At least, I would have been better prepared.
Although we generally say “Dos and Don’ts”, and starting will Dos is common, I will start with Don’ts because impact of doing those Don’ts is higher.
- Don’t copy competitive product.
You want to differentiate your product vis-a-vis competition. Wouldn’t it be foolish to copy. Why would you even think of doing that?
- Don’t copy any other User Interface.
Okay! I am going to be more prescriptive here. Don’t copy any other user interface just because it worked in other product it may not work for you. Of course, you can steal the user experience constructs you believe will help users of your product. But there is one condition – those stolen constructs shouldn’t be from your competitors product.
- Don’t expect it to go as per the plan. It won’t!
Remember the time when you started learning how to ride the bicycle or trying to woo a partner for a date. Nothing went as per the plan. That is true with user interface transformations as well! Expect turbulences, buckle up, and be prepared for them because they are inevitable part of your UI transformation journey.
- Don’t move what’s in your old thick client to new browser-based client.
This at best is…stupidity. I have seen this being proposed as the easiest option because then we would know as a final result. Do you really think your users want dumb transfer of old UI to a browser or mobile platform product? Don’t even think about it.
This UI transformation project is your best chance to get to where your product should be in future. Attempt that whole heartedly because even with that you may not get best results so attempting anything lesser than that is foolishness.
- Don’t try to transform the UI in one long program – phase it out!
We all want results.
We all want them without pain.
And, we all want them as soon as possible.
The truth is, it won’t happen. If possible try to break your program into at least 2 or even 3 smaller phases. A phase should be at least 6 months long for you to be able to go through all the required steps for that phase.
Every phase will serve as a learning experience, and since you wouldn’t have tried to change entire UI in one phase if things go wrong you can still recover in next phase.
Caution: If your phase 1 goes as per the plan. Don’t rest on your laurels, just be as vigilant as you were in phase 1. You most likely had successful phase 1 because you were vigilant.
Now with that said, lets move on to what you should do.
Figure: UI Transformation Phases
- Identify the use cases of your product.
You should consider yourself lucky if your product is used by only one type of user and is mostly used in similar environment. If not it would serve you well to identify various use cases of your products. Different use cases lead to different ways of using the same product and hence may need different user experience.
- Learn about users, buyers, and sellers of your product.
Once you know the use cases identify users, buyers, and even sellers for every use case. Again, consider yourself lucky if all of the above converge into single individual.
It’s obvious that one must learn about user of the product and how those users day-to-day operation will need to be addressed by user. Buyer of the product may use the product but the product UI must make it easier for him to make the buying decision. And, hence studying buyer persona is important.
And lastly, if you learn about how people sell your product then it will help you understand how they do that. Having few UI features to help sellers sell the product can contribute a lot to your product’s success.
- As much as possible get real user feedback in all the stages – research, prototype, implementation, and post implementation.
My philosophy on “user feedback” is simple. User opinion is important and I will listen to the user during all the stages of product cycle irrespective of whether I like their opinion or not.
Note: I said I will “listen”, not agree with every opinion they expressed.
- Get external help – most teams don’t have all the skills required to transform the UI.
Unless you are a very big company and have every skill set in the organization, accept that you don’t have all the skills required for the transformations. Whether you like it or not most developers don’t have user interface development skills to build an awesome UI.
So get external help! (And, make sure you get it from the right people)
- Target for an awesome User Experience! Because unless you try that you won’t get above average UI.
Shoot for the moon, and even if you miss you will land among the stars.
By the way, when I started this post I said 4 products but recently I have embarked upon another UI transformation. In this case it’s going to be browser-based to browser-based UI transformation of a product that was built 7 years ago. I will let you know how that goes after some time.
Did you attempt a user interface transformation? What would you like to share?