Asaad El Salawi, Senior Product Designer shares his learnings made along the journey from reactive to strategic research in the virtual discussion with Alexis Gerome in the following topics:
The problem with reactive research and the consequences for the business
The definition of strategic research and how it changes the business
The reasons to operationalize research and the benefits of it
When I started writing this article, I thought I’d be a pioneer. Until I searched for it and found lots of articles covering this topic. Which showed me how important that topic is on the one hand, and that it humbled me on the other.
We all have been in this. Exciting times. We start working on a new product. We do just enough research to get some insights, we want to be fast throw MVPs into the wild, and get real feedback as early and often as possible. Based on our first learnings we eagerly start building the first flows, deeply thought throw and beautifully crafted. Exiciting times. And as our products grow, features are added, new edge cases appear, and our teams expand, things start getting messy. Inconsistencies appear, user journeys feel broken, we lose users. The experience of our new baby drifts apart.
Our colleagues from engineering
There is good news: We are not alone. From our engineering colleagues, we know that they have the same problems. The term which is used, is called Technical debt. It is a concept in software development by Ward Cunningham in 1992 that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. He compares this code debt to financial debt. In this 5 minute video Ward describes the debt metaphor in his own words.
The reasons when technical debt happens, can be quite different. But agilescrumguide.com explains the seven top causes in this article:
Time pressures
Overly complex technical design
Poor alignment to standards
Lack of skill
Suboptimal code
Delayed refactoring
Insufficient testing
What is Experience Debt?
Experience debts reflect the cost of additional rework, as well as possible loss of trust of existing and gaining new users, by choosing short-term functions instead of well-thought-out long-term solutions. In the worst case, errors can creep in at all levels of the user experience.
Top Level: Inconsistencies in the customer journey
Mid Level: Interaction design, Copy, content, and messaging, Information architecture
Bottom Level: User interface, Accessibility elements
The bigger the debt, the more damage will be caused to the business. Or in other words: The costs of frustration is the experience debt that our businesses will pay.
The root causes for the debt
Let’s have a closer look on those seven reasons mentioned above. We can see quite some similarities to our work as designers.
Agile Misunderstood
In the section above, we already saw some points which lead to the erosion of the experience. One bigger reason, I wanted to address seperately is our thinking around ‘being agile’, ‘gaining speed’, and ‘getting data quickly’. While this is not necessarily wrong, we ascribe some things to agile which are not correct.
Low hanging fruits
In almost all product decisions, I have been part of, which feature we build, we decided to go for low hanging fruits. Why? The implementation effort is small. Looking at our impact / effort matrices, that leads often to quickly creating a bunch of shitty isolated shortterm assumed quick wins.
Being hasty with building
Many times our assumptions end up being written code to test with real people. We assume that we a) are right, b) can only learn through fully fletched software, and c) keep building on that written piece of code, even though we should have never done that in the first place. Lowering the risk and validating assumptions can (and should) be done without writing even one line of code.
Not seeing the forest for the trees
Working on a specific feature of a product with your product team day to day makes us operationally blind. We only see our own microcosm and forget the big picture. And mostly we only measure KPIs within the microcosms we are captured in. Measuring this big picture - the overall experience - is harder and a full time job. That doesn’t mean we should leave that out. We need to embrace the challenge and measure the hollistic experience.
Agile ≠ Not having a vision
Based on our learnings we should create a vision what our service / product should and shouldn’t be. The vision is our lighthouse which gives us guidance. Our strategy defines how we will get there. Agile is incorrectly associated too often with not having a Strategy. Only by matching our immediate insights with our long term goals, we can make early and deliberate decisions how to adapt.
How do we reduce the debt?
Avoiding or getting rid of experience debts is not a one time effort. It is something that everyone in the team — or even the company — has to actively and frequently contribute to . The following points are supposed to give guidance how to get minimize or get rid off the debt. It’s not a hard guide, but rather ideas what to think about.
Depending on your current flight level and whether you piled up some debt already, you might want to go one path or the other.
Measuring the holistic experience
Having an overview and benchmarking the whole experience is too often neglected. Mid-size internet companies, which have over 250-1000 people, can have thousands of pages across plattforms. All of those are touchpoints which support our users. Lots of space to mess up the experience. If we don’t have an overview of those touchpoints and their effects on our users, we won’t be able to keep satisfy our users.
Defining design opportunities
One technique of the IDEO design kit that I highly appreciate is design opportunities. Based on our insights we learn in the qualitative research with our users, we create a short list of four to eight opportunities. Such opportunities can have a lasting impact on the quality of the designs. It is as well a very good tool to measure the impact of the designs on our users success.
Sticking to guidelines
In todays design organizations it is not uncommon to see Design guidelines. They are used to ensure a consistent visual appearance and interactive behavior across touchpoints. Mostly the range from being asset libraries to being complete data bases which include animations, copy text , frontend code, backend logic, and even process workflows.
These guidelines are very good tools to mitigate the debt which would appear otherwise.
Iterating continuously
Jeff gothelf gives the perfect example of the magic of iteration, as he talks about the pottery class, which was divided into two groups. Both groups had to create pots. The quantity group would be graded based on quantity, while the quality group would be graded based on quality. In the end, the quantity group produced also the pots with the best quality, because they iterated a lot. While the quality group had only theory.
Iteration is an important factor in order to get red of bigger debts. Mostly we cannot (and maybe should not) do everything at one in one huge task. Rather you do small steps, but many. In product teams this means making the debt visible, communicating the imprtance, and prioritizing it accordingly. Finally it is our duty to sprinkle small tasks into the product development, which help to increase the experience and to resolve UX Debts.
User Testing
Our biggest strength as UX designers are our users. We should give them the power to improve our products. Nothing is more vauable to us, seeing our users reacting positive or being frustrated when interacting with our designs. If we don’t test on a regular basis, involve non-design stakeholders, and prioritize accordingly, we won’t get rid of UX debt.
About different perspectives and how we designers can make it work.
﷽
From the shining eyes of the audience and the smile on their faces, you could see that the head of a digital accelerator had hit a nerve. He gave a very vivid description of how he set up his exclusive studio. It was his design team that decided the topics they wanted to work on and with which team. They defined the requirements under which the project should take place and what the design process looks like. He made sure that nothing disturbed the calm of his studio. Only in this protected environment his team was able to create these amazingly beautiful results. (Unfortunately this is not the only time I’ve seen such a story.)
Naive romance
Young designers too often have the romantic idea of a perfect design environment in which they are the driving force behind design and product decisions. They want to control the process from an ivory tower. On the one hand, this is due to the fact that we mostly restrict * design * to its visual properties — and therefore do not do justice to the discipline. On the other hand, the involvement of other stakeholders in our process is very challenging and can be tiring: External factors such as budgets, technical feasibility or business policy often thwart our deliverables.
Influencing factors
If we think of the stakeholders with whom we come into contact every day, it becomes clear that we generally interact a lot (more) with people who are not designers.
Designers who create solutions for video verification must adapt their designs to legal data protection regulations. Here the legal department becomes the determining design factor. Designers who create mobile web applications such as social networks must ensure that their pages load quickly. Here web development is the determining design factor.
Not all stakeholders will influence our work the same way. Some will have more influence on our processes and results, some less. But there will be factors, which could prevent us in achieving our desired outcomes.
If we don’t involve our non-design bosses and peers at eye sight in our process and get them to hear our users’ voices, the quality of our results will suffer. In doing so, we ignore important perspectives that weaken the effect of our designs or even make them completely irrelevant. Regardless of whether the result meets our qualitative design requirements or not. We do ourselves a great favor by welcoming these factors rather than excluding them.
Influencing upwards
Whoever the Head of Design reports to automatically becomes the new Head of Design. https://t.co/5CG1IQZ6zl
Not every designer is in the luxurious situation to have a CDO, VP of Design or a Head of Design as a manager who sets the course so that we can do our work in the best possible way and achieve the greatest possible success. Whoever stands above you will have a strong influence on the process, the means, the resources and ultimately on the outcome. I was e.g. ever in the situation where my supervisor considered user research to be unnecessary and therefore did not free up the means and time for it. That of course had a negative impact on the quality and therefore the impact on business. I was not happy about it, but in the end, it’s a design decision as much as it was a (bad) business decision.
Lead the conversation
It is therefore essential to proactively try to influence top-down decisions. The earlier we identify important stakeholders and try to influence them using data, the more relevant our work becomes. And there is good news for designers: With our methods, we have the best tools to do this in a targeted and orderly manner. On the one hand, this increases the importance of our jobs because we understand and integrate business-critical perspectives right from the start. On the other hand, we get more substantial feedback, especially from non-designers, who go beyond superficial opinions like “I don’t like this design”. The moderation and orchestration of conversations are becoming more important for designers than the craft itself.
Accept the challenge
There are different ways to get the required buy-in from higher-level stakeholders and to integrate different perspectives into the design process. While some measures are political in nature, others are very pragmatic. Here are three obvious ways to address the problem.
Form alliances
In a great post, David Stoker describes how to persuade other stakeholders to be on your side in non-design environments. In a conversation, a designer friend told me that as a freelancer, he chose the programmers he needed to get his designs implemented. He understood, that those developers would have the biggest influence on the designs. So he regarded them as designers and involved them equally.
Master the language of the data
The other way round, we should also participate in conversations far from design. This happens at different altitudes. When it comes to strategic issues, it is essential to have data at hand. While PMs communicate their product KPIs, developers their velocity and technical performance, marketing people their audiences and campaigns, we can score with user research. It can be a short clip of a usability test session with a user or a crisp report to convince the participants of our mission. This way we speak their language, become the master of our process, and finally get a place at the table of “the big ones”.
Design Thinking
In my opinion, design thinking is the best way to bring different perspectives together and to include them actively and specifically in designs. It illuminates the entire process from collaborative ideation, through concrete conceptual elaboration, to testing with users. Every step is relevant for all stakeholders and creates strong ownership among all participants.
So…
Let’s be good hosts, open our ivory towers, and let other stakeholders enter as well.
Our work as designers is influenced by many people. The single most important person which will impact our work are our bosses. Let’s take a closer look at that person.
﷽
In my last article I described superficially why we should welcome and actively involve non-designer-stakeholders in our creation processes. In this article I would like to dig a little bit deeper in this on the factor which influences our work.
My experience visualized
Throughout the last years I‘ve worked in very differently structured organizations, in small and big, locally and distributed teams, with designers as bosses and non-designers as well. It makes a huge difference not only to the you, but to the whole product and strategy, whether the person who happens to be your boss is skilled in design and has influence or not.
Skillset
Is your boss a designer by profession?
Is your boss not a designer by profession, but actively and knowingly designed artifacts
Does your boss have experience in working with designers / design teams?
Influence
Is your boss close to the C-level and knows how to talk to those people
Does your boss have a higher status in the company
When we put that on a 2x2 chart, we get something like above. I will call it the Influence-Skill-Matrix. Depending on the influence and skills your boss has, it can help you in your mission, or it can prevent you from doing anything.
Upper right: Your boss is skilled in design and has Influence in the company. Might be a VP of Design, Head of Design, CXO, or any other fancy position. You should make this person your friend and mentor. Having this person as your boss, will boost your work and make its value visible. Congratulations!
Lower right: Your boss has influence but is not skilled in design. While that’s not optimal, it doesn’t mean that your ship is going to drown. Invest some time, use all your storytelling and visualization skills, and try to persuade this person as much as possible. There is a good chance you can draw that person on your side.
Upper left: Your boss doesn’t have influence but is skilled in design. Honestly, your boss should have some influence in the company. It’s not ideal, but also nothing you should cry about. You can work out things together. At least you are more than one person. You need to work harder.
Lower left: Your boss doesn’t have influence and is not skilled in design. You rather find someone like 2 or at least 3. You can try on work that relationship, but I consider this a waste of time.
Obviously there is no clear formula, that I have at hand, but there are definitely some aspects to consider. Let‘s dig into it.
Organization chart
I structured the diagrams by the following parameters
Number of people, departments
Hierarchy chains
Direct Boss
# of direct Coworkers (per team)
Organization 1
→ My work was mostly cosmetics work. Nothing else. In a discussion it also came out that I shouldn‘t be doing more than that.
Organization 2
→ Most of my work focussed exclusively on UI. The thinking was very much based on building stuff than solving real problems. The only research we did was feedback we got from customer care. Growth was not a topic, nor was it proceeding with innovations.
→ When the boss changed my work still mostly covered UI. We wanted to do more qualitative research but were actually prevented from doing it. Numbers were everything, no empathy for our users, no focus on the product.
Organization 3
→ While my direct boss gave me lots of opportunities to try out new methods, doing my own research, and get into technology, the company as a whole didn‘t pay attention to grow UX. There were almost no people fighting for our users. So the designer/non-designer ratio stayed like 1:250. And those people who called themselves UX people actually never talked to real users.
Organization 4
→ Without any doubt, with my direct boss being a designer and Product Lead himself I had the biggest freedom, support, knowledge growth, impact, and fun. We had the chance to participate frequently and early enough in strategic product decisions and our voices were heard.
The difference between having a non-designer or a designer as a boss makes worlds of differences. The positive impact on my ownership and results of the work were immense. The designer decided to design his team as well as he was designing services, information architecture or screens before. While others unintentionally build groups of people who happen to work together. Teams are more than manpower.
Organizational Design
In his infamous org design for design orgsPeter Merholz goes in depth how design teams can work best within bigger organizations and what needs to change. In this article (which is an excerpt from his book) he mentions two very important topics
Who is design reporting to and why
“[…]With small design teams, it is common for a squad of junior-to-senior designers to report to someone who is not a designer, but instead in product management, engineering, or marketing. To a certain extent, this is acceptable.”
Distance from the C-suite
“[…] For design to realize its full potential, leadership must be only one or two rungs away from the CEO, and so must either be an executive or have executive access. If too far away from the “C-suite,” then the politics needed to navigate the organizational reality of end-to-end experiences becomes extremely difficult. Such distance makes it easy for others to dismiss design’s contribution.”
Most CEOs, Department heads, who are not designers need to put some efforts into organizing their organizations in some way. I like to call this an information architectural skill. Oftentimes what comes out appears strange to us. The critical part is when those people organize our environments. Then this strangeness can turn into frustration. If we don’t want to involve ourselves in those organizational processes other than the visuals and interactions, we will suffer the consequences.
With the growth of designers in companies the demand for designers in management positions is growing and we are getting a place at the management table. So we can hope to balance the organizational inequality of different disciplines. But It would be counterproductive for most businesses to have only designers in management positions. We need to have other stakeholders in our direct vicinity and we need to involve them them as often as possible in our daily work.
When we look at companies like AirBnb and N26 we can feel from their services that design is deeply rooted in the DNA of the products and business. Topics like user research, storytelling, micro interactions, are implemented into their organizations — if necessary top down. In fact those companies are so successful, because Design paved its way into the C-Suite and is considered as business crucial.
The friction that is created between designers, product, devs, marketing, a.s.o. is fruitful and makes our services and products sustainable. That’s the only way for us designers being relevant for the other (upper) stakeholders while moving the organization to become more or stay user-centric.
That’s not the end …
I’m looking forward to hearing from you. You can reach me on the following channels