Design Leaders: Three Unspoken Realities of Product Design Your Team Needs To Understand

After 25+ years in the industry, I continue to come across situations that I'm not necessarily prepared to deal with when walking into a room (and I do prepare).

The vast majority of time such issues are tied to the complexity of the problem that the team is attempting to frame or solve—from technical roadblocks to a lack of clear insights to overly complex notions that find their way to a whiteboard.

These scenarios represent what I love about collaboration in our field—people with diverse backgrounds, skills, and agendas come together to solve wicked problems with, at times, elegant solutions.

But product design isn't a paint by numbers activity; there are a number of misconceptions about the nature of how product gets made that can catch even the most seasoned designer off guard.

Inclusive design benefits all of us, including the bottom line, but such statements alone won't impact a product roadmap.

Industrial design calls for a high degree of up-front research, ideation, and craft iterations due to fabrication being a one time effort with a fixed cost—such companies only have one shot to make an impression with the consumer and not blow their production investment.

With digital products, Design is steeped within the tradeoff game to get a product to market quickly, secure customers, and iterate additional value. Talented product marketing teams know how to frame the rough edges of early releases so that customers experience limitations within the context of progress.

When it comes to inclusive design in digital products, a team could take the same approach to that Ford took in the above video, but such an approach won't align with the accelerated time to market goals that dominate our industry.

This bottom-line reality of organizations that I've worked within makes inclusive design a progressively tougher sell simply because, by definition, user requirements deviate from standard solution patterns.

Yes, it's frustrating, but zero profit spaces have a different DNA.

If market research doesn't clearly point to market differentiation potential through an investment in a wider array of features that serve everyone, your CPO will most likely tout the The Pareto?Principle as they narrow their prioritization.

So if inclusive design is important to you, and you're attempting to sway leadership, you'll need to think strategically to start stacking wins.

#1 Consider accessibility standards as the foundation of a successful inclusivity program—they can become a fixture of both the design and engineering approach rather early in any product lifecycle.

High contrast colors, readable & scalable type, labeled interface elements, and tab flows for screen readers are all standards that designers can easily implement into a design system. Engineers have the tools within their platform frameworks to rather painlessly support the needs of blind, diminished sight, deaf, and HoH users.

#2 Inclusive design programs can be perceived as added complexity— necessitating upfront research to elegantly support the needs of people with diverse attributes and environmental context. Obtaining runway for such research and design thinking is 100% dependent on the perceived value of the investment. This is where you need to consider the greater context of the organization.

For instance, I'd think twice about framing up a formal 'inclusive design' program if the CEO of your Series A startup needs a launched product yesterday to rally investors.

Similarly, a CPO steadily driving towards a Series D fundraiser is most likely already facing difficulties reaching scale while delivering on requirements that her peers in sales or marketing are generating—not to mention feedback from customers and insights from data analysis and user research.

I'm not saying that you shouldn't believe in the power of inclusive design to enable all people access to a great product experience and impact the bottom line of your company.

What I am saying is that there's a proper time for such work, and there are strategies to assist you in making your case.

Consider:

• Check the numbers. If you're selling into large institutions, a percentage of their employees will show the need for accessibility support. Might there be other opportunities in the numbers if they're sifted through with inclusivity in mind? Is ESL highly represented in the numbers? What about socio-economic status differences? Cognitive differences? Age? Physical limitations?
• How might you include inclusive design within established ideation activities? Consider coaching your designers to introduce an array of exclusionary design personas into brainstorming, even for what seems to be broad problems. Have teams ideate with such context to see if unforeseen gaps can be identified. Participating PMs and engineers will be more likely to rally behind resulting concepts.

Textured innovation comes at a cost that must be invested in with precision.

I may have just coined the term 'textured innovation,' but it seems like the best way to describe interwoven layers of a product—from breadth of capabilities to how they're experienced by people across tiers of executed and maintained delivery platforms.

This isn't necessarily how executives view the notion of innovation .

The vast majority of founders consider even the most basic execution of their mission that finds a market to be the primary innovation of the company. It's a classic business approach of prove the concept in-market, and then pragmatically fortify, and advance the service.

Of course within such a journey there's room, even a need for innovation, but never innovation for innovation's sake.

Ask yourself: Why would product leadership expand the focus of resources to invest in design innovations, even micro-interactions, if corollary data aren't clearly pointing in a direction that expands market share or generates more revenue?

The very definition of product prioritization runs counter to the notion.

Designers who desire to attack problems with novel, innovative solutions need to ask themselves whether their concepts are truly valuable.

Are we considering operating variables, such as limited development resources or the impact to speed to market?

A/B or multivariate testing can gauge which solution works better than another, but these testing approaches can't give quantitative results unless a service has a critical mass of users already in play.

It's difficult to prove upfront that two more weeks of design and engineering time to execute, for example, an innovative form design, will be more valuable than knocking out a best practice approach.

If your designer slips an expensive execution past the team without either a clear design hypothesis or research findings that scream ROI, you might never be confronted by your peer leading product management, but the reputation of you and your designers can quickly shift from being force multipliers to something more akin to blockers.

Reinventing the wheel and expanding the scope of a feature is time taken away from deepening core capabilities to meet market requirements.

Conversely, designing a product into something that looks and behaves too much like what's already in market—to follow the path of what's cheapest and fastest to build—could very well fail to establish necessary differentiation from competitors.

The challenge seems to be: How do you nurture designers to lean into empathetic human research, great collaboration with peers, and prototyping and learning with users as the center of an innovation engine, rather than focusing on feature or UI innovation?

