Scaling UX Through Research, Product Vision, and Design Systems with Mitchell Clements | Episode #87

Mitchell Clements brings an engineering perspective to UX design and product management. He says designers do not need to write production code, but understanding implementation constraints helps them anticipate what engineering partners will face. It also helps designers assess proposals from more than one professional viewpoint.

Clements draws on his experience at Simple Nexus, where he joined as employee 17 and saw a simple product become more complex as the company added features. He explains how regular research, visual communication, product vision, and a maintained design system can keep that growth from fragmenting the user experience.

What you'll learn

• How to turn recurring user feedback into shared product context

• Why a visual product vision can align cross-functional teams

• How a product audit can establish the case for a design system

• How outcome-based goals clarify tradeoffs among speed, quality, and resources

Move research from collection to shared context

Clements does not prescribe one research method for every situation. He recommends regular exposure to users through a mix of qualitative and quantitative inputs because each method has different strengths and limitations. In the episode's rapid-fire section, he explains that qualitative research can reveal why something happens, while quantitative research can indicate its scope. His priority is consistency: teams should keep learning from diverse feedback rather than treating research as an occasional phase.

Collecting evidence is only the first step. When research remains with a researcher or product manager, stakeholders see the resulting proposal without the context that shaped it. Clements recommends exposing colleagues to the evidence through clips, testimonials, data, or research included in presentations. Every recommendation should show both the proposed action and the user evidence behind it. That makes disagreement more specific and helps stakeholders follow the reasoning.

He developed empathy for homebuyers by going through the home-buying process himself. The experience felt hard, overwhelming, and frightening. Product teams cannot always become their users, but they can expose themselves to users' challenges and work to understand the pain from the user's perspective.

Use vision and systems to control product complexity

At Simple Nexus, customer requests and new ideas kept producing features, but the growing product lacked a clear view of how those parts should fit together. Clements looked beyond the next three to six months and created concepts showing what the homebuyer journey could become over three to five years. Showing that future experience gave teams a common destination for their research, priorities, and implementation choices.

The same visual principle supported cross-functional coordination. A roadmap made of feature names can leave people with different interpretations. Clements visualized concepts so teams could understand how their work connected to the rest of the product. Teams can apply this by pairing roadmap language with enough experience-level detail for design, product, and engineering to see the intended relationship among features.

He used an even more concrete method to address inconsistency across web, iOS, and Android. The design team captured every screen, workflow, and interaction, printed the audit, and placed it on a wall. They then isolated the product's button styles and found more than 54 variations, including different colors, shapes, shadows, and treatments. Presenting that evidence at a company-wide meeting made the cost of inconsistency visible.

That audit helped secure support for a shared design language and coordination between design assets and coded components. Clements stresses that a design system cannot be completed once and checked off. It needs processes for maintenance, updates, iteration, and correction. Teams planning one should define ongoing ownership when they define components.

Align decisions around outcomes and narrative

Clements frames speed, quality, and resources as legitimate but competing concerns. Designers may push for the strongest experience, product managers may face delivery pressure, and developers may prefer the simplest implementation. He recommends aligning the team around the outcome it needs to produce. If adoption is the goal, the team must consider what scope and quality users need before they will use the feature. If market timing is the priority, speed may deserve more weight. Naming the outcome gives the team a basis for choosing tradeoffs.

This focus also connects UX work to the business. Clements advises teams to understand the strategy behind increasing revenue or reducing costs, then connect it to user goals. Research and design create business value when they help users solve meaningful problems, improve conversion, support product-led growth, or choose the product over a competitor.

Storytelling is how Clements carries that reasoning across an organization. Early in his career, he assumed data and a recommendation would be enough to persuade people. With study, observation, and practice, he learned to build a narrative that explains where a proposal comes from and where the team is going. For developing designers and product managers, his advice is to look beyond the immediate feature and connect individual decisions to a broader product direction.

Listen to the full conversation: Episode #87 audio.

Clements offers a practical sequence for scaling UX: gather user evidence regularly, make that evidence visible, show how proposed work fits a longer product journey, and maintain the shared system that turns vision into consistent delivery.