UX Refactoring. Complexity of simplicity
Use simple solutions using user skills. Constantly simplify the system from top to bottom. Use UX refactoring at each iteration.
Let’s consider the question that often arises in many projects, interfaces and systems: how to make what we have much simpler and clearer for most users, without losing the accumulated useful functionality?
Russian version available here
If you plot on the graph the number of people and their abilities (user experience, acquired knowledge or skills — substitute what you like more), you will get similar to Gaussian curve. There is no very stupid (thanks to universal education) and few geniuses (thanks again to universal education).
There is a stereotype in the heads of the majority that human knowledge, like the functionality of systems, grows exponentially (proportional to previous experience or practices). In theory, it is. But in practice there are limitations. After school and university, there is work, family, trips to the country. Time for reading books and self-education is reduced.
The complications of interfaces and engines (software, i.e.), dictated by the business, more and more difficult to implement because of the already done functionality. Often, those variables that were considered to be the static need to be made dynamic. Either the range of values becomes too small, when sales exceed the most optimistic values and the order counter overflows a couple of years after the start of the project. Even Moore’s law stops working.
The actual schedule, which shows both the functionality of technical systems and the ability of an individual person, closer to the sigmoid function
The simplicity of understanding systems
Let’s build a third graph. Distribution of technical systems by the ease of understanding by users.
There are some simple systems that you don’t need to learn how to use. Remember, children first learn to use their hands, then open the door handles and running around the house, then learn to hold a spoon. Becoming a little older, they learn the bike. So, gradually, a person perceives the world and discovers more complex systems.
Teens learn to drive cars. But rarely anyone knows how to use fax! For example, the Montessori board is shown, with which children of 2–3 years old are playing. This is a fine example of simple systems that do not require special user abilities.
But complex systems, spacecraft control interfaces or the hadron collider are available just for some peoples that have dedicated years to study it.
If we compare the graphs of simplicity of systems (Fig. 3) and the user’s abilities (Fig. 1), then each point on one will correspond a point on the other. Moreover, only those people who are located to the right side (more capable than to the left side) will be able to use this system normally.
But, as in any rule, there are exceptions. Products that are incredibly complex in functionality, but extremely easy to use. A good example is Apple products or the Google search line. How can this be achieved without millions of budgets?
Simple complexity or complex simplicity?
Attempts to improve the system, apply UX, interrogate users, use empathy, play with fonts, or make buttons “brighter” — these are attempts to move on the graph of system simplicity to the left, towards understandable products and interfaces. So more users can work with the site, product or interface.
In the process of shifting left, sooner or later you will fall into one problem: the inability to improve anything at this level. Polished out interfaces — it is necessary to change the API. Corrected API — it is necessary to change the system architecture. You redid the architecture — understood that it is necessary to realize the root cause of the user, his goals and the meaning of everything created. And the further, the deeper will be this abyss and more effort to move a step.
What is there to advise?
1. Keep it simple and people will reach out to you
From the beginning try to use the skills that all possible users have. Reduce the use of your system to actions that are already familiar to everyone.
As John Maeda wrote, “Knowledge makes everything simpler” (“Laws of Simplicity,” 4th law, p. 45). This is absolutely true. But what if we do not require the user to increase knowledge to use our interface? If we make a system based on the skills that he already has?
Consider, for example, a lock with a magnetic card. It imitates the key. Opening the lock with a key for hundreds of years is familiar to anyone who has ever locked the door. The card can be attached or you can insert it. If you have a hotel and you decide which of magnetic locks to buy — what will be your choice?
Following the above, it is better to choose those models where the card is inserted and not attached. Especially if your hotel in the hinterland and users are not accustomed to technological innovations. Models with attached cards are best used where the audience already has the skill to attach objects to perform an action: transportation cards, contactless payment PayPass and similar technologies.
Even more clearly — print on the card image of a key. This will help if the orientation of the card in the lock matters. People will insert a “key” into the lock.
The wider the audience, the simpler its common skills.
2. From the top of the mountain, you can see the easiest way
While improving, you will invariably descend lower and lower into the subsystems of the product or interface. And, obviously, you will be faced either with technological limitations (by the way, perhaps with the advent of quantum computers, Moore’s law will work again) or into financial ones. Therefore, it is better from the beginning rise to the level of logic, given the entire path and functionality that has already been accumulated. Reconsider the business logic, ask the question “how can you achieve the same goal, but easier”? You already know the background to the creation of the current interface, you know how people use it, what’s left from previous versions. Take a fresh look at the system and redesign it.
“Sometimes it is very much easier to see the surest route to a place only after you have arrived. You may have to be at the top of a mountain to find the easiest way up.”, Edward de Bono, New Think: The use of lateral thinking in the generation of new ideas.
Otherwise, there will be a situation where previous pivots, system versions, changes in business strategies and the addition of already unnecessary functionality gave a one-legged Frankenstein, which you want to make dance, changing hairstyles
For example, you want to make a subscription form for news. The classic option is to implement the standard template and immediately, from the first page, require the user to email. But after all, if we consider it comprehensively, it will be effective to ask for consent to subscribe at that step of the process where the client enters it (the checkout stage). In the same place, why should I sign up for the value — what topics will the notification be, how often, give an example of such a letter, etc.? Show signs of this subscription.
Similar case with the user’s phone number. You can design an input form, or you can design a situation where the client himself calls to the contact center/courier and automatically determine his number. For example, “so that the courier arrives not in the selected time range at the specified address, but within one hour and where it will be convenient for you during the day — dial him and discuss the actual time and place of delivery”. Not everyone can stay at home for 4 hours while waiting for delivery. Someone can drive off on business, leave the office for lunch or a meeting, go to the gym. The purpose of the user — to get the goods as it suits him. And planning, even for the day ahead, is practiced by very few. Use it.
Take the user’s goals that are already used when working with your system and change it. Fundamental changes in logic and more correct implementation of the goal will automatically respond to subsystem levels: architecture, hardware, software, and interfaces.
Move not from changes to goal, but from goal to changes.
By the way, as a consequence of the foregoing, the role of the person and the team designing the system should be very versatile. From design to technology. From programming to the understanding of financial flows. From procurement of components to disposal. The increasing convergence of specialties confirms this. Technological engineers, full stack designers, product managers and analytics.
Yes, it is very different from iterative methodologies. Fans of Agile and hypotheses will now begin to object. Therefore, there is the third recommendation:
3. Every time as for the first time
Iterative methodologies can be applied, but they should not be a means of seeking variants or checking hypothesis through the process of achieving improvements. Otherwise, you risk to start build up unnecessary functionality from past iterations. A nonlinear increase in complexity will begin and the system will begin to slow down in development.
Therefore, plan every change from the goal. Review business logic, conduct analytics, cut off unnecessary parts of the functionality, simplify to the maximum. Try to apply such solutions that contribute to the achievement of several goals simultaneously.
As in the example described above with a call to the courier — and you get the user’s phone, and the user gets an additional service in the form of delivery flexibility. The classic solution with the choice of the delivery time range is OR (logical XOR). Or one option (from 12 to 16 hours), or another (from 16 to 20 hours).
The genius of the conjunction AND the villainy of the conjunction OR
Each release is a potential patch from above to the system for the implementation of a specific functional, and not an organic integration into logic. By adding everything to the heap, you risk making the work with the system incomprehensible and illogical. Disadvantages of type 1 and 2 (goals are blurred among themselves, or none of the actions seems to the user leading to the goal) — as a result of uncoordinated changes.
Pay attention to what is the system you have at the moment. UX refactoring is applicable not only to the visual interface. Any set of systems can be isolated as a whole and improved in isolation from another part.
The higher you take the supersystem level to consider (business logic, for example), the more extensive the UX refactoring can be done, affecting this and the underlying levels of the systems.
In this case, the interfaces also become, for example, API (at the level of software systems) and connectors (at the level of server hardware). And not only external clients become users, but also internal managers, operators, administrators. Even some systems can be clients in relation to others and they are also subject to the principle of eliminating defects and disadvantages.
Conclusion
How to understand that you are already there, in the zone of products that everyone understands?
When working with the interface, the user does not look for documentation and does not ask for hints.
Everything is so clear that anyone will understand. Yes, maybe only nerds and geeks will initially use your product, and technology newbies will connect at the very end, but it’s better to focus on newbies right away. It would be even more correct to say that in order for the nerd feel the simplicity and consistency of using the interface:
Turn a nerd into a newbie.
Facebook: facebook.com/lessplusmore
Telegram: t.me/lessplusmore
VKontakte: vk.com/lessplusmore
Twitter: twitter.com/lessplusmore
And clap the article, if you like it!
Special thanks to Wova Roodnyy for ideas and consultations.
