UX professionals often find it difficult to demonstrate the value of User Experience to enterprise product teams, especially when companies or organizations lack UX maturity. Perhaps you’ve found yourself outnumbered on teams of solution-focused developers and their like-minded peers, feeling as though no one understands your perspective. You might have been the recipient of a dismissive arm wave. Maybe someone has told you that a product or a feature does not require UX oversight—even though it does. Perhaps stakeholders have told you that they already know what users want or there isn’t enough time to address a product workflow that could satisfy a core user need.
When you meet resistance from teammates and stakeholders, do you turn tail and slink away, then allow a product to go to market without its receiving the appropriate level of UX attention? Hopefully not! Some battles are worth fighting—as uncomfortable as they might be. As I described in “Demonstrating the Value of User Experience to Enterprise Product Teams, Part 2,” responding tactfully to caustic feedback from teammates is a challenging skill to master. It requires empathy, a trait that UX professionals must often draw upon in relating to the people who use our products. It is just as important to demonstrate empathy for our teammates, who are under their own pressures and must often meet challenging deadlines.
But there is a limit to how acquiescent you should be—especially if you’re conceding issues that would negatively impact core aspects of a product’s user experience. Knowing when to advocate passionately for the user versus when to capitulate is key. Outnumbered UX professionals typically have a limited influence, and your influence capital can dwindle quickly if you choose the wrong battles or dig in your heels over every minor issue. You’d then have very difficult obstacles to overcome when you need to collaborate with wary teammates on something that is truly important to the product’s user experience.
In this column, which is Part 1 in a series of two parts, I’ll present some scenarios in which it makes sense to demonstrate flexibility with your product teammates and stakeholders:
making aesthetic choices
employing custom patterns and controls
following a UX process
managing teammates’ expectations
using UX jargon
defining the scope and timing of products and features
In Part 2, I’ll focus on some scenarios that necessitate your taking a firm stance, then offer some suggestions on how to decide whether a situation befits taking one course of action over the other, acknowledging that the best approach can sometimes be ambiguous.
Making Aesthetic Choices
The saying, “kill your darlings,” is in common use in the literary world, exhorting authors to cut any self-indulgent passages or prose that does not serve the broader story—even if it’s beautifully written. The mindset behind this saying applies to any creative process, including UX design.
Ask yourself whether you are negatively impacting the user’s experience of the product by refusing to let go of that darling you so desperately want to include in a release. You might be in love with the generous amount of whitespace in your design mockup, the understated elegance of the font you’re recommending for your design system, or perhaps the style of the icons you’ve painstakingly drawn by hand, but do any of these things really benefit the overall user experience? Do they help users to achieve their goals? Even though the aesthetic-usability effect can cause users to perceive a visually pleasing experience as easy to use—even if its usability is just average or even poor—do not give aesthetics priority over creating the most efficient, effective, satisfying user experience possible. While a popular aesthetic choice might work well for business-to-consumer software users, that does not necessarily portend its success with enterprise-software users.
Also, think about whether the implementation of trendy patterns or visual elements would justify taking developers’ time and effort away from other more critical aspects of the user interface (UI). Including unnecessary, merely decorative UI elements risks slowing down an application’s performance, as well as the pace of users’ work; getting in the way of users’ ability to achieve their goals with your product; and negatively impacting the amount of time and effort the development team can expend on building the right thing for users. Time and effort are both finite resources and developers are human. Don’t run the risk of adding to their fatigue by demanding unnecessary UI elements that won’t actually benefit the user.
Employing Custom Patterns and Controls
As with other lower-priority, aesthetic choices, you might unnecessarily add to the developers’ burden if you ask them to implement custom patterns or controls. Even if the UI elements you’re proposing in your design specifications would deliver a wow-factor, sticking with the familiar, native patterns and controls that operating systems support is usually best. They offer the benefit of years of their repeated use and copious documentation. Plus, native UI components get updated automatically, along with updates to the operating system, so they’re generally less buggy than custom solutions. Their use also prevents developers from having to maintain custom solutions in the future.
Most importantly, familiarity and consistency contribute to usability, which benefits users. A Web site or application does not exist in a vacuum. Introducing a foreign pattern into users’ software lexicon risks confusing or frustrating them because they won’t be able to draw upon their existing knowledge to achieve their goals efficiently. Is it sometimes necessary to forge new experiential ground? Of course, and it’s important to recognize when such opportunities exist. Implementing a superior, more efficient approach of doing something could deliver a key brand differentiator.
As with issues of aesthetics, if you’re facing a decision regarding whether you should push for a custom solution, ask yourself whether your solution makes the user’s experience more efficient, effective, and satisfying. Also, determine whether the value of implementing the solution would justify expending the development team’s time and effort. If your answer to both of these questions is no, it’s likely a self-indulgent design solution.
Following a UX Process
Of course, your darlings won’t necessarily be part of a UI design, and you might not be able to put them on the chopping block. But even if you can’t kill them, that doesn’t mean you can’t revise them. Consider your UX process. Perhaps you’ve cultivated a tried-and-true approach with a previous product team, organization, or company. However, when you onboard with a new team, your teammates won’t know that you prefer user research to precede sketching, sketching to precede designing wireframes, and designing wireframes to precede high-fidelity mockups and specifications.
Regardless of what processes have worked for you in the past, be empathetic to the mindsets and needs of your teammates. Not everyone has a shared understanding of User Experience and all that it entails. Be flexible about ramping up your colleagues’ knowledge of the UX process. For example, some people are highly visual so, try as they might, won’t fully understand your role or the experiences you’re proposing until they finally see a high-fidelity design mockup. Plus, a project stakeholder could be mistrustful of qualitative usability metrics—favoring quantitative data and statistics that prove,in their mind, that a design solution is a worthwhile investment. Educating teammates and stakeholders is part of your journey as a UX designer. Be flexible and forgiving of your colleagues’ preconceived opinions and expectations about what you’ll deliver and when. Do not become argumentative if they do not immediately understand your approach. Instead, coach them as you adapt your approach, working to find a mutually beneficial middle ground.
Managing Teammates’ Expectations
The level of engagement that developers and stakeholders expect from you could vary greatly, depending on the company’s culture, the nature of the team on which you work, and the team’s cultural predispositions—a common issue with global companies—or personal preferences. I’ve worked with both individual developers and development teams who embrace and enjoy being included in collaborative design activities. Conversely, I’ve worked with individuals and groups who simply want a design artifact in hand so they can finish implementing their user story and move on to the next one.
The ways in which developers prefer to engage with UX professionals can differ. Every team and every individual might have a different mindset. Sometimes the mindset of a single individual can permeate an entire team, creating a microculture that mirrors that mindset. You cannot force developers to change their existing mindsets to better facilitate your preferred processes. They won’t change, and you shouldn’t expect them to.
So it’s best not to make assumptions when onboarding with a new team, organization, or company. Resist the urge to view an entire team as having a single mindset. Solicit your teammates’ ideas individually so you can understand how involved each of them wants to be in the UX-design process.
While it’s perfectly acceptable to communicate your preferred level of engagement, give your teammates plenty of opportunity to influence the nature of the relationship and the processes you’ll follow. If they seem open to a deeper level of engagement, invite them to participate in ideation activities and design reviews. But don’t stop there: demonstrate emotional intelligence as you reflect on your teammates’ responses to your overtures and how involved they actually become in the ensuing activities. You might be surprised by the eagerness that certain individuals express whom you hadn’t expected to become deeply engaged in the UX-design process. If this happens, continually solicit their involvement, reinforcing their interest. The perception of User Experience as a shared responsibility will gradually mature.
Using UX Jargon
As with process, be forgiving of the terms and phrases your teammates use in characterizing your work. There’s nothing personal about this. They’re learning. As Chris Braunsdorf and I explained in “Demonstrating the Value of User Experience to Enterprise Product Teams, Part 1,” you could quickly alienate your teammates by becoming mired in semantics or reacting defensively to the words they use. Instead, endeavor to educate your teammates gradually by demonstrating the value of User Experience in more meaningful ways.
Keep your own UX jargon in check. Using unfamiliar terms such as heuristic evaluation, contextual inquiry, or cognitive walkthrough with your teammates, who lack the proper context or experience to fully understand them, only results in blank stares.
Defining the Scope and Timing of Products and Features
Perhaps you’ve seen the illustration shown in Figure 1, which uses a transportation metaphor to demonstrate the virtues of building a minimum viable product (MVP) over using a more traditional approach such as waterfall or iterative development. The MVP approach theorizes that a skateboard or a scooter solution would still address the underlying user need for transportation, even though these vehicles don’t boast all the features of a car.
Agile and Lean development have matured within many companies. If you work on one of these teams, you’ve likely encountered scenarios in which stakeholders sometime push back on design solutions that fall outside the scope of the business’s defined MVP—which often shifts depending on the team’s velocity and the product’s target release date. Any improvement that doesn’t support the product’s evolving value hypothesis usually gets deferred to a future release. This might include your work deliverables—however compelling they might be. Could you work several sprints ahead to craft a vision for how the car might work? Of course. Always push the team toward envisioning the bigger picture.
There is tremendous upside to projecting a vision, which generates excitement, builds morale, shows your team what is possible, and most importantly, lets you and others think through the user’s journey in a more holistic way. However, designing the full vision should not take priority over what your teammates need from you now to make the MVP work for its intended users. Ensure that your teammates have what they need. Don’t burden team members with aspirational workflows for the distant future or gripe about your not getting everything you wanted into the first release. Effective agile and Lean teams release software often. A team that adheres to agile or Lean principles and executes on releasing a product that users truly want earns its right to iterate. They’ll eventually see their full vision come to fruition—assuming that early user feedback doesn’t necessitate a pivot in a new direction.
But what about other development methodologies? Perhaps you’re working with a product team that still relies heavily on waterfall development, and stakeholders and developers expect you to deliver all of your UX-design work up front. Often, with such monolithic product-delivery approaches, a failure to champion your full UX vision at the outset of a project results in the release of a subpar solution that can become frozen in time. In this scenario, you must passionately advocate for the most comprehensive vision possible before development begins, a situation that I’ll address in Part 2 of this series.
Even if you encounter resistance from stakeholders and teammates, you should assume good intent on their part. Most people care deeply about the product they’re sponsoring, designing, or building. Continually demonstrate empathy toward them. You might need to rely on their empathy in the future.
Remember, if you prescribe self-indulgent aesthetic choices or custom patterns and controls, you risk doing a disservice to users by needlessly subjecting them to distracting affordances or unfamiliar paradigms. These can also becomes the scourge of developers, who must spend their time implementing alternatives to existing native counterparts that are well supported by operating systems and browsers.
Adapt your UX process as necessary and be flexible in the level of engagement you expect from your teammates. Remember, not everyone shares your understanding of User Experience and all that it entails.
Be forgiving of the words others use in characterizing your work, and avoid complicating things by needlessly adding to your teammates’ vocabularies—especially if your company’s road to UX maturity is steep or poorly paved.
Finally, be realistic about scope and timing constraints. Avoid toiling on designs for future features at the expense of delivering what your teammates need now to complete their work. A team that successfully releases a product that satisfies core user needs—even if just a minimally viable product—earns its right to iterate.
The scenarios that I’ve described in this column, as well as those that I’ll cover in Part 2, are highly derivative of my own experiences in collaborating with a variety of enterprise-product teams. Perhaps you’ve encountered other scenarios. If so, please describe them in the comments. This topic is broad and highly contextual to specific product domains, company cultures, and designers’ personal experiences—including your own.
Jon has a degree in Visual Communication Design from the University of Dayton, as well as experience in Web development, interaction design, user interface design, user research, and copywriting. He spent eight years at Progressive Insurance, where his design and development skills helped shape the #1 insurance Web site in the country, progressive.com. Jon’s passion for user experience fueled his desire to make it his full-time profession. In 2013, Jon joined Rockwell Automation, where he designs software products for some of the most challenging environments in the world. In 2020, Jon became User Experience Team Lead at Rockwell, where he balances design work with managing a cross-functional team of UX professionals.