How DesignOps improves design to dev productivity at T. Rowe Price
User Stories
Linda Le Phan
Dec 2023@lindalephan
What would it mean to your organization if your designers and developers had an additional 25% or more availability every week? And what if they could use that time to focus on their craft and to work on valuable design and development work vs. other distractions?
That’s one example goal outcome for a DesignOps function. There are also other DesignOps focus areas — like increasing employee satisfaction and resource planning — but ultimately, it's hard to find more value than to radically increase designer and developer productivity so they can build more beautiful products together for your users.
That’s certainly what Mark Figueiredo, Senior DesignOps Manager at T. Rowe Price, feels strongly about. He also believes in using Zeplin for providing the clarity and structure his entire team needs, but is typically missing from Figma alone.
He generously shared his experience and expertise with us in a recent webinar — check out the full session:
Here are some highlights of what Mark covered:
1. The journey from UX designer to Senior DesignOps Manager
Mark started his career and UX design, and like many DesignOps leaders today, he worked his way into a DesignOps lead role through a mix of determination, inspiration, luck, and passion for what the field stands for — improving outcomes and success for designers by building efficiency, trust, and healthy collaboration between teams.
2. What DesignOps is and what it looks like at T. Rowe Price
Mark emphasizes that DesignOps looks different at every organization — every team has their own “DesignOps catalyst” — and walks through his favorite DesignOps maturity framework. He also shares how he pushed for DesignOps at T. Rowe Price and it's become key to the structure and consistency they have in their design processes and cross-team collaboration.
3. Design-to-development inefficiencies he and his team solved
In his experience doing the usual DesignOps work of organizing meetings, enhancing communication, and facilitating collaboration between designers and devs, Mark has tackled a few major design-to-dev inefficiencies. The biggest ones he's observed relate to organization, tracking version changes, and keeping design documentation structured and in context.
4. The central role Zeplin plays in his team’s workflows
Mark is an avid believer of using Zeplin — rather than having everyone in Figma — to solve all of these blockers, with features like Flows, Annotations, version control, and built-in structure and organization.
Zeplin ensures his developers understand the intent and direction of the constant influx of design work, while also preventing unnecessary back-and-forth and rework across the entire team.
By using Zeplin as a separate space for our finalized designs, we were able to avoid the confusion that was happening when we had everything in the same [Figma] design files before. It really gives our devs everything they need in a very organized and systematic way.
Mark Figueiredo,Senior DesignOps Manager at T. Rowe Price
5. His take on DesignOps tooling and workflows
Every designer’s workflow is different and designers should design – not manage tools. Mark believes evaluating and implementing the right tools for the design-to-development workflow means taking this into account. It also requires continuously gathering feedback from both designers and developers on what they need so they can focus more on what they do best.
Even though there are multiple ways to mark things ready for dev in Figma...having Zeplin was really central to us for design-to-dev collaboration, and just making that whole process less error prone, less time consuming across our entire product team.
Mark Figueiredo,Senior DesignOps Manager at T. Rowe Price
Want to know more about why Mark sees Zeplin as a central part of his DesignOps practice, and prefers Zeplin over Figma as the source of truth for his designers, devs, and product team? See the full transcript below.
And if you want to try Zeplin for yourself, contact us to learn more or join an upcoming Zeplin Group Demo. ⚡
Transcript:
I’m kind of blown away that I get to talk about something that has become a major passion of mine. I didn't start out this way — my experience has been all kinds of interesting over the years. I actually made the full-time move into design operations in a full-time role about two years ago. Before that, I was a design lead here at T Rowe Price for about five years. And before that, I was UX designer as an individual contributor at various companies. So, my path into design operations wasn't through a program management channel but much more through the UX design space.
But during my time in design leadership, I was already executing on a number of design operations ideas and methodologies, and through that I came to learn more about design operations as a field and what I found is that this truly is my passion and it was a major reason that I decided to go ahead and pursue this as a full-time role. How often do we get to literally work in our passion?
So a few personal things about me, because I always like to over share, I am a avid bullet journaler, as Nico, shared I love analog planning and productivity and that’s been super helpful for me over the years. I love a good fountain pen, it kind of comes with the territory, and I recently took up disc golfing which I found is actually super fun. You get to be competitive and be outside and go hiking — you can't really say anything bad about that at all.
I’ll do a real quick overview of my organization and my group specifically. So for almost about 90 years now T Rowe Price has been helping people close the gap between what they have and then what they'll need so that they can live confidently. A lot of times that's in retirement. I specifically work with the Retirement Plan Services business — I’m going to call it RPS throughout this presentation because it's much easier to say — where my team builds the experiences for our employee sponsored retirement programs.
T Rowe Price has about 7 000 Global employees, and there are 52 countries in which we're serving our clients and our shareholders. We have over a hundred designers as a part of our design community at T Rowe Price and I work with amazing team of 13 product design team members, that's including myself as well as cross-functional teams with product managers, our dev teams, researchers, our marketers, and a whole bunch of other people too which I'll introduce you to in our org chart design.
Transitioning into DesignOps
Design operations didn't actually exist here at T Rowe Price when I joined and I think a lot of people come across that in their different businesses as well. But there were several clear signs and symptoms that catalyzed the need for design operations.
Something that I like to do anytime I meet anyone new in design operations is I like to ask them what was your Design Ops catalyst? So if you want you can drop this in the chat, what was it that got you into design operations or interested in design operations? For me, mine was actually coming to T Rowe Price in 2015.
The UX team that I was joining was relatively new and there was a lot of opportunity.When I joined there was poor to no onboarding process. I found out a lot about stuff just on my own just from asking a lot of questions, and there were multiple processes that weren't in place for how work was getting done. There was no capacity management at the time — everything was “yes” work and just kind of flowed in. There was no conversation about really planning for work, and work was extremely siloed. I used to half jokingly say well this team is kind of like being on like an individualized sport.
There wasn't a whole lot of team activity going on early on, and there was also no centralized design tools for UX. Everybody was using what they liked. In my first year, I looked at the opportunity and I decided to work with some of my like-minded team members to begin documenting and establishing our ux design process. It was something that was never truly written. It was kind of there, but we brought everything together so that we could share that and also follow along with it ourselves.
We established file organization for our ux team. It seems so simple, but when that doesn't exist or it's not working effectively it's something that you can and should spend time on. We also researched and procured UX Pin for prototyping at the time. That was a fun project like a research project we got to do, that was when I got to bring on my very first tool which was a learning process. And then also, I began doing some light capacity tracking for our UX team early on with that. So as I started doing this work early on, I didn't know that it actually had a name.
In 2017, I came across probably the most influential article I've ever read, it’s medium and it's by one of my favorite guys, Dave Malouf. I call him the grandfather of Design Ops — he probably wouldn't like that — but he was the person who taught me so much about this and he had this article it was called “What is design operations and why should you care?” and I attribute a lot of my design Ops knowledge to Dave and his writing on this topic. This article was a game changer for me professionally and personally as well, and honestly this is what started me on my path to full-time Design Ops career.
Then in November of 2017, I attended the design Ops Summit. This is a summit that currently exists and is actually happening next week and I'm sad I'm not going to be able to go. But this is a summit that is dedicated to design operations community and it was here that I met my tribe. I met these like-minded people at different size companies, I was meeting people from Google and Pinterest and Sendesk and they were talking about these giant design organization that they had. And then I was also meeting people like myself who were just learning about what design operations was and how it had impact on their
companies and their teams and what they were doing. I came back from that conference with so much energy it was kind of ridiculous and anyone that worked with me at the time knew it I was literally posting up sketch notes from the talks on every wall that I could find. I was talking about it non-stop I just knew that like this was it for me, like this is where I wanted to go, this is what I wanted to do and I wanted to make it happen at T Rowe Price.
It doesn't necessarily always happen that way and something that I kind of found by accident while I was doing this is that I'm the thumbnail of that summit’s video — a very unflattering thumbnail of me from that summit that I found on YouTube. But it really was just amazing o be a part of that community.
I then went to my second Ops conference and this is where I started to really double down on design operations. I started infusing in everything that I was doing even though there was not a full-time role and no one else was really talking about it at the time. I found some like-minded people at work which really helped out, but it took four years for me from this standpoint of learning what design operations even was and then coming to a point now where I was actually able to finally secure a full-time role at T Rowe Price in this RPS organization with an absolutely amazing team and an incredible design leader who recognized the need for it on her team and who honestly has been just a true champion both for myself and design operation. I've been truly lucky with a number of leaders that I've worked with over the years
What does DesignOps do?
At the highest level, if you're unfamiliar with design operations, design operations is working on building strong and impactful design teams by organizing and orchestrating people, processing, and tools. This is the definition you hear Meredith Black, who's highly involved in Design Ops and started up The Design Ops Assembly. She recently said: Design Ops is everything but design, and she couldn't be more true.
It has so many pockets to it. As Design Ops started to develop into an official function at T Rowe Price, I worked with other people in our design community to define our goals and our operation principles on how we wanted this to look. We knew that we wanted to focus on four main things going into this:
The first is just auditing your resources. It’s scoping out your projects and making sure that your projects are staffed and resourced appropriately. We know that we needed to work on improving our workflow efficiency, how are we measuring things, how can we improve efficiency, how can we save time, and what we're doing to allow our designers and our content strategists and our other team members to do truly what they are here to do.
We also focus on process and collaboration — that's a sticking point for so many different businesses and companies. Our goal is to build strong cross-functional relationships. We want to be able to talk about our process and our product, and we want to also be able to share that across the board with our engineering teams and our marketing teams and anyone who we work with.
The other part is implementing the right tool stack. I think for every business you never stop worrying about tools, but we want to make sure that we're evaluating the right tools for our teams, we're onboarding them appropriately, we're making them available, and then managing those to make sure that our design teams can get done what they're here to do — [design].
So as I mentioned, it's important to acknowledge every company has a different approach to design operations and there are many versions of different op models that exist out there.
This opportunity model is one of my favorites, it’s by Rachel Posner and John Calhoun. The main idea here is that every team needs different things at different times. The key path to follow is the progression happens as your design teams grow.
So for example, with a smaller design team, you might only need one Design Ops team member on your team. That's how our team is right now: I'm a design team of one. Dave Malouf actually used to share the magic number for him and it may have changed over time, it used to be that after you have nine design team members that's the right time to start implementing and having someone in design operations join your team. And as your team grows, you might add an additional person to help focus on certain programming or communication areas.
But you have to go through different phases. As your team is growing and expanding to each of these thresholds, you get to a point where you go from a family of you know 1 to 30, which is still a big family, to an organization of over 200. You come across different challenges and Design Ops can help focus in those areas for growing at scale.
So in my time at design operations, I've learned that teams will need to lean into different aspects of design operations depending on maturity level. For me here at T Rowe Price, that focus has been primarily in meetings in communication, program management, and tooling.
For meetings and communication, this has to do with promoting healthy collaboration between everyone involved in design and products. So this means focusing on your design team, your developers, your program managers — it's really everyone. And as a design operator, this can come in a multitude of different forms: you could be the meeting organizer, you might be the facilitator, and in many cases design Ops are also the hype people. We're getting you excited to be in these meetings, we want to make it fun, we want to do good work.
So as an example, I run my Monday team meetings and I'm facilitating that meeting. I'm bringing the icebreakers and the meeting starters, and we're focusing on tracking capacity, we're talking about the work that we're doing — that way everyone's on the same page as we kick off our week.
When it comes to program management, this is really for forecasting your work. This is helping to define what it is, it's supporting your systems and your processes that you put in place to make sure that your teams can work more efficiently. For my team, that means involvement with things like integrated planning, discovery and research work, as well as cross squad organization and prioritization.
And then there's also tooling. I love this area, I know not everyone necessarily does, but I love finding new tools that are helping our teams do better work. For us here at T Rowe price, this focus on tooling been really important to help the day-to-day operation experience for our teams and elevate the designers and the work that they're doing.
A focus on tooling can take the form of being the tool administrator and being the one getting people in there and orchestrating and auditing and doing all those things that need to be done. That could also be training. I could be working with procurement to bring it in legal and all the other people that are part of that process. So it really takes on multiple levels and your team structure and your maturity is really what's going to help you determine where you and your organization might need to focus when it comes to tooling.
So overall, with design Ops, If you're a smaller team you might actually just be focused on just putting simple processes into place. You're not necessarily trying to take on this mountain right out of the door, right? Once your team starts to grow and scale, you start working with more cross-functional teams and collaborating.
When the number of meetings you have starts to overtake your day-to-day and you see those silos starting to form — it's at that point that you need to then take a step back and start to reconsider where you need to focus and what's most important. That's certainly what happened in our experience, so I'm going to move on to more about design ops at T Rowe Price.
DesignOps at T Rowe Price
As you can imagine, and as I showed, T. Rowe Price is not a small company by any means, with 7,000 people across the globe working together. The organizational structure, even within Retirement Plan Services (RPS), is quite complex. To elaborate on the people I work with daily, I collaborate with 12 product design team members—13, including myself. This group includes our design capability lead, the remarkable person I previously mentioned, who granted me my full-time role. We have two design leads, a Content design lead, and I serve as the design operations lead. Additionally, we have one dedicated researcher for UX designers and three content strategists. We collaborate with 13 different B2C product teams, seven B2B product teams, two product marketing teams, and a sales team we also support. That amounts to over 20 teams we can be working with at any given time throughout the year.
As we expand, things start to pop up where there’s potential for more siloization of teams. This leads to less visibility and you start to develop more and more distance between your design and your development teams. This is something that our team had struggled with early on and an area that we've decided that we want to focus on and keep in check.
I believe our team has done a fantastic job in honing in on this area, but you know this is something we see all the time. These problems with cross collaborative teams — and particularly between designers and developers — is so important because their collaboration is how we get our job done as a product team.
Inefficiencies in design dev collaboration
Design-to-dev collaboration one of those challenges that every product organization grapples with over time, and it's definitely a catalyst for design Ops. This was also a really big one for us.
Before we had the workflow we have now, most of our design teams were working collaboratively in Figma file all together. For a lot of teams out there, especially smaller teams, this makes a lot of sense. You don't have the budget or maybe the need necessarily to go broader than that. But like most teams who are beyond that, what we found is that when you're working in those same Figma files, it starts to cause problems over time. You'd think “we're all in the same file, this is easy. Collaboration is perfect”, right? It just wasn't the case for us.
By bringing everyone into the same file, from designers, product owners, and developers, we were actually running into some pretty major problems.The first thing is that each designer early on had their own way of setting up their own files. At a small scale this isn't a major problem, but when you start to multiply that across a large organization, or over 20 different product teams that you might be working with, that makes collaboration really difficult. So many of our designers early on were doing their own thing, there was no real standardization for design organization and documentation, and yet that's exactly what our developers and our broader organization needed at scale. The immediate impact of having everyone in the same file right off the top was lack of clarity.
Here's an example. We have our working file in Figma and we used to, back in the day, draw a line and put our next iteration right below it. We would redline in Figma to help out our developers, and we would also sometimes export our files into a PDF and give direction by doing things like making notes around accessibility there, and then we would send that off to them. And what was happening is our developers were getting very confused inside of that design file.
Designers were constantly trying to satisfy everyone within a single design space, and as result, collaboration was a struggle. There were trust issues starting to grow among the team members because neither side was truly able to really work efficiently.
That's where my team and those in our design leadership had to take a step back and ask ourselves:
“How do we solve these trust issues and the confusion that we're having?”
“Exactly where in the communication and the process of how we work, where are those breakdowns?
“How can we identify those and then how can we fix them?”
That's the really important part.
So to solve the problem, you first have to get an understanding of it. I often relate design operations to my UX background, where your customer is your user. But in design operations, your customer is your design team. We have to solve those same problems.
So what we did together is we just looked closely at how our designers and our developers were regularly interacting during the product development cycle. In doing so we were able to identify a few parts of that design to dev workflow that were causing a lot of inefficiency.
When a design was ready for development, designers were telling the developers either word of mouth or by email with a Figma link and saying “hey files ready for you”. Seems pretty simple, but the problem is sometimes design needs to make small updates or tweaks to those designs and the developers are just assuming that things were ready, now that's going to go ahead and lead to problems down the line. Time is going to be wasted and that mistrust will grow. People fooling around in files they shouldn't be in, as the team is trying to work to make new updates.
Another example of this is when new iterations came and we’re stacking our iterations on top of each other — that creates unclear direction for the developers.
“What has changed?”
“How do I navigate this humongous file?”
“How do I know where I need to go as a developer?”
And also, if I’m brand new to your project as a developer, I have no context as to what in the world is happening in this single file.
Our developers were also having a really hard time understanding the flows and the interactions that we were creating in our designs.One of the worst things for your product development is having a developer infer how a product should be designed or should be worked based off of a design with no documentation or clarity.
Time is our currency, so any inefficiencies in a process is costing us. What we do is we use the data on where our teams are spending that time within a product and find these things that are costing us with kind of a negative workflow is redoing work right if I have to redesign something or a developer has to redev it that is time taken away from us doing the best work that we can do and moving forward it's also building low confidence with your teams both designers and developers that extra time it's taken to develop because you're looking at PDFs and red lines and trying to figure out what goes where you start to find design discrepancies as you go through in the QC process when you're like I gave you everything in this one file why don't you just follow what was here and they're like yeah but you have seven things in here I don't know what I have to do and then overall that just starts to create really bad cross-functional relationships and that's never a good thing.
So if your team is running to similar inefficiencies like we, first take it from me you are not going to be able to figure out everything at once. You have to take it on in pieces and prioritize what's most important, but I do have some steps here that you can follow to solve design to dev inefficiencies a lot faster.
First is to take an inventory of how your team works, particularly around your workflow and tooling. What is working and what is not working. Similar to in UX how we'll create a user flow or a mind map or a user map of what an experience looks like, do that same exact thing but do it for your team. Apply the same approach to build a comprehensive overview of your team's experience, from start to finish. Once you have that, you can conduct listening tours, with your design, leadership, and development teams. Having individual conversations with those people is so invaluable, because these are the people who are doing the work every single day and you get to understand their preferences and challenges. If someone with a listening ear asks them their perspective, they will spill everything and that is gold for design operations.
For our team, going through these steps is what helped us uncover a lot of these inefficiencies. Now, I want to share the exciting aspect of how we improved our processes. We transitioned from an inefficient single-file system to now changing over to using Zeplin in our workflow. I want to share some parts of our Zeplin workflow with you right now because it has been incredibly helpful and continues to be.
Zeplin workflow
By using Zeplin as a separate space for our finalized designs, we were able to avoid the confusion that was happening when we had everything in the same design files before. It really gives our devs everything they needed in a very organized and systematic way.
With Zeplin, we’re able to do this first by keeping that inherent messiness that we like to do in our design exploration completely away from our development teams. There was no one fooling around or surfing around in files to see what was going on because what they needed is right there.
We also get a nice orderly way to update and iterate on those new versions and designs. So instead of expecting a developer to know how my design file functions, we put it in one place it's clearly marked, it's updated, and they can get exactly what they want.
Even though there are multiple ways to mark things ready for dev in Figma — and don't get me wrong this is not trashing on Figma at all — having Zeplin was really central to us for design to dev collaboration and making that whole process less error prone, less time consuming across our entire product team.
There’s also some additional collaboration challenges that our Zeplin workflow solved for us. So before, our developers were getting confused on what the screen flow was. Sometimes it just looks like a sea of pages and they were having a really hard time kind of following the path that they needed to. There's also early breakdowns in understanding, too, with having to cross-reference PDF files or anything else around design direction and accessibility.
Zeplin has really helped with unifying our designers and our developers because there are lot of features of Zeplin that have helped us move conversation and collaboration forward. A big part of that is how Zeplin keeps documentation structured and in context.
For example, one of the features that has made a really big difference for us in design and collaboration with our developers is called Flows. It's a really nice, unified way to document the complete user flow, which are sometimes difficult to do in other tools especially at scale.
In those earlier versions of Figma, there's a lot of manual work. A lot of arrows and notes and those kinds of things put all over place to try to communicate what was happening. With Zeplin, we can easily connect those pages visually for developers and they can easily understand the intent and direction of what we're trying to communicate in our designs. We've also gone from having multiple meetings a week to try to verbally communicate a lot of these pieces of information, to I would say not ‘none’, but a lot less than it was before. This is time that designers are spending in more meetings to try to communicate something that should be a lot easier, and this goes back to what we talked about where time is our currency.
The next thing also has to do with this reality of no one wanting to sit in a meeting just to communicate something if you can have a tool that can do it for you. One of our other most used features in Zeplin has been Annotations.
What I like about Zeplin and what our design team likes about it is you can create these points in time directly on your design and you can communicate whatever you need for things like requirements, behaviors, accessibility requirements — it's all very clear.
With Figma, we had a lot of cross-referencing that was going on with PDFs and red lines. Our design team was first spending time creating PDFs — and no one likes to create a PDF — then send that, while also making sure that the team has the most recent file. Again, time is being taking away from our designers doing what they're truly here to do which is design, and same thing for our content strategists who are also spending so much time making sure everything's right in these PDFs, whereas they could be working and spending their time on better things.
Zeplin gives everyone what they need, when they need it. We're listening to our developers share their feedback, where we had thought everything was great, but developers were having a hard time tracking through things. Zeplin has actually been super helpful with opening up just better communication channels through our workflow.
As a design operator, part of your job your responsibility is allowing your team the time that they need to do what's most important for them and that's their craft, so you you have to always think about what can I do to give everyone else more time to do what they're actually here to do.
Introducing new tools to teams can be super time consuming, but it’s important part of the job especially during onboarding for new developers. When introducing a new tool to a team, we record the demo and share it in a centralized place accessible to all development teams. This way, when onboarding a new developer, they can watch the demo for tools like Zeplin, saving time on additional training.
But don't forget that your teams also need time outside of stand-ups and project meetings. Trust, communication, and norms develop over time. Provide opportunities for interaction, whether virtual or in person. Gathering feedback from the team is a favorite part of the process. Nurturing relationships and seeking feedback through methods like retrospectives or asynchronous surveys helps improve processes.
I am not single-handedly taking on design operations and the responsibilities for every design team across our organization I have the great honor of working and collaborating with other design leaders at T Rowe Price. Each person brings a different background, knowledge and experience, ad if you find people in your organization — maybe that is you — that really enjoys that part of the process, listen, step up, and use those things. This builds stronger communication and a more robust design community.
As a participant in our community, we achieved a lot before the existence of design operations. We developed a large-scale active community with decentralized teams, established a design system, and improved communication. Sharing best practices, particularly in onboarding and agreeing on design tools, has strengthened our teams.
Thank you for listening to the presentation. I hope our process for identifying and solving problems in design operations can inspire your teams. Looking forward to the Q&A, and feel free to connect with me on LinkedIn or explore other provided links. Thanks again.
Fin
