User Experience aka UX is quite a hot topic these days amongst designers and startups. According to Don Norman & Jakob Nielsen,
User Experience encompasses all the aspects of the end-user’s interaction with the company, its services, and its products.
Caring about your customer’s experience becomes even more important, when products face cut throat competition in the market in the terms of functionality.
In the race of quickly releasing the new feature updates for a product, product designers often ignore some critical steps in the design process which eventually leads to customer dissatisfaction, and wastage of time and resources. For a company or a startup with limited resources this seems to be a major setback.
There are some steps that could be followed during the product design cycle to predict design failures or to provide better user experience of the product.
1) Testing
If you believe testing is just for the programmers, then you are wrong! Experienced product designers often test their designs before forwarding them to developers. Testing designs not only opens ways for initial feedback but also allows designers to have a feel of user perspective before the actual implementation of the product. It initiates the process of Iterative Design. It’s not true that you require a large set of users to test your product and get a good feedback. Testing can be done at individual level or with a handful of people.
a) Individual Level Testing
A UX designer can conduct small tests or analysis of the designs during the initial stages of design process. Few of them could be:
- KLM Analysis: It stands for Keystroke Level Model. According to Wikipedia,
In HCI, the KLM model predicts how long it will take an expert user to accomplish a routine task without errors using an interactive computer system.
Proposed by Stuart K. Card, Thomas P. Moran and Allen Newell in 1980, this model calculates the total time for an action by a user, by summing the time it takes to complete the small steps that lead to that action.
For example, if you are in a dilemma whether you should provide a dropdown menu or a radio button for gender selection, below analysis could help you. Let’s suppose that
clicking a button takes = x milliseconds pointing mouse to option takes = y milliseconds
So, if we use dropdown for selection then the actions would be
- pointing the mouse to the dropdown
- clicking on the dropdown
- pointing the mouse to the desired option
-
clicking on the option to select it
Considering the above mentioned time in milliseconds, total time to complete the action would be = x + y + x + y
Whereas for radio buttons, actions would be
- pointing to the desired options
-
clicking on the option to select it
Therefore total time in milliseconds for radio button would be = x + y
Hence, making radio button easier and faster choice in this case.
Estimate values of similar operations (pointing, clicking, scrolling, thinking)could be found on the web or could be calculated using available tracking tools.
However, there could be few scenarios where results of KLM analysis prove to be an exception.
- Fitt’s Law: It is scientific model that is used to predict the human movement in HCI. According to Wikipedia,
Fitt’s Law predicts the time required to rapidly move to a target area is a function of the ratio between the distance of the target and the width of the target.
That included a lot of technical jargon! Let’s simplify. In simple words, targets which are bigger in size and near, require less time to reach as compared to the targets which are smaller in size and far away. This is the reason those ads buttons which you see on most of the free stuff websites are very big in size compared to the main action buttons.
However, there could be cases where Fitt’s law would not be an optimal choice. For example, a bunch of big targets might eat up all your screen space hence leading to bad UI or if you try to keep button near to each other to reduce the distance, there might be a case all your menu options get cluttered. Therefore, a thought should be given to the situation before directly applying the Fitt’s Law.
b) Group Level Testing
Studies by NM Group show that,
More than 80% of your product problems are found if your test group consists of just 5 users and you run as many small tests as possible.
This clarifies the fact that you don’t need a large set of users to test the design of your product. If you are a small startup, you can form a small group of users of different expertise level by considering your friends, family members or even team mates who are not in advance aware of the ways your product works.
2) Don’t try to build Rome in a day
“We need to redesign full application.” or “We need to discard current design and come up with a new design quickly.” These words are very common when you are working in a fast paced organization. Most of the times VP’s or CEO’s come up with a decision to entirely redesign the application without even thinking how much memory load the new design will create for the end user of the product. There might be a case that your user don’t like the new design at all and they start complaining about it. This can be illustrated by Ebay’s Yellow color scenario. Few decades ago, Ebay used to have a yellow colored background and their design team decided to change it to white. This mistake of suddenly changing the yellow color to white bombarded Ebay’s support inbox with tonnes of complaint messages. Just imagine! a small change of yellow to white made so much difference. Learning it hard way, folks at Ebay had to roll back to yellow color and it was decided that yellow will be changed to white gradually. So, everyday Ebay reduced one tone of yellow and in a span of few months it finally changed to white and guess what? No complaints this time!
If your application’s design is not the worst, then you should not try to build Rome in a day. With that I mean, its better to do gradual changes than to release the whole new application in one go. Gradual changes benefit you to understand your user and to also get a step by step feedback for the changes. Just consider a scenario, when you spent eight months in redesigning your application and your users don’t like the new interface, not because they like the previous one, but because they are used to the previous one. However, now they will have to learn the entire new interface again. What a pain!
Moreover, feedback received while gradually making changes can pave the way towards User-Centered Design Process. You can make small changes and collect user feedback and refine previous changes before moving to the next step. Also, this way your users will not have to learn an entire new interface in one day. Just remember, “Rome was not built in a day.”
3) Think of “Why” before “How”
“Let’s start with wireframes”- A very popular phrase when it comes to the designing of a new product. Designers directly wear their hats and get to work with their toolbox. And, after few weeks of sleepless nights, the outcome is hundreds of wireframes. Cool! Isn’t it? Now just assume, the specifications given to the designer missed a special edge case, which might itself be a new feature or which might need to be excluded from the design. Crap! Editing so many wireframes is a pain. Right?
Now let’s just rewind the scene to the time when you decided to start a new project. At this point,
think Why and not How
What happened in previous scenario was the result of How - How we should implement it? Instead, if the team would have spent some time thinking why we are implementing it, then it would have been easy to detect flaws or additional edge cases before the actual design process began.
One question that comes to the mind is - How to get the answer for Why? I will explain this using an example. Consider that you are working on an SOS application, then before directly jumping to wireframes, just create a storyboard where you sketch and think upon the scenarios where your user will use the application. For instance, in this case you can ask yourself - In a situation of distress, why will the user consider my application? Will my application work even when there will be a network problem? Will user remember to use my application in that situation? These are some of the questions which lead to the answer of the question - Why are we building the application?
Also, the storyboard developed, helps all the designers in the team to come at the same level before they dive into actual design process. This also helps other departments to understand the requirements of the application and they can plan on their role in the development or marketing of the product. Moreover, the storyboard looks more like comics than any other technical representation of an idea, which makes it easier for anyone without technical ability to understand the main idea of the product.
4. Accessibility
Do you think your audience includes old, visually impaired or physically challenged people? Does your users complain about the reduced productivity due to frequent switch between pointing device and keyboard? Then you must not miss on accessibility options in your designs.
With enhanced accessibility options, you can improve your product’s UX to a large extent. Thus, increasing your viewership or user base.
Some of the ways in which you can take care of accessibility can be:
- Dynamic Font Size: For people with low vision, this can prove to be a blessing. But, you have to make sure increasing font-size doesn’t distort the entire user interface.
- Support for screen readers: Do you remember the last time you used “alt” attribute in your image tag? That’s what screen readers look for when they encounter an image in your HTML code. Also, while designing three (or two) column layout with image and text, make sure to keep the HTML code in a way, every image is followed by its text instead of keeping all the three (or two) images in code first and then their texts. Since the screen reader scans your HTML code from top to bottom in the former case it will read the “alt” attribute of image tag first and then the text, but in the latter case it will read the “alt” attributes of all the images first and then the text for all the images, making it really hard for the user to understand. Screen readers should also be kept in mind while designing pop-ups or dialogs because if your dialog’s HTML code is at the end of your page’s HTML code, then screen reader will read it after parsing the whole page even if your dialog pops out somewhere in between.This gets even worse when you offer a call to action in your dialog. Make sure your dialog’s HTML code is just after the action which triggers it. This will make screen reader to read the content of the dialog before reading the remaining content of the page.
-
Never miss on keyboard shortcuts: Remember the time when you created a pdf file for Photoshop or Illustrator shortcuts. Why did you do that? To improve your productivity. Right? Then why not providing the same productivity enhancing features to your users?
If you feel that your application has too many menu items or call to action buttons, it’s a great choice to create shortcut keys for that. Also, make sure you give reference to the shortcut keys in the tooltips or beside the menu items. This will help your users remember them easily. Moreover, shortcuts not only make the work easier but they are the most preferred choice of the expert users. Many products get discarded because they don’t provide keyboard shortcuts hence making it difficult for users to switch between a pointing device and a keyboard. So, the next time when you design the front end of an application, just think of your life without Photoshop shortcuts!!
- One is good, Two are better: This is an old proverb, which holds good in design too. This implies always provide multiple ways to reach the same goal. No matter, how simplified your design is, if you don’t provide redundancy in your design, your users will have hard time figuring out how to reach their goals.
It’s true that UX design is a creative and logical process, but sometimes in the hassle of abiding by the deadlines, we often miss small points which hurt us in the later stages of the product lifecycle. So, the next time when you work on your designs, just try to consider the above points and you will feel the difference.