Forming an In-House Design Discipline
|
[SUMMARY]
Design at Sapphire (and post acquisition, Zelis) shifted and matured through the six years I was part of the company. I was responsible for doubling the size of the team, formalizing existing roles (product design), introducing new ones (user experience research and communication design), and deepening the integration between Product and Design.
The following case study covers the evolution of the team from 2018 to early 2024, with a focus on the emergence of Design Operations, intertwining with Product around insight analysis, and deepening our collaboration with engineering through partnership on an improved Design Language System and componentization framework.
As always, the success of anything and everything below was a result of the team and partnerships across the organization.
|
[ROLE]
Director of Design
Insights & Empowerment, BU
|
[COMPANY]
2x
team size (from 4 to 9)
37%
increase in project delivery speed with improved DLS
558
UXR participants in 2023
3
new role types established
SECTION 1
Tracing the Growth of the Design Discipline
// PARTS //
01: The Initial Shift
02: Firming Up the Foundations
[01]
THE INITIAL SHIFT
The company begins its move to an established, in-house design team, but we struggle to find our footing.
When I joined Sapphire in 2018, Design was undergoing a shift from being a hybrid of internal designers and agency support led primarily by Product, to an all in-house, design-led, still small, team of four. We were top-heavy: one design director, two managers, and a junior designer split across two separate product teams. I was one of the two design managers and although we had ownership of different products, our group centralized around a budding Design Operations model that was demonstrating immediate impact by bringing service design to the organization.
At the time, the design director had kicked off a total visual overhaul of the two core products, moving them into a new design language based on Material, since an engineering decision had been made to rearchitect the platform’s frontend with Angular. The redesign was a true revamp of the visual identity and the focus on heavy use of color, improved alignment, spacing, and overall polish, became a demarcation point in both product’s history.
The effort Design led to demonstrate value and impact my first year there centered around:
Upping craft and UI polish
Introducing in-house human centered design toolkits and design-led research
Leading workshops and design evangelism
Upping Craft and UI Polish
The most visible design-led change in 2018 was the shift to an entirely new UI and overarching design language system, that was implemented alongside the rearchitecting of the two core products. The changes were primarily interface and component related, with some small UX tweaks, but core feature functionality remained mostly unchanged. A large part of this was because our biggest product, the provider finder, was embedded in client (health plan) portals. Engineering had reached the decision to use Angular as the bedrock of their frontend-overhaul, so we rooted the visual shift in Google's Material Design, coupled with a configurable approach to colors/branding to make the product look more integrated into a client’s overall online experience. Improvements in boldness of color usage, composition, and clearer visual hierarchy, were accompanied by a new componentization of the frontend that would (in theory) allow for faster UI-iteration moving forward.
Improvements in craft extended beyond UI implementation, to everything the team touched: internal decks, personas, service journeys; everything increased in polish and ambition. The team created splash-images, “sizzle-mocks,” for client presentations and senior leadership, as a way of putting a stamp on what the new group was capable of and what “good” looks like.
Introducing In-House Human Centered Design Toolkits & Design-Led Research
I was fortunate in my early experience at Amex to work on a process-rigorous team. Now obviously it’s more important to adhere to principles over process, but there is benefit to having a clearly defined approach to design activities and models for definition and delivery of your work. Whether it’s the “double diamond,” any IDEO or frog diagram, or even IBM’s snake-eating-infinite loop, having something that your team can reference is a fundamental step for building a foundation that principles can rest on.
We picked the “4 D’s” (Discover, Define, Design, Deliver) as the overarching process phases, since it was simple for other teams to remember. To supplement and add depth, one of the early toolkits I created was essentially a diner menu of design and product activities that a team could leverage as they moved through the stages of their work.
Design-led research began in earnest during this time, with ethnographic and service design inspired work-streams prioritized to demonstrate the skills of the new team. In-field member interviews accompanied by discovery activities, focus groups, increases in usability testing and prototyping – every project became an opportunity to bring a fresh activity to the organization.
Leading Workshops and Design Evangelization
Workshops: is there anything a Design Team loves more for demonstrating impact to leadership than getting 20 people in a room covered in plotted paper and bright colored stickies? (Nope!). The workshops we ran were a fantastic opportunity to connect with other departments, deepen our own knowledge of the healthcare industry, and promote the expanding scope and abilities of the Design Team. We created service blueprints, charted member journeys for different procedure types, created personas and behavioral archetypes based on marketing, sales, and client success research and input.
To foster interaction and provide visibility, we plotted off these artifacts and tacked them up around the offices. We distilled them into slides that could slot into decks. We opened up our design crits into a reoccurring Wednesday session that all teams could join. We tried to be as open and inviting into our process as we could be.
We did all this in one year, but...Design didn’t move the needle in any significant way for member experience. Over the next few years, the products stagnated. Why?
THOUGHTS ON WHY DESIGN STRUGGLED TO INFLUENCE THE PRODUCT, DESPITE INCREASED UX MATURITY
[02]
FIRMING UP THE FOUNDATIONS
The team goes through structural changes; roles are clarified and added; tool improvement becomes part of ongoing capacity and pride.
Over the following years, the team grew in size, added new roles, and further intertwined with product and engineering. The design director left at the end of 2018 and for two years I co-led the team, before becoming the senior director in 2021. The term “senior” in that title is somewhat superfluous, especially since for a large portion of my time leading the team, I was the only direct people manager. So if it helps you to think of me as just a director, that works too!
The expansion of the team brought in incredibly talented individuals that were nascent in their careers or nearing senior levels (eg. previous experience at one or two companies). In order to provide clarity, direction, and some sense of stability, myself and the other co-director at the time, began to take organizational design more seriously. Peter Merholz and Kristin Skinner heavily influenced our approach and we developed the first iterations of:
Updated roles and definitions (switched to “product designer” from “UI/UX designer”)
Team skill stacks
Level expectations
Hiring practices and interview coaching
The majority of the team consisted of product designers, but as the years went on, we added:
User Experience Design
Communication Design (formerly “marketing graphic designer”)
Data Product Analyst (connected to the team with UXR as “CX Insights,” but people managed by the head of product)
Similarly, much more focus was given to our primary tools once we made the switch from Sketch/Zeplin/InVision to Figma. Our Design Language Systems for our two core products merged into one and the amount of research and continual iteration became pat of the team’s DNA (I talk more about the DLS later on in the “partnering with engineering” section).
SECTION 2
The Team Grows Closer with Product
// PARTS //
03: The Blend of Product and Design
[03]
THE BLEND OF PRODUCT AND DESIGN
Of all the teams, Product and Design share the greatest overlap, which rather than being fear inducing, was the source of greatest collaboration and eventually merged into a singular team identity.
What can be said of Product and Design that hasn’t been said by all the two disciplines thought leaders? “Three legs of the stool,” “Product” as an all encompassing word for product managers, product designers, and lead engineers – it’s one of those concepts that everyone can nod their head to, but can be much harder to actually implement. I was fortunate to work somewhere with such a receptive product leadership. Over the years, the collaboration and to a large extent, identity, of the two teams became one. In fact, I started referring to “Product” as a singular term when referencing “Design,” since Product had more respect and buy-in for decision making than what the rest of the organization up until then had referred to as “the UX Team.”
We tried our hand at several working team compositions, often trying to staple Engineering on to what seemed to come so naturally to PMs and PDs.
Finding Something to Center Around
What really enabled product managers and product designers to blend into singular “duos” (ha! I feel like that’s almost an oxymoron: singular duos), was the centering of the team around insights for one micro-journey (read the case studies on the MX Index to learn more on these). This wasn’t overnight – we built paths into insight generation over many quarters, but eventually had data, staff, and tools to more readily:
talk to customers (health plans)
talk to users (members)
glean industry knowledge
probe new technology
analyze product data
SECTION 3
The Team Grows Closer with Engineering
// PARTS //
04: The DLS as Glue for Design & Engineering
[04]
THE DLS AS GLUE FOR DESIGN & ENGINEERING
Getting serious about design language systems, componentization, and improving the way we deliver our interface at scale.
The sheer size of Engineering in comparison to Design made the overall relationship more dispersed, individual-specific, than with Product. Product designers and engineers became close over the years, but it tended to be as a result of project-based time together. What helped shift this, was when we made the decision to get serious about our Design Language System.
If innovation “absolutely depends on empowered engineers [link],” (Cagan, 67) yet we existed within a strict B2B2B2C environment [link], the DLS and shift to a monorepo allowed the creators of the UI to actually have a say in research, decision making, testing, and governance.
When I first joined the company, the DLS was a set of symbols in each Sketch file that got duplicated with each new project. We had two separate languages (both based on Material) for our two core products, that shared a similar stylistic approach, but were in two separate code repositories. What enabled us to move to treating the DLS as product were three things:
The growth of the design team and having enough product designers to dedicate time to research and continual improvement
Senior leadership support for improved componentization to enable a scalable approach to personalized product experiences for members
Engineering work to move both core products into a monorepo (made a singular, shared component repository easier)
In all honesty, it probably took about a year for the teams to reach critical momentum, by which I mean we had our Figma files transitioned to the new component library, the monorepo up and running, and governance integrated in it’s first few iterations into existing product delivery processes. Since our largest product, S365, was integrated into client environments (and thus, client release schedules) and contained hundreds of configurations, we took the approach of updating components through two routes: all new features and functionality would contain the new components and we would work to replace old components by a “bottom-up” approach (styles first, then atoms [eg. buttons, form fields, etc]), then molecules, and on and on). Because being pretentious is mandatory for mid-level leadership, this method become known internally as the “Ship of Theseus” approach:
Working on the DLS was also one of the few times that Engineering and Design, the two craft disciplines, got to truly be in control of their output. Hashing out questions of governance models and meeting cadences, but also immersing in each other’s research for decision making.
[05]
WHERE’S DESIGN GOING FROM HERE?
It’s early summer 2024 as I write this and the Design community continues to simmer in a stew of existential dread and aimlessness. At least that’s the surface conversation on any feed I skim across. I feel some of it too: shrinking teams with the same expected output (which isn’t always a bad thing), continued integration into Product to demonstrate business value (which is necessary, but ends up flattening the joy out of a lot of the craft), a sinking tiredness from having to demonstrate design’s value at the umpteenth enterprise or legacy company (which often prove that a bad product doesn’t mean you have an unsuccessful company and vice-versa). Despite all this, I find it hard not to be excited at what I see evolving in Design. I should obviously state here that my view is narrowed to my own experience and I can’t speak about the industry as a whole, such as trends for design agencies or bleeding edge B2C companies. BUT...as things like UI continually became “solved problems” these were the things the team engaged in and filled our time:
Further integration with Product, with an especially prominent focus on connecting work to metrics that ladder up to business value.
Service Design and user experience research serving as foundational elements for insight formulation and perspectives, which feed and generate strategy.
Design as Editors
Further integration with Product, with an especially prominent focus on connecting work to metrics that ladder up to business value.
Pretty obvious objective, but it was incredibly hard for us to get meaningful metrics integrated into our workflows. It was like trying to chisel human facial features into a block of granite other people had started carving a horse onto, as it swung back and forth on dolly straps. I’m not a sculptor, nor have I ever held a chisel, but the point is that existing structures in the organization had to be worked *into* as opposed to built fresh. Centering product designers and product managers around individual micro-journies, or tasks a member were trying to complete, welded Design and Product closer together and gave the teams clear CX metrics that, in theory, laddered up to business value.
Service Design and user experience research serving as foundational elements for insight formulation and perspectives, which feed and generate strategy.
In college I majored in history before “discovering” that design was a viable career path and convincing my parents that a fifth year for two degrees is basically a bargain. The most valuable thing I learned from the history-discipline was the idea of the research-trail; of immersing in primary and secondary resources and pulling out something insightful to say to support your thesis. Translating this into our design-world, the concept of “perspective documents” became a way for team members to have structure around things as specific as system-color selection to nebulous concepts like member expectations around cost transparency in healthcare. The budding CX-Insights team allowed us to generate significantly more “primary” documentation, which worked it’s way into not just external documentation, but writings the teams could use to crystalize their views on foundational elements of their work. It’s a cliche, but it’s true: you need to write so you know what you actually think.
But what’s the point of perspectives and service design artifacts if they’re not to feed into something bigger?! How do those activities ultimately evolve the discipline of design? Well..I *think* they can ultimately shape strategy, but that gets into a much fuzzier territory. Saying something “impacts or shapes” strategy is generally just one of those seemingly correct non-statements that you can nod your head along to without questioning how it’s really done. Rich Rumelt completely reshaped my view on what strategy is. If strategy is problem-solving, the tendency to focus design’s aim on uncovering user-centric obstacles won’t really move the needle on design’s evolution without then connecting those pain points to business obstacles. Translating those issues into an action plan (aka getting the updates into the product).
But strategy is also making choices, so in order for design to evolve as a discipline, it needs to get more comfortable making decisions in the face of uncertainty. Perspectives based on insights that come from better access to data and synthesized with service design techniques, *can* be a way to get there. I don’t think I’ve done it well, nor really at all intentionally, but this feels right.
Design as Editors
Adam Moss, in his promotion for The Work of Art, was on Ezra Klein’s podcast and said the following:
ADAM MOSS: I think any editing is just a heightened level of sensitivity to reaction. I think you’re just being super sensitive to the way in which your mind is reacting or your heart is reacting. And it’s not just an intellectual thing — it’s also very much an emotional thing. Bob Gottlieb in that Caro documentary described editing as reacting. And that is a pretty good definition, I think.
ADAM MOSS: Yeah, it’s trusting the reaction. And then there’s another part, which is kind of separate, which is figuring out what to do about it. I would write all over manuscripts, and sometimes I would have solutions, but often, it would just be a reaction. I spent a lot of time praising the stuff that I thought was good and kind of withholding when I didn’t think it was good.
Gen-AI, at least what we’ve seen so far, is so incredibly disaggregated in terms of its output. Even if Figma didn’t pull their tool that auto-generates entire UI layouts for you, you can still see where things are headed. Our team at Zelis built the entire DLS on Material, which was essentially something a bunch of super designers at Google built and maintain. BUT, the role of the product designers on our team became more about being good editors...of knowing how to use it as the foundational starting point for analyzing it’s success against a given problem. It made them spend less time in the UI manipulation of single components and instead, became easier to try out several variations and do the more difficult task of coming up with a perspective on what to move forward with based on data analysis, testing, and assessment of the business’ goals.