New designers or designers with start up experience can get a rude shock when they take on enterprise UX work. Here's how you can overcome those challenges.
.png)
At PebbleRoad, we work with large organisations and help them drive transformation by delivering impactful, sustainable products and services. New designers or designers with startup experience who join our team sometimes get a rude shock when working on such engagements; they feel like someone pulled the carpet under their feet. Nothing works as they expected; instead, they feel like everything is working against them.
Our Product Owners plan for these situations by picking up the signals and mentoring new designers on enterprise life and how to understand and navigate it. In this article, we present notes from such conversations in the hope that it will help designers who want to work for and drive change in such complex environments.
We’ll cover the top 10 challenges that designers who are new to enterprise UX face. These are:
In a startup, everyone (at least most of them) understands your role as a designer. Whether you are a product designer, service designer or content designer, a set of expectations is established at the outset, shaping all subsequent interactions.
However, when working with an enterprise, this might not be the case. You are covered if the organisation has a mature design department. However, in most cases, you will work with specific business units or the IT department with an ad hoc sprinkling of designers (or no designers at all), and they may harbour some wrong assumptions about a designer's role. Some people may think of you as the person who "makes things pretty", or worse, a person who is "clueless about business stuff". Be careful of these assumptions as they set the tone for the entire engagement.
Suss out the maturity of the enterprise. Find out if they have worked with design teams before. Study the work they have done and are currently doing. Arm yourself with stories and narratives of how design is becoming a way of doing business in the modern age. Find opportunities to tell and retell these stories and aim to break detrimental design myths in the enterprise. Learn how the business operates. Work out the business model of the enterprise. Start learning business design. Read Reimagining Design, Kevin Bethune’s story of his life as a designer at Nike.
While overcoming the 10 challenges may seem tricky, remember that you are not doing it alone—you have the team to support you.
If you are used to having a few stakeholders in a startup or SME world, get ready for a complex web of stakeholders in the enterprise world. At times, it will feel like every senior person in the enterprise is a stakeholder. To make matters worse, all these stakeholders may have different views of their stake in the project. To top it off, some stakeholders may have political agendas with the other stakeholders. Then you have the HiPPOs (highest paid person’s opinion)? Yikes!
Study the stakeholder environment for your project. Map it out. Find out who are primary and who are secondary stakeholders. Carry out an RACI or DICE exercise and figure out how to set expectations and communicate with each type of stakeholder. The more well-versed you are with the stakeholder environment, the easier it will be for you to navigate your way around the enterprise. Read Art Kleiner’s Who Really Matters: The Core Group Theory of Power, Privilege, and Success.
In an enterprise with a mature design practice, you can leave it up to the leaders to make the right decisions. But in an enterprise that is just starting to embrace design, decision-making will most likely be ego-driven and arbitrary. Your research and design logic will be glossed over and decisions will be made based on what “Apple would do”. You may find it extremely difficult to rationalise or grasp the logic of decision making.
As a designer, you must help to shape the decision-making process by starting early and educating the decision makers before the time for making the decision arrives. You can introduce the decision-makers to what makes good design by inviting design leaders from other companies to share their stories. Take the initiative to build the design knowledge and experience by holding brown bag sessions and inviting the decision makers to participate in such conversations.
If you sense a radically bold decision may be required (e.g. scrapping the mobile app), then you need to seed the possibility very early (over months, not days) and start building your case around it. Remember, your job is not to design a pretty-looking app but to help the organisation realise its business outcomes. It will help if you become a trusted advisor to the stakeholders. Yes, read David Maister’s The Trusted Advisor.
Enterprise products usually have many users. If you are not experienced with the design of multi-user products, you may get overwhelmed with their complexity. While your primary user may be the business owner applying for a grant, you also need to cater to the needs of the grant owner, grant approver, process administrator, legal counsel, finance representative, enforcement officer and the list goes on.
Don't panic. Divide and conquer. Depend on the process maps (see below) and take one user journey at a time. Like an artist, you'll have to learn when to lean in (focus on a user journey) and when to lean back (see the big picture). Think of Changi Airport and the passenger experience journey. The journey has many users, from ticketing agents to ground staff. While they have their workflows (e.g. ticketing workflows), in the end, they all align with Changi Airport's brand promise of offering "unrivalled passenger experiences".
As an enterprise UX designer, it would be best if you were on top of the user ecosystem. Know who the different users are and their role in the entire experience, and seek out the UX outcomes for each user group. Read Rethinking Users: The Design Guide to User Ecosystem Thinking by Michael Youngblood, Benjamin Chesluk and Nadeem Haidary.
Are you used to seeing clear, single-flow business process maps? Welcome to the spaghetti-like business process maps, where everything seems connected to everything else. “We’re building an import function to integrate third-party wealth data to provide better service to our clients”. That looks pretty clear, right? Wait till the business units, data, security, legal, audit, backend ops and others get involved. Your mind and body can quickly go into full shutdown mode. But resist, you must.
Learn the basics of business process mapping. At PebbleRoad, Susan Page’s The Power of Business Process Improvement is a must-read. Business process knowledge will give you the power to read and interpret process maps and find many ways to improve them.
You’ll be surprised how easily you will spot improvements because you bring a human-centred perspective to the boxes and arrows. Your effort in not just interpreting the maps but also offering substantial enhancements will go a long way in building your reputation and influence in the enterprise.
With such complexity in users and processes, you would think the organisation would overcompensate by conducting in-depth user research. On the contrary, you may find that the organisation has no respect for user research (“We know the problem”) or too much respect for a particular kind of research—quantitative studies. Trying to get a budget for conducting user interviews may be a tough sell.
Intervene early if you sense the organisation is not tuned to doing user research. Take time to explain the value of research from a business point of view—loss of time and productivity, cost of workarounds and overall disruption to business. Read Tome Sharon’s It's Our Research: Getting Stakeholder Buy-in for User Experience Research Projects.
If the business is leaning towards quantitative studies then bring up triangulation. Business people get the rationale of triangulation—different perspectives on the same thing—to increase the odds of having a substantiated result. Convince your bosses that you will do a survey, but you also need to triangulate the findings by doing a qualitative study. In research terms, this is called a mixed method study. Chances are, you will get the approval to conduct your observation or interviews. Check out Sam Ladner’s book, Mixed Methods: A Short Guide to Applied Mixed Methods Research.
Yes, enterprises are obsessed with data. It is hard to find someone who is not working on a spreadsheet. Even digital applications resemble spreadsheets with some automation included. As a designer working on a digital product, you’ll be presented with many spreadsheets, each having many fields and all somehow connected. Confronted with such complexity, you may easily give up and become an order-taker—“Just tell me the fields that I need to include in this form”. As you can imagine, this work can quickly become demoralising.
Learn data or content modelling. It surfaces the story behind the data, defines each item and shows how they all connect to each other. In our teams, the product designer works with the content designer to develop the content or data models so that each can better understand the lay of the land.
Mike Atherton and Carrie Hane’s book, Designing Connected Content: Plan and Model Digital Products for Today and Tomorrow, is a brilliant introduction to the field. With a thorough grasp of the data models, you will transition from order-taker to meaning-maker, and the confidence will help you design great products and get respect from the subject matter experts (SMEs).
If data is everywhere in an enterprise, so is measurement. If you are lucky, the enterprise has a well-thought-out process for measuring things. Otherwise, you will have to prepare to face a potpourri of measurement frameworks from personal favourites to flavours of the day (think NPS and OKRs). It is no wonder that many enterprises have dedicated people just for churning out ad hoc reports for different people. As a designer, you need to know about the prevailing measurement environment because it may affect your work.
Pay close attention to the existing measurement environment. Find out what the key stakeholders are measuring, why and how it connects to the business strategy. Dig for measurement stories from the past or attend meetings where measurements and results get presented. The saying, “What gets measured gets done”, is the gospel in the enterprise. If you want to grok measurement, pick up a copy of Douglas Hubbard’s, How to Measure Anything: Finding the Value of Intangibles in Business.
It used to be that designers and developers built the product and then passed it to the operations people to maintain it. Development and operations were two distinct phases, and the two teams did not cross paths. Business analysts defined the requirements upfront, which largely remained the same throughout the product's lifecycle. Not anymore.
These days, requirements are constantly changing and morphing to stay relevant with the fast-changing user needs and external environment, hence the rise of continuous design and continuous delivery. As a designer, you may be used to big upfront design, but now you will be subject to a continuous stream of seemingly ad hoc design briefs, and you might start to feel like a hamster on a wheel.
To get meaning from a seemingly disjointed design brief, do your part to establish context and direction. Ask a lot of questions. Review the goals, findings and feedback. Look for patterns. If the gaps are simple enough to fix, then accomplish them. If they are complex, then gather the team and conduct design sprints.
You will work closely with the tech and operations teams during this period. Use this opportunity to deepen your relationship with them and introduce them to the designerly ways of thinking. The continuous design period can be as fulfilling as the upfront design period. Read Jeff Gothelf’s Lean vs. Agile vs. Design Thinking: What You Really Need to Know to Build High-Performing Digital Product Teams.
If you are used to doing startup UX work with little or no documentation, you will be in for a rude shock while doing enterprise UX work. The enterprise project team may ask you about documentation during the project kickoff and at all subsequent meetings. At times, you may feel that the documentation will be the measure of your UX work. Resist that feeling, you must.
There may be many reasons enterprise project teams insist on documentation, from record keeping and audit checks to security against staff turnover and payment milestones. Find out the reasons for documenting design work and who will be using the documentation. Treat documentation like another piece of design work. Define what documentation is needed, such as research findings, insights, design principles, user stories, design decisions, design systems, etc. Use a collaborative documentation app such as Notion or Confluence and start documenting as you go. Present the documentation at project meetings and get feedback. With this iterative approach, documentation will become more of an understanding aid during the project and less of a thing to do at the end of the project.
Steve Jobs famously said, “Design isn’t just what it looks like and feels like—design is how it works.” And from this article, you can see that it takes a lot to make enterprise UX work. At times, you may feel that you don’t want to sign up for this tedious work and want to work in an exciting and lively environment. At PebbleRoad, a design practice servicing large enterprises, we also hear the same sentiments. Some design agencies even toy with us by saying, “you work with traditional, boring companies”.
Yes, in theory, that is correct. These companies may seem boring compared to well-funded startups, but these same companies are the ones that make the economy tick. These “boring companies” hire the most people and have GDP-shifting influences on the economy. From this point of view, helping make progress in these companies looks like a cause worth designing for.
Also, while overcoming the 10 challenges may seem tricky, remember that you are not doing it alone—you have the team to support you. Are you stuck with user research? Reach out to the UX Researcher on the team. There are also informal UX groups online that provide support and advice, including the Content Strategy Singapore Meetup group that PebbleRoad is a founding member of.
So, if you are new to enterprise UX, do not feel discouraged by the challenges. Pull up your socks and prepare for a fantastic adventure over rough seas!
I enjoy helping organisations achieve their potential in an ever-changing and complex world. I lead product and transformation conversations.
