In our previous blog post we explained what human centered design is about and why it’s so important when creating web products. Although it’s seems like such approach is probably the most effective method for creating enjoyable, satisfying user experiences, the ideas behind it also significantly influence the way most of us in RubyGarage work every day.
At first we’d like to cover the way human centered design is implemented in the products by our UX designers.
The final goal of the human centered design is to find out the target audience of the product, its tasks, goals, expectations and context in which that product will be used. Thus, the final product should offer a solution of the problem that is:
- Legible, or, simply put, easy to use and comprehend
- Visible, i.e. the user should be able to quickly understand how to interact with the product
- Accessible, that is allowing the user to interact with the product in an expected way.
A few tools are used to achieve these goals, let’s stop on each of them in details.
Persona is a fictional character created to visualize a typical representative of a target audience of a product. Thus, before creating personas we do a research and collect necessary data about such people and their behaviour.
The term “target audience” is often used to unite different groups of people. For instance, the target audience of the tool aimed to monitor internet activity of computer users can be useful both for system operators in big corporations and parents caring about their children.
The human-centered design allows having a few personas to represent either different kinds (system operators and parents) or different characteristics (parents with laptops and parents with smartphones) of the target audience.
In the end personas help to focus on the images of final users, make argued decisions regarding the required functionality and avoid making products with lots of great yet unnecessary features.
After the personas have been created we need to understand what are their daily life, habits and problems. Having such specific info allows to understand the context and build scenarios in which our future product will be used. Usually a few scenarios are developed:
- the best case, when everything around goes simply great in the life of such persona
- an average case, when everything goes just fine and the mood is neutral
- the worst case, when everything goes wrong and the character is upset or aggressive
Such scenarios are great because they are organize information in the form of stories, are thus easy to understand and allow to notice important details in the interaction of the user with the final product.
Often it appears that common solutions simply will not work due to the specific context (scenario) in which it is used, and so the UX designer must come up with a better solution. For instance, if you’re creating an online learning tool and want to verify a user’s personality for a certificate, it’s better to record his/her typing pattern than request his/her current photo in case that user is currently using a desktop.
Once you have the scenarios at your desk, it’s time to figure the exact pattern how the personas will use the final product within the previously defined scenarios. Such interactions are called use cases and basically are lists of events that happen within these interactions.
Instead of explaining each function separately, you can write use cases to avoid technical details and focus on making the interaction process as easy, understandable and usual as possible, while at the same time making it fitting the scenario and corresponding the selected persona’s needs.
While use cases aimed to figure out how the final users achieve the set goals, they also help designers to decompose the big tasks into smaller ones and then address them one by one. For instance, if you’re designing the way user should sell his old stuff on a marketplace, you will probably start with the “user logs into the system” action, knowing that later you can get back to it and design how exactly that logging in happens when needed.
Prototype is a test sample of the final product that allows to interact with it according to the previously designed use cases. According to the Dynamic Systems Development Method framework, such prototypes are used to ‘define, refine and demonstrate user interface design usability, accessibility, look and feel’.
In the human-centered design prototypes are done with minimal efforts and with the only goal: to perform user tests and check the previously made hypothesis.
Prototypes can be represented in any way, for instance, as paper blueprints or computer images. Many online solutions now offer creating visual prototypes that look and act just like a real software. They lack most of the functionality but offer the visual representation of the possible data that is expected to be shown by that software. We’ll cover such solutions in the next blog posts.
Once the prototype is ready, it’s time to perform user tests and figure out: if the solutions were designer correctly? Does the user follows the previously created scenario? Does s/he have unexpected troubles or complications?
Gathered information is then used to improve personas, scenarios, use cases and finally the prototype. The developers and UI designers do not start implementing the designed product into life until all hypothesis are correct, because they risk to do unnecessary job and spend time uselessly.
As you see, such approach considers the smallest details of the user interaction, check all hypothesis and guarantee that the final product will correspond to the user expectations even before the whole team will start implementing it.
Of course, when we say “the final product”, we mean the final product of the current iteration. Once the iteration is over, everything starts again if the product is planned to get new functionality and become even more attractive for potential users.
The reason any product is created is that people need or want it, and it is people who are going to use it in the first place. Thus, whatever you do to make any product, you always keep in mind that it’s done for a human. We have just covered, how human-centered design is implemented, but does affect other stages of our general product creation workflow? Yes, and to demonstrate it, we’re going to go through all the stages of a typical project at RubyGarage — that is research, design, implementation and post-analysis. To learn more about development workflow, take a look at our corresponding blog post.
When client reaches us for the first time with his idea, we usually start a new project with making a research. Are there any competing products? Why are they successful? How to make the client’s future product outstanding, notable and profitable?
Those questions seem to be obvious from the business perspective, i.e. when you are interested in bringing a great and successful product which you will be proud of. However, another reason for that research is to study humans. Why they use such products, how they do it, how much they are satisfied with the experience offered and why — answering these and many more questions allows to understand how to make a human-centered and thus successful product.
After all the necessary researches have been conducted, all the information is gathered, and the details are agreed with the client, it’s time to design the architecture of the product. And this is where human-centered approach affects all the processes throughout the stage, and we’ve just explained how it happens.
In addition to that, at RubyGarage our UX designer brings out new wireframes every 2-3 days, and then the team (and sometimes the client) takes a look at it to see if it corresponds to the product requirements and user expectations, if it is comfortable to use a product with such design; if it can be better, be further improved. Such feedback can bring a great amount of fresh and reasonable ideas to make the better design and thus represents the only way to raise the chances that the product will be liked by final users.
Implementation and post-analysis
When the design is finally ready and approved, it’s time to implement it through code. However, it doesn’t mean that the project’s UX designer is not needed anymore. Being ready to market changes means adapting on the fly, which in our industry means that the web product creation can never be finished. As soon as any software is released, it’s time to plan how it can be better, how the next version will look and how the new functionality will affect the design of the product.
Moreover, while functionality is an important aspect of any product, humans change their preferences over time and often seek new design, new experiences and new ways to interact with products. As an example, simply recall how mobile interfaces have been changing for the last couple years: first, you had buttons designed for tapping; then swipes were introduced for richer navigation, and recently Apple presented the Force Touch technology, expanding the ways to interact with visual interfaces even further.
Thus, a great UX designer is always looking how to further improve the ways humans can interact with the product and to make them more satisfied by simplifying the ease of use. It can be either done by analyzing the feedback and user reviews, or by gathering specific stats and metrics like time spent using the product, conversion rates, popularity of different interaction patterns and others.
Making experiments like changing a general flow of the site, the ways a specific problem can be solved by users or even switching to a different color of a button becomes extremely effective with analytics, and this is another part of the UX designer workflow based on the human-oriented design.
After working for a while by sticking to human-centered approach we noticed that its ideas are easily applied when working in a team as well. We design human-oriented products, but aren’t relationships human-oriented as well? Thus, every connection between two or more people can be stronger if all of them will consider not only each other's technical skills, but also goals, passion and emotional conditions. That’s a great skill that we mastered and that helped us make the whole RubyGarage team communicating, interacting and working on your products much more efficiently.