Embedding Product Design in a Large Agile Organization

athenahealth provides network-enabled services for healthcare and point-of-care mobile apps to drive clinical and financial results for its hospital and ambulatory clients — we employ 85+ designers globally to support those efforts

The Agile approach can be tough for designers — if misinterpreted it creates the expectation that a solo designer assigned to a scrum team will constantly and magically generate just-in-time designs. That a great cohesive overall product experience will be envisioned and unfolded piece by tiny piece across multiple scrum teams. On the other hand, if strategically focused on both discovery and delivery, Agile represents a great opportunity to center product development around frequent user feedback, and to constantly iterate by treating every release as a prototype that demands learning and improvement.

Starting in 2016, athenahealth made a broad organizational commitment to Agile as a product development approach and organizing principle. As a design group we decided to seize this change as an opportunity to improve user- and design-centricity in the product development process, so we focused on reorganizing our 85+ strong design team to take advantage of the transformation. We found the book Org Design for Design Org’s by Kristin Skinner and Peter Merholz invaluable as we made our plans.

Staff scrum teams judiciously

Previously we had groups of designers assigned to products who worked in ad-hoc teams to generate designs in response to numerous business priorities. For individual product designers the move to Agile meant aligning to scrum teams as their primary responsibility. With more than 200 scrum teams in the company and less than 100 designers we could never staff every team (and nor should we aim to as some scrum scope simply doesn’t need it). We also rapidly confirmed through experience that being a core member of two scrum teams is difficult for anyone, including designers — Agile ceremonies are an important, but time-consuming endeavor, and the desired tight collaboration is tough to maintain with multiple teams. Spreading our teams thin — we say “peanut buttering” — results in exhausted designers and low quality work. A better approach is to identify where UX matters most, and ensure you do a great job in those parts of the product.

We therefore rapidly settled on a model where:

• Scrum teams working on end-user interfaces include a designer (we refer to these designers as “scrum designers”);
• Most scrum designers are dedicated to one team only (in cases where the work of two teams is very related and lighter in design load, they might span two); and
• Scrum teams without an assigned scrum designer get UX design support as needed from a senior designer who oversees a broader scope of work.

This does entail making some tough decisions about which teams do not receive a scrum designer. We made some product managers unhappy, and we still have cases where either an unstaffed team needs more support than it’s getting, or a design-staffed scrum is moving too slowly to keep their designer truly productive. Importantly however, it’s made design resourcing much clearer and explicit. The value of having a designer work on your product scope (or not) is much more apparent to product owners who’ve been forced to go without.

Some of the messiness and slack in this system is managed by our design leaders. Aligning with how Product Management and Engineering were organizing, we grouped scrum designers into “zones” of which there are several in each Product Area. Each zone is then overseen by a Design Zone Lead, who reports in into a Design Manager for their Product. The Design Zone Leads guide and support the scrum designers and also works with the unstaffed scrum teams that need partial design support.

To read more about the leadership and career path structure we established for design read this article.

Ask T-shaped designers to represent design on product teams

The sub-disciplines of product design are wide and deep, and we’ve long embraced the “T-shape” model for design talent. The T-shape model acknowledges that a designer may have broad exposure across multiple sub-disciplines like user research, UX, UI, visual design, copy writing, and front-end coding, but may only be strong at one or two of them. Designers are not jack-of-all-trades and we have explicitly called that out to ensure this is not the expectation of product teams. Rather, scrum designers are considered a representative of design, not a sole resource.

A summary of the sub-disciplines of design we use internally

Our intent is that the UX designer assigned to a scrum team is accountable for ensuring quality design input, guidance, and review for their scrum team. While building a great user experience is the responsibility of every R&D team member, the scrum designer is expected to be the key advocate for the needs of the user and the application of design methodologies to discover and solve for them efficiently. They participate in all of the ceremonies with their team and lead the planning for the relevant design work. This does not mean however that they complete all design work for their scrum, in many cases they may be the conduit rather than the “do-er”. Example: a scrum designer from a heavy research background partners with another from a deep visual design background and, working together as a pair, they complete the design activities for both their respective teams.

Scrum designers representing design within their multi-disciplinary scrum, and working with each other across scrums to get all the design work done.

This is a simple principle but an important mental model to get right. It impacts expectations of a scrum designer from all disciplines. Continuing the example provided above, it may mean that a research-background scrum designer in a sprint review is less able to articulate exactly why a detailed UI page mock is designed a certain way until they consult their design partners. For any given scrum designer there are three possible places to look for this partnership: other scrum designers, design leaders, or our DesignOps team…

Support product designers with internal systems and tools

As we established the scrum design role we recognized that:
1) We were asking scrum designers to do a lot as described above, and
2) we had a bunch of great specialists in our organization that weren’t UI-capable product designers — we had researchers, strategic designers, content specialists and even some UX engineers.

To leverage those skills and to support our scrum designers we established a centralized DesignOps team. Over the last 18 months this team has built out several internal systems that help designers and their peers in R&D to efficiently build the right thing, and build it right, including:

1. The Research Council — a panel of users who’ve volunteered to be contacted for design feedback, spanning the 23+ different specific professional user roles we serve across healthcare. Every two weeks, or more frequently if needed, scrum designers can send a prototype out to gather feedback.
2. The Experience Definition and Measurement Frameworks — a suite of ready-made discussion guides, concept testing surveys and data collation tools that help scrum designers conduct rigorous user research and UI audits with a minimum of preparatory effort, and to analyze the data that comes back.
3. The Forge Design System — a library of thoughtfully designed and coded UI components that make it quicker and easier for designers AND developers on scrum teams to build intuitive, consistent front-end experiences across athenaNet.

Could scrum designers function without this centralized DesignOps team? Yes. Would they do their best work? No!

The work of this team alleviates the burden of design process and planning, allowing Scrum Designers to focus more deeply on the problems and solutions they’re trying to find. We’ve also found, as we hoped, that the data generated by the centralized system of tools is of great value to product managers and developers, raising the profile and credibility of design as a discipline internally.

For much more detail on our DesignOps team and their work read this article by my colleague Jen Cardello.

Leading indicators and looking forward

We feel as if we’re making progress — some teams are generating much higher quality experiences, uptake of tools and resources is slowly increasing and while designers still face challenges we have strongers resources, answers and advice to offer each other. We’re still very much experimenting and learning — we’ve soaked up every best practice we can, but each organization has a unique genome and our company certainly has it’s own pathologies to be addressed.

Much of our learning is qualitative but we’ve also tried to track quantitative OKR’s. A few of things we’re tracking to gauge our progress:

• Adoption of DesignOps tools — How many of our released experiences employed the research tools or Forge design system?
• Design quality — What is the average design heuristic score of new workflows being released? (an article going deep on this is in-preparation)
• User perception of quality and satisfaction — Are individual roles we’ve released new experiences for trending upwards? What about the user base as a whole?
• Staff engagement — Do designers feel like they are supported in doing great work?

It’s early days but we look forward to sharing our progress and additional learnings in future articles. Please let us know if you’ve encountered similar challenges in your organization — we’d love to talk to people who are figuring this out just like we are.

—

We have a variety of design roles open in Boston, Austin, Bengaluru, Chennai and Pune. If you’re interested in working with us try here and here or get in touch via LinkedIn, Twitter etc.