Table of Contents Hide
We all want the best-designed product, right? Well… no!
I can’t count the times I realised that this is actually not true. For years, I left meetings disappointed. Or maybe confused. Why are the people I work with slowing me down? Isn’t user satisfaction the reason why we build our product in the first place?
Sadly, not necessarily. The bigger the company, the more complex the decision-making, especially in environments where profit isn’t the main driver. Governmental organizations for instance.
Many big companies have in-house software teams. These teams work on systems that make sure that the company can operate. Internal processes, supply chain, administration, that kind of stuff. User adoption, sales, online reviews, or UX in general, are not so important in this context. Employees are usually obliged to use these systems, so why optimise?
Working in a context like this can be challenging for a designer.
You might help the company by saving a lot of costs. You mitigate administrative errors. You decrease the time it takes to process an invoice. You reduce cognitive load for all employees. All impactful work, but how much is it really appreciated?
Office politics are a big factor in your success. But how much is the organizational culture ready for strategic design? Let’s have a look at a few examples to illustrate our challenges.
How does your company appraise and promote? Are you rewarded for the success of your product? Are hard metrics used? Perhaps not. In traditional environments, it’s likely that supervisors assess your performance on gut feeling. This potentially doesn’t affect how you design. However, this might not be the case for the people who collaborate on your design.
If performance reviews are, maybe unintentionally, based on anecdotes, then hard metrics don’t count. This means we might want to please our supervisor, who gets orders from higher up. We can be forced to support the unrealistic ideas that descend from the C-suite. A logical feature might be delayed because another feature, requested by someone important, must be done first.
Is this the rational thing to do? No. Absolutely not. Your team has carefully worked on a strategy. This is now undermined by an executive, who might not understand the bigger picture. Or didn’t go through your elaborate user research.
You have no choice but to work on the tasks your supervisor gives you. Next year’s salary increase for all your team members is at stake.
How to deal with it?
Give your boss a good understanding of what you are trying to achieve
Our classical user and stakeholder-centred design workshops can help to keep us on track. We should involve our superiors as much as possible. It will give them awareness about why we design particular things. Perhaps even more importantly, it will also increase trust.
Our workshops will also give our supervisors motivation to push back on demands that will come from their bosses.
Tom Greever wrote in his book “Articulating Design Decisions”
Our role is also to make sure our stakeholders have what they need to represent our work to other people. We have to give them the tools and vocabulary to succeed in those conversations too.
Give your boss as much ammunition and awareness to defend your team’s vision.
If you receive “demands”, try to understand the motivation behind them. Someone might say “implement payment method X”. But why? What’s the business value? Maybe the reason behind it is just because the demander wants to please a political connection. The business value for the demander might be to have a more stable relationship with someone, rather than a better UX. This can be valuable too. It’s just political value.
It’s sometimes inevitable to make some adjustments to our designs. Occasionally, one step back will quickly lead to two steps forward because you’ll have more political leverage.
Some stakeholders worked hard to earn a particular role in their organization. After years of suffering, they became lead of X, head of Y, or chief of Z. Representing the domain they lead is now their aim. They have to prove their worth and need to show achievements.
Your design project might be a platform for them to do this.
You’re working on your company’s homepage. The head of marketing wants a newsletter sign-up, the head of HR wants a careers box, the head of communication wants a news section, etc. etc. Shambolic and compromised designs are the results. Everyone wants a piece of the homepage- or dashboard-pie.
How to deal with it?
Form alliances before you present your designs
A cheap approach would be to leave some obvious flaws in your designs. Your stakeholders will point these flaws out. You can present your new designs based on their input. They will be happy that their comments have been taken into account. They will have a sense of influence.
It would be more honest to design the best solution from the beginning, but sometimes you might need to fall back to your last resort.
A better approach would be to form alliances. Do this before you come to the meeting where you present your work. Find people that will defend your design. They will be able to help to influence the entire room. Another quote from “Articulating Design Decisions”
You want to find the swing votes that will build a majority or ask other people to be prepared to help you. […]
Getting other people to support your decisions is about showing that you’re not alone in your ideas. It demonstrates that there are other smart people in the room who agree with you (and who may have more relational capital than you).
Map your stakeholders to have a good understanding of the political relations you are dealing with. You can create diagrams to analyse their relationships.
As Eric Stephan Moore points out in his article “Are you prepared for office politics in a remote workforce?”
Start by visualizing the people impacted by the work issue. Map out the landscape of people who affect or are affected by the conflict. Make a note of their interrelationships and what you’d like to learn from them.
We now know that colleagues might want to impress their supervisor. Direct colleagues showing off to each other can be another thing you might have to deal with.
You probably know how these meetings go. When someone talks, the other person is not really listening but is only busy preparing to say something that sounds intelligent. The meeting becomes more like an alpha baboon vocal arm wrestling contest. Independent one-liners are being shared but there is no real conversation.
Their loose comments are not helping you with the designs you just presented. In fact, they can harm a lot. The stakeholders are looking for elements in your mockups that they can use to show their know-how. They want to criticise you for the sake of being critical.
As the interaction Design foundation explains in an article:
In one of my previous jobs, we spent more time in meeting rooms, where the C-Suite conducted witch hunt after witch hunt, than actually doing any real work. Any decision that had to be made required 10 different signatures and none of the signatories was prepared to give an inch to work with any of the others.
How to deal with it?
Let the stakeholders make the decisions themselves and give them credit for all design choices
Our designs are not going to be approved if we want to take credit for our work. We should give the spotlight to our stakeholders as much as possible. Preferably to all the stakeholders at once.
Democratising design through workshops is a way to not put the strategy in the hands of a single person. This will lead to better decision-making but will also reduce the “us against them” sentiment. We should try to make the “them” (the executives, stakeholders etc), become part of “us”.
Let the workshops guide the decisions.
Use dot-voting exercises to let the group come up with the direction. Be aware that all your participants have different motivations. Cheryl Platz addresses this in her article “Design techniques: Better dot voting”:
Are you asking everyone to vote for their favorite? If so… are you confident that “favorite” means the same thing to different people?
After you worked on the direction that came out of the workshop, you need to present your reiterated design.
Link all your choices to the particular desires of your stakeholders. Show that have been addressed, even if they are a bit far-fetched. “Based on Joe’s input, we decided to…”
Make sure to convey how the stakeholder’s input is used as much as possible.
If you work in-house, you might have a task to improve the administrative processes done manually. Perhaps those processes are still done on paper. With signatures, internal mail, and paper archives. Yes, they still exist. Or, maybe, your company’s future relies on spreadsheet-4.82_new_NEWEST.xlsx.
In a start-up organization, you can imagine that you would work on a system that automates customer support. We could optimise the handling of the most common user questions. Or we can automate unsubscription flows.
When you start this design task, you probably already imagine smooth automated scenarios. Your ideas are might even relatively easy to build. Your engineering peers can do this in a breeze.
However, automation could mean that some of your colleagues become obsolete. jobs will be lost. When you want to conduct your UX research with them, you will not be received with open arms. They might want to avoid the change you are working on to protect their job.
We should not underestimate the impact of job insecurity. The study “Job insecurity and health: A study of 16 European countries,” describes how it can affect our lives:
Having an insecure job is associated with an increased risk of poor health in most of the countries included in the analysis. Given that job insecurity is likely to increase as the labour market becomes more globalised, governments and labour unions need to pay attention to job insecurity and its public health consequences.
How to deal with it?
Don’t put yourself in the role of HR or management. Verify before starting your research.
Let’s start with the basics: communication. Do the people you have to interview know all about your work and the implications? You shouldn’t be sent without them knowing everything they have to know.
Reach out to the executives. Verify that your users are aware. Don’t take for granted that everyone is informed because communication is sadly often neglected. You want to avoid being the messenger of bad news. This is the job of HR or their direct managers.
Inform yourself too.
Find out what the contract structure of your users is. Will they really lose their job or will they transition into something else? If they will be replaced, how is this solved? Make sure that they are mentally ready to speak to you.
If they stay with the company, lay out how their expertise is essential to the workings of the new functionality. This will be a great opportunity. Give them the possibility to be the architect of the new feature (see the next section: reputation).
Legacy systems. A dirty word to many. But not to everyone. Some people created these systems and might be proud of them. Rightly so.
The world was different in the ’90s. I’m not saying these are the good old days. They were more like the complex old days. Some bright minds put systems in place that digitised our world. Some of these systems are still used on a daily basis. This only shows how well these systems were crafted.
Obviously, the systems now have suboptimal usability and rely on antique technologies and code that became messy over time. The system still does the job, but changes might be needed.
Even fairly modern systems can be considered legacy. The fact is, most companies rely on software that’s not following the fanciest UI and code patterns.
The specialists that put these robust systems in place, can wear this as a medal of honour. It’s possible that they designed the UI themselves, or that they wrote the codebase when some of you weren’t even born. Redesigning their system means taking away a part of their identity.
We can think that legacy systems are boring and old, but “How Do Professionals Perceive Legacy Systems and Software Modernization?”, a study done by scientists at the University of Utrecht, shows a different view:
…evidence that legacy systems are not necessarily a quagmire, but are business-critical, reliable and proven systems that effectively execute the day-to-day business of organizations. Such perceived benefits of legacy systems are the factors that keep them alive in the industry.
The older generation can be proud of their achievements.
How to deal with it?
Give the original creators of legacy systems as much influence and recognition as possible.
We should involve the OG architects heavily in the design process. From the first step on. We will come across some resistance. Nevertheless, when old engineers realise that they can be a part of the modern future, we might be able to engage them.
By giving them controlled control over the future shape of the system, we can help them to hold on to their identity. We might be able to give them some sort of ownership over the system, depending on how your organization is set up. Maybe they can have a new role that makes them responsible for a part of the new system.
Build upon their expertise. Don’t disregard it. They have a lot to offer and a lot to lose.
You, as a designer, are probably an imaginary thinker. Someone who’d rather see the world change today than tomorrow. But change is not easy for everyone.
Most of us love our habits. A small change can derail our entire routine. Yes, “we’ve always been doing it like this,” can be a frustrating answer. But there can be deep emotions behind it. Fear of change is real. Something that shouldn’t be underestimated.
As designers, we are well aware that, if we change something in an interface, we might have an impact on the full user journey. Our risk-averse colleagues, customers and users realise this too. Fear of the unknown can make them very uncomfortable. This means that design requires a decent amount of change management. You would want to plan some extra time, just to help your stakeholders get used to new ideas.
Change management can be needed for a simple change in a sign-up process that has an impact on the support team. It is even more relevant when you redesign an internal system that completely changes the way a company is organised.
How to deal with it?
Guide your stakeholders in getting used to the new normal.
The one thing you want to avoid at all costs is the Steve Jobs’ “tadaaaahh” moment. Don’t overwhelm anyone with abrupt introductions to a new reality. You also wouldn’t want to put your stakeholders in a situation where they think “why did you not ask me?”
Take them along on a change journey. Involve them in every step. Give them the possibility to express their desires or current pain points. Interview them. Organise journey maps where they can add their inputs.
Amy Blackburn describes this in her article “Five Steps to Reducing Fear of Change at Work”
Holding a conversation about change at work is meaningless if you have no intention of actually listening to what your team has to say. Employee input can make all the difference in the work-flow of your company and can positively affect worker performance and customer satisfaction.
Don’t only involve your stakeholders in the discovery process. Share your mockups. Come back to them to show that you’ve taken their input into account.
I know that the content of this article can sound really intimidating. It’s not my aim to scare you, but I want to prepare you. You should be mindful of all the unspoken aspects of getting your designs approved.
You see that most situations require a similar approach.
Don’t try to be the hero. As a designer, you are a facilitator. You should give your stakeholders the idea that they designed your work. Involve them in each step of your process. Give them as much credit as possible.
Of course, the suggestions that I propose are just a few of many. Each group of people requires a unique path. We need our social antennae. We need to sense how people feel, what they need at a specific moment, and how we can help them.
As designers, we manage people and manage change. Our work has a big impact on everyone who’s involved. Obviously, we impact the end users of our product. But we also deal with everyone that supports the product. The engineers, the Q&A people, marketing, etc. etc. If you want to be a successful designer, you have to be capable of much more than being the best Figma artist.
Read the full article here