I am Aaron Martin. I create web experiences, mobile products, custom typography, and branding experiences. I provide creative direction by way of design, strategy, and art direction.
Operational Excellence is all about building an environment where your design function is resilient, efficient, and ready to deliver high-impact work consistently. Your job is to create systems and processes that empower your team to thrive, adapt, and improve over time. This chapter walks you through how to scale design processes, allocate resources effectively, maintain a high bar for quality, and use metrics to drive meaningful outcomes.
Scaling design processes starts with striking a balance between flexibility and structure. When your team is small, detailed, step-by-step processes might feel unnecessary. But as it grows, a structured yet adaptable approach keeps chaos at bay. Rather than enforcing rigid rules, you can rely on standards & defaults—guidelines and templates that give your designers a clear starting point, no matter their experience level.
For junior designers, these standards provide a roadmap to learn the craft and meet expectations. For senior designers, they offer a reliable foundation when time is short or challenges are new. The trick is to keep them flexible, leaving space for creativity while ensuring consistency across the team.
To keep these processes relevant, revisit and refine them regularly. Quarterly reviews, with input from your team, let you adapt based on real feedback—whether it’s new tools, shifting challenges, or changing team dynamics. This keeps your approach fresh and practical.
One way to make these standards stick is by appointing "process champions" or "lead designers" who model best practices and help onboard others. This builds ownership within your team and sparks improvements from those closest to the work.
A great example of a default procedure at Ridgeline is our Effort Matrix. We noticed that we tended to spend too much time on things that in retrospect weren’t features that made big impacts on our users’ workflows. So we defined a way for us to more appropriately gage how much effort we should put into each project.
It’s a fairly simple 2x2 grid, with one axis being the frequency or criticality of the user task, and the other being the complexity of that task being done by the user. Each of the 4 quadrants aligns to a general list of defaults we expect the designer to run through for that specific project. It has allowed us to quickly get everyone up to speed in reviews and sign offs as everyone is now aligned with what level of work and effort is expected for each type of project. Given the product we’re making at Ridgeline, these axes make sense. It may not work for everyone. The effort matrix comes up in almost every single retro as a thing we should continue to practice, and that’s what you want to see happen with those things you’re instilling in your team’s culture.
A strong design team does more than create great products—it shapes your organization. As Conway’s Law points out, your team’s structure influences your product’s structure. In large, distributed products, design can act as the glue holding everything together.
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
One way to make this happen is through what I’ve called the breathing method. Here’s how it works:
The Inhale Behaviors are those things you do together as a function: design reviews, weekly kick-offs, brown bags, co-design sessions, etc. The Exhale Behaviors are the pieces of work done by designers on their product areas with their stakeholders and collaborators: use case writing with PMs, sprint kick-offs, scums, design hand-off with engineering, etc.
This rhythm boosts communication across your organization. During the “inhale,” your designers sync up on vision and standards; during the “exhale,” they carry that alignment into their cross-functional teams. Over time, this builds a more cohesive product and a tighter organization.
Your team’s processes are like a product—they need regular iteration. Just as you’d refine a product, you should gather feedback, spot pain points, and make adjustments. Regular retrospectives are a great way to do this.
Try this simple framework:
Give your team time to reflect, then discuss and group the responses to spot trends. This highlights areas to improve and keeps your processes aligned with reality. You can even apply this to team meetings to ensure everyone’s time is well spent.
As a design leader, resource allocation is one of your most powerful tools. It’s not just about putting the right people on the right projects—it’s about managing energy, avoiding burnout, and aligning work with your strategic goals.
Begin by setting a clear project priority framework. Pinpoint which projects tie directly to your vision and which can take a backseat. This clarity lets you assign resources smartly, keeping your team focused on high-impact work.
Transparency matters here. A central dashboard can track team capacity in real-time, but it’s only effective if you communicate clearly about how work is assigned. Regular check-ins with cross-functional leaders keep you in sync with shifting priorities and ensure your team’s efforts support broader goals.
That said, watch out for micromanaging. Resource allocation should empower your designers to own their work, not bog them down with oversight. Set outcome-based goals—like “improve onboarding completion rates”—and trust your team to deliver.
Building a high bar for quality requires an environment where continuous feedback is ingrained in the culture. Design reviews are a classic way to foster this, but they work best when tailored to the needs and skill levels of the team. One approach is to categorize critiques based on the stage of design—early sketches vs. final deliverables need very different feedback structures. Early in a project, focus critiques on alignment with strategy and customer needs; later, hone in on visual and interaction details.
A “quality checklist” that designers go through before presenting work maintain the necessary structure for each unique piece of work. This doesn’t need to be overly formal but should include key questions to self-evaluate the work against standards of usability, accessibility, and alignment with the product vision. And beyond formal reviews, encouraging an open feedback loop where designers feel safe seeking feedback outside of scheduled critiques.
Design quality is the degree to which a product meets the needs, preferences, and expectations of its intended users while also meeting functional and aesthetic requirements. It encompasses the overall user experience, including usability, reliability, and durability, as well as the product's aesthetic and visual appeal. It is an important factor in determining a product's success in the marketplace, as it influences user satisfaction, loyalty, and brand recognition. We, as the design team, must strive to achieve the highest possible quality via a thorough understanding of user needs, effective problem-solving, and attention to detail in all aspects of the design process.
So how do we determine if what we’re creating, from a design, functionality, and build perspective, is up to the bar we’re aiming for? And before that, how do we even define our bar? And once we have that bar define, how do we share it in a way that’s manageable and actionable?
There will never be a completely defined ruler we can apply to every situation, but by having a framework of questions in place will allow us to answer (with a somewhat binary yes or no) how we can grade our work, and push for a great experience. Those questions fall into four categories:
Targeting these four areas with specificity allows you to implement a quality pyramid in a way that’s measured and proactive.
Everything we create must first align with our goals as a business. As a company, we have made several promises to our design partners and users. We aim to deliver high-performing software that is always available, reliable, secure, and scalable. We create software that users can trust, and we design it in a way that our engineering and PM stakeholders can build in a profitable way, i.e. doable and on-time given the time constraints we will always have present. Our ideas must be cost-effective to produce, and should provide a competitive advantage in the market by addressing user needs and preferences.
How can we actionably define this? By asking several questions around the resiliency of our ideas:
Ridgeline is replacing systems already in place at the firms we’re signing, so there are defined needs that we’re actively addressing. We need to fully understand those features, needs, and processes to adequately upgrade the experiences for our users. Our designs should provide an intuitive and satisfying user experience that meets the user's functional requirements.
By maintaining this user-centric view, we’re living out a company value. By delivering what firms expect functionally, we’re showing our relevance in a clear and immediate way. Combine this functional equivalency combined with a single system of record, and we’re providing a unique and valuable offering.
On top of meeting existing needs, our job here is to push on the assumptions of our users, to deliver on the promise of solving their problem in a better way, and not just blindly accepting existing solutions as a gold standard. True partnership with a user means a willingness and desire to push them to a love of the problem, and not a love of the solution.
How can we actionably define this? By asking several questions around the value of our ideas:
The experience of a user in our system is probably the most closely-tied aspect of the work at Ridgeline to the quality of our product. How a product is used, how a user performs tasks, how they move through the system, how they build an understanding of the structure and information architecture, all of this builds a perception of quality.
The product must be easy to use, understandable, and should provide a positive emotional response to the user. And that emotion is trust. The design and user experience of an application are the canary in the “did this company invest time, effort, and research in solving my user needs” coal mine. If a user sees an untrustworthy experience, how can they have faith that the “harder” problems of resiliency and value? Trust comes through our purposeful effort and targeting of consistent, streamlined, and cohesive features.
How can we actionably define this? By asking several questions around the usability of our ideas:
The visual design of a product plays an important role in the success of Ridgeline, both for the individual users and for the competitive moat we are building. We must consider aesthetic aspects such as branding, visual appeal, and form factor. Everything we create should be visually appealing and consistent with the brand promise of Ridgeline. Well-crafted ideas convey a sense of purpose and thoughtfulness. They tend to be more natural and delightful. They adapt to changing needs and features of the part, while maintaining the cohesion of the whole. Our users are used to experiences that sacrifice the experience at the altar of functional completion.
We can do both.
Our users are real people and are delivered refined experiences in the majority of products they use outside of their 10 hours a day in Ridgeline, so why should there be a lower expectation for the software they are using and paying for?
How can we actionably define this? By asking several questions around the lovability of your ideas:
Having a bar is nothing without:
As designers, we will never be free of the struggle of educating others on what good design is. The concept of subjectivity in combination with explicit functionally-complete needs by our users is a difficult balance. Much in the same way we learned our craft, we can be the teachers through conversations with our stakeholders.
Questions as a form of measurement are an easy way to communicate to teams that an experience isn’t up to the quality bar that we’re trying to maintain. Having a set of questions we can ask ourselves and our stakeholders will help us educate stakeholders on the assumptions we’re making and what we’re delivering, and over time the answers that we deliver as designers will educate others to what a positive and negative answer looks like. In aggregate, they will soon have an understanding (and hopefully, practice) to what good design actually is.
We will meet the needs, preferences, and expectations of our users, while also meeting functional and aesthetic requirements of our design practice. Only dedication to a single vision of what quality means for us as a company will allow us to maintain our standards. We ask for consistency and cohesion in our product, we now expect the same for ourselves in how we shephard the experience.
Over time you will have created living, in-app examples of what quality looks like. These experiences can be used to show influence, as well as become proof-points for those areas of your product that customers gravitate towards as validation of the success of your influence.
Users care about the entirety of their experience, but it’s your job as a leader to make sure your team finds was that your users feel heard. Just ask yourself and your team these questions. While some of these won’t be negotiable, some will be, and you need to make sure that the user’s voice is a part of the conversation.