Collaborating with Stakeholders to reduce design complexity
Written by Luis Garcia
During the design process, dealing with stakeholders could be difficult, if not directly, a problem due to the blind love that some feel for the field of knowledge in which they are involved in. That feeling could bring complexity to the service or product under consideration. As designers, we need to know how to deal with this issue.
I like to define UX designers’ activity as that of a ‘Complexity Avoider’. Basically, we identify, analyze and solve a problem with the overarching aim to simplify a complex reality. It sounds very sophisticated but is not. In most cases it’s just about changing the problem’s frame. Therefore, it is essential that someone helps us to understand the dimension of the problem and to be allowed to change the way things are done in a certain domain. Here is where the Stakeholders are key.
As a designer, I had the chance to work in several diverse markets, from financial to aeronautical, and in all of them I had always faced the same situation: Stakeholders always love what they do and want you to fall in love with it as well- Doesn’t matter the topic we are diving into, the professionals always feel a personal attraction about their subject.
The journalist loves scoops, the mechanic loves engines, the financial analyst loves investment funds and so on. This by definition is not a problem rather a natural behavior and a sign of professionalism. But into this behavior I have always found a challenge for a user experience designer and the reason tons of services fail. I have named it Engineer’s love or Specialist’s love.
Engineer’s Love
We can describe this phenomenon like the more complex and sophisticated is my field of action the more interesting is my activity and any intent to reduce the level of complexity will be refused arguing simplification or lack of experience. In most cases engineers love what they do including the dark parts that need to be redesigned. When you have spent many hours in a particular field of knowledge, you are used to its strengths, but also to its limitations. Of course it is not something that is done on purpose but could have a great impact in our design process and its result.
Let me explain it with a real example. During the design of an ecommerce site, a wireframe had shown a list of carpets with just two or three options to filter (by size, color, material…). Right away the product owner of this line has claimed the scarcity of filters considering our vast offer and had suggested some additional (washing method, year of production, type of drawing…) In this case the product owner didn’t realize the additional complexity taking in place and the fact that its users didn’t use filters systematically. His point was about how sophisticated his market was and not about its user needs or attitudes. The final result was a not user-friendly list of carpets that didn’t address the user needs.
Behind that situation we can see the lack of a real customer centric design approach. Into a Design Thinking process any decision has to start on the understanding of the user and the problem that we want to solve. If we break this work flow in the name of new business aims or additional requirements we will lose the real focus of the project. And that’s something stakeholders have to understand too.
This example it’s extensible to any field and it’s especially applicable to the more technical subjects. And of course it’s a problem for the design performance of any service.
Distribution of Complexity
Behind the Engineer’s love, we can find a misunderstanding where the charge of complexity is in the design of a digital service. Instead of reducing the level of difficulty for the ones that will use our service, we pretend to translate it directly from the back-end to the front-end. It’s about the classical issue of distribution of complexity. Any digital service has a certain level of complexity and our duty as designers is first reduce it and second keep it out the user’s way. Said in other words, keep the hard work for the professionals and simplify for the users.
But it’s not all bad news. To avoid the effects of the Engineer’s love there is a general golden rule that helps to tackle any related situation. It would be something like what is not mandatory is not needed and we should remove it from our design process. We can apply that to different contexts: A text field in a form, a step in a check-out process, a new feature of a product… always works the same radical way. If you remove an element and the service still works at the same level is because it was a source of difficulty and you don’t need it. Probably some Complexity lovers raise one’s hand, but it doesn’t matter because you will be in the right path.
Google is a clear example of that. If we raise our view, we will find that its interface’s evolution is a constant reduction of secondary elements. Links, drop-down menu, tabs and other elements were gradually disappearing during the years.
Of course I know that things in life are not so simple, we always have constraints and pressures to add something up to our designs. So I suggest a new general golden rule. That second version would be like what is not mandatory, have to be isolated, if not hidden, in our design process.
In any case I know there are people who have to deal with real tough situations. For these ones let me elaborate the super new general golden rule. Would be like what is not mandatory, must be hierarchized in a second level. And that’s my last offer.
Regardless of rules, what I intend to explain is that there are some objective ways to identify when we are crossing the boundaries of a lean approach and getting into the Engineer’s love.
The fallacy of Value = Complexity
Moreover there is a frequent situation in the design projects in which someone wants to include the development of a new feature in the backlog. We are talking about something on top of the main flows of the solution that brings some additional value, but also raises the general complexity of the product. What should we do?
At first it doesn’t sound so terrible to exchange some value for some complexity. Finally we are here to give value to our users. But if you think about it in detail you will see that it is not a good deal. Actually is one of the usual causes of failure of digital products during its life cycle. This ‘Feature Race’ drives most of the products to a decline of the user experience offered.
One clear case was Online banking services. During many years all of them have struggled to have the bigger functionalities offer: all kinds of transfers, deposit, financial transactions… All the banks ran the ‘Features race’ trying to be the bigger in terms of features. But they didn’t realize that each time they added new functionality they also increased complexity. Now most of them have changed their approach to focus on the user experience of a certain number of features.
So considering any new feature in isolation is a mistake. It’s not a simple exchange between what this functionality brings and what additional work it development implies. As owners of the service we have to consider as our main priority the impact in the product general performance. Keeping the product simple is not passive work, it implies some additional amendments to give room to these new features (new value).
So please don’t accept this agreement in which value means complexity. All the products have a certain point in which any additional feature means a rise in difficulty. We as designers have to identify those cases and anticipate a solution. If we do this work correctly the result will be a new formula in which any new feature will bring either value or complexity
Final thoughts
Keeping things simple is one of the main purposes of our work. To be able to achieve it we need to rest in the knowledge of some stakeholders that in most of the cases love what they do. We should take advantage of this circumstance and not let them influence our design process. It’s important to maintain our objective perspective without losing our empathetic capability.
In some cases it’s just a topic of distribution between the elements that we present in the front-end and the ones that we keep in the back-end. The more we keep the complexity out of the user’s way, the more possibilities of success we have in our project.
In the same line any initiatives that follow the idea that some value always brings some difficulty to the general performance has to be rejected. We have to struggle to maintain the alignment between features and value. If not we will run the race of features, the race of complexity.
Want to learn more?
If you’d like to become an expert in UX Design, Design Thinking, UI Design, or another related design topic, then consider to take an online UX course from the Interaction Design Foundation. For example, Design Thinking, Become a UX Designer from Scratch, Conducting Usability Testing or User Research — Methods and Best Practices. Good luck on your learning journey!
References
- Managing complexity
https://uxdesign.cc/managing-complexity-8094c316a506 - The Complexity of Simplicity
https://www.uxmatters.com/mt/archives/2006/12/the-complexity-of-simplicity.php - When Designers and Stakeholders Collide
https://www.uxbooth.com/articles/when-designers-and-stakeholders-collide/ - How to Collaborate with Stakeholders in UX Research
https://www.nngroup.com/articles/collaborating-stakeholders/
(Lead image: Pexels)
Originally published at UsabilityGeek by Luis Garcia. He is a Digital omnivore. He is interested in almost everything, but especially in all topics related with digital experiences: User Experience, Service Design, Usability.