Consider:

• How engaged are your designers in the problem framing space? Help them secure a seat at the table early. Are they working closely with the product manager and lead engineers? Coach them to ask the questions necessary to understand desired business and technical outcomes. Make sure they're either leveraging user research to understand everything from the breadth of a user's journey to the nuance of their behavioral needs or know how to plan their own design research. Once designers have informed intuition through such investigations, they can represent human centered scenarios at the fidelity that the conversation dictates (e.g. journey maps, prototypes) and move towards a solution with everyone onboard.
• Increase collaboration with engineers. If you lead a centralized partnership where the design team works across product managers and engineering teams, do what you can to replicate a pod structure by having your designers engage early and often. Designers should be floating sketches, exposing prototypes, and learning what they don't know about execution alternatives. If their discussions point towards novel innovation, then great, have them dig in; otherwise, they should be specifying the most simple solution in order to learn quickly and iterate.

A design process is useful; a design framework will empower your entire team to solve problems with better results (and often quicker)

If I were to identify an agreeable outcome for you when visiting my home—let's say enjoying an hour in the pool in my backyard—how might I best help you to reach such a goal?

One approach might be for me to give you directions to my home, how and where to park, instructions to knock and to call out my name if I don't respond, where to change into your bathing suit once in the house, where the towels are, what door to exit to find the pool, and the location of the best entry into the water.

But what if you were walking, not driving, and already knew where I lived? What if you had laryngitis? What if you were already wearing your bathing suit, wanted to surprise friends in the backyard, and just grill and layout without getting wet?

An assumptive-laden experience won't meet the needs of all humans engaging with your product, let alone your core customers.

Similarly, a prescriptive process for designing, building, and shipping product won't fit neatly into every initiative scenario.

Processes provide a high degree of prescription—they're perfect as protocols for reproducibility, but not so much within the dynamic realm of product design where degrees of understanding and risk (e.g. How much do we know about the problem? How much do we know about the people who will use this? How well might this solution work?) drive how a team invests their time towards designing a solution.

For example: a standard design process might be to first brainstorm, then design, then build, then ship, but how would such a process serve our pool guest example where the addition of user research would completely change our host's approach to meet her guest's needs?

And what if a particular problem isn't novel, and the solution is rather straight-forward? Is it a solid investment to invest deeply in both user research and brainstorming sessions?

Might we forgo the exercise of bringing a cross-section of stakeholders and users into a room to ideate—producing a real cost and creating downstream expectations—when we can quickly move on a solution?

For such a low risk example, might quality feedback come from people using the product in production (if it avoids endangering the brand or the customer experience)?

When design leaders hit the wall of leaning into prescriptive processes, they tend to become more logical, mapping out if/then statements for how their teams might operate.

This shift turns their linear processes into less prescriptive methodology , yet more complexity is introduced and it becomes harder to align cross-functional teams around.

My advice is that if you're heading in the direction of creating a singular methodology, you're far better off focusing on developing core frameworks.

What are a framework's key attributes?

Adaptability: A framework should be flexible and adaptable to different scenarios, acknowledging that not every situation requires a one-size-fits-all approach.

Guidance, Not Prescription: Instead of prescribing specific steps, a framework offers guidance and principles, allowing teams to tailor their processes based on the unique needs of a given project or initiative.

Strategic Alignment: A framework should align with the strategic goals of the organization, providing a structured yet versatile foundation that supports cross-functional collaboration and innovation.

Design thinking is a simple yet powerful framework, intentionally designed to be as flexible as possible while providing practice principals that allows the project team to move forward as the DNA of the problem and solution spaces dictate. Teams using DT don't follow phases blindly—e.g. people don't 'empathize' in one phase and stop empathizing in the next.

The downside with frameworks is that by operating with less prescription, more senior ICs are needed in order to make sound decisions to navigate the framework's inflection points.

The questions become: Is your team following strict protocols and engaging in unnecessary activities and artifact creation in spite of the challenge at hand? How can you introduce flexibility and efficiencies that generate effective collaboration and results?

Consider:

• Introduce elements of a potential framework to your team in bits and pieces across different projects to eventually operationalize a framework that meets the needs of your particular culture. Have your lead designer run a single brainstorming activity with the XFT and frame it as being at "this point" in your design process that unlocks a next activity; propose a simple research project at an earlier point to determine desirable user outcomes before beginning any work, and get cross-functional team alignment on your framing so that the impact you're pursuing is understood. Once you have a stack of wins exemplifying value, co-create a framework with XFT partners, aiming for what fits your particular organization and culture, and shop it around for broader feedback.
• Beg, borrow and steal. Alan Cooper's Goal-Directed Design was a game changing user-centered methodology, well before its time—it was also perceived as overly prescriptive with too much time spent upstream, reducing time to learn through iterative shipping cycles. This kept GDD from being implemented across a myriad of in-house software development cultures. If you were to pluck, say, user interviews, data collection, and persona modeling from the GDD method, you'd have a useful set of activities and artifacts that could be used in any framework based on need. What might then happen if you were to sprinkle some Agile inspired, time-boxed design sprints into the mix? Don't be afraid to custom concoct a framework from existing elements in the wild.

Final thoughts

With all of its moving pieces, digital product design would make Dieter Rams toss his drafting table out the window in frustration.

As a design manager and a leader, a primary aspect of your job is to keep your designers focused on the work itself, but the nuance of how and why they work the way they do becomes just as important to success—to their career, the customer, and the business—as the research they perform, the concepts they present, and the pixels they specify.