Choosing Your Battles, Part 1

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.

Image source: “Making Sense of MVP (Minimum Viable Product) – and Why I Prefer Earliest Testable / Usable / Lovable” on Crisp’s Blog

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.

Conclusion

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.