Driving design maturity in an Agile-centric startup
If you’re anything like me, as a designer you want your organization to understand, respect, and help you build your design practice. Maybe you’ve wondered “How can I build a sustainable method of communicating and collaborating with Engineers and PMs that moves design out of a last-minute, pixel-only activity, to a long-term strategic practice?” In other words: “How can I mature the design practice at my organization?” This article discusses some practical steps and insights that have worked for us during my +2 year tenure at TriNetX, a data-driven healthcare company that helps research hospitals and pharmaceutical companies conduct better clinical trials.
Design Maturity
The now-famous report “The New Design Frontier” architected by the amazing Leah Buley, and Chris Avore and Stephen Gates posits an instrument to measure how “mature” a design practice is within an organization. The instrument establishes five levels that go from “Producers” (Design makes it look good) to “Visionaries” (Design means business).
Buley argues that the best way to drive up the design maturity at an organization is through the process. Process, process, process! Why is that? A visible process is something that people can respect and it helps formalize the practice of design while challenging preconceived ideas that may already exist at an organization. This is what we did at TriNetX and it has worked wonderfully: in 20 months I can say we went from a sub-Level I/producers company to a solid Level II/connectors level with some bits of a Level III/Architects level, and we did all this while having to pay up the “design debt” that a large number of part-time designers left at the company. Good design is notoriously rare in healthcare, just to paint a picture of where I was back in 2018:
I was a newly-arrived User Experience Designer wishing to do more design research at the company, and while my team supported my efforts, product development is done in two-week sprints. These two-week sprints permeate the entire organization’s calendar, making it very hard to establish good research plans that span more than 14 days and to plan with my product managers and engineers. On top of it all, it’s hard for my team to they see how busy I am because while the engineers use a task manager to track their work, I didn’t, so I can’t provide organizational visibility. One more thing! I was establishing the first design team at a young startup and no one really knew about design process and methodologies.
This is an old problem: Jeff Gothelf and Josh Seiden talk about this in their seminal book “Lean UX”. They suggest that you should plan at least three sprints ahead so that you have enough time to brainstorm, prototype, test, evaluate and refine your designs before you send them off to engineering. This is certainly a good approach, and it’s a good way to start talking about the design process at your organization. However, for many projects, three sprints are simply not enough.
But why does the process matter so much?
Simply put: because you want to do better. Having a systematic, transparent, and organic process that fits in your organization, that everyone can see and that you can follow to do your work effectively and efficiently is a way to do better design. I love Hugh Duberly’s preface to his compilation of design processes that reads
Our processes determine the quality of our products.
If we wish to improve our products, we must improve our processes; we must continually redesign not just our products but also the way we design.
That’s why we study the design process. To know what we do and how we do it. To understand it and improve it.
To become better designers.
OK, but how exactly did we do it?
- Make your process visible and easy to follow
- Make your workload visible to others
- Anticipate and track all the design work
1 Make your work process visible and easy to follow
The first thing we did was to create a project in Jira for our design tickets. But, Jira is a task manager for software development… right? The rationale was that we needed to use something that everyone was comfortable with. Every new tool you add to your team increases the barriers for adoption, so use what people already know and use. Each Jira project has a set of issues: normally for engineering projects, you have things like Bug, Story, and Epic. We created a single issue type for our Jira project called “Design Request” and a Jira workflow to move the ticket across different statuses. We tried to map out what we considered to be the key steps in our design process:
On top of that, we modified the form you use to create an issue so that PMs would get used to providing enough information for us to get started. If there was not enough information, we would “send the ticket back” to an “Awaiting Brief” stage. This started to create accountability between design and PM. Finally, we created a Confluence page with a guide on how to fill out these tickets so that the PMs could use it as a reference, and we briefly trained them on it.
This started to force the entire team to think about the projects more deeply, and to think in terms of measurable outcomes and not in terms of features.
This worked well for a while, however, we started to see that the workflow we had designed in Jira was not always reflective of how we would go about solving a design problem: projects would often be put on hold (did I mention we’re a startup?) and we would have no way to show that. Some projects didn’t require design research at all, while others were only made up of research. In fact, we handle all sorts of projects:
- Exploratory research
- Usability testing
- Information Architecture audits and UI improvements
- Data visualization
- Service and strategic design
So we created a second version of the workflow: More flexibility means we can support our teammates better.
💅 Pro tip: Enforce your now-visible process as much as possible
using Jira is a pragmatic solution to how you go about making your process visible and have the extended team agree (or disagree) on it, and it has made our work with engineering and PM so much better because now we can talk in the same language with them. However, it only works if you keep reinforcing its use. So when a PM wants new work you have to try to push back and say “OK, can you please make a ticket for that?”, or if the ticket is empty, then message them and say “We need a bit more info, please check our confluence page for a quick guide”.
2 Make your workload visible to others
Now that we have tickets we also have a Jira board with all our work. So whenever we discuss projects with anyone we can say “look at all the stuff we have to deliver on sprint ABC, is your project really that high priority?”, or we can talk to our lead PM and say “please help us with a master priority list because we have conflicting requests from different PMs”.
How does this lead to maturity? A tangible process makes people recognize that design is not just “what happens on-screen” (Level I). It exposes the many different activities that as designers we carry out to do a good job. On top of that, we create accountability and ownership of our work because it can now be tracked. We use the Design Request to document everything we do for a project: design research, usability test results, prototypes, mockups (using plugins), and conversations (using the messaging system). We also started using the issue ID to track our mockup versions in Abstract whenever we had to and we leave the specs for the engineers there as well. Our issues are the single source of truth for the brief, research, comments, and specifications.
3 Anticipate and track all the design work
We can now discuss in terms of sprints and quarters and we can anticipate the big projects with considerably more time than just three sprints.
Once PMs and engineers started to see the huge amount of work we had on our plate and the process that each project goes through they started to become more interested and open in the design process and theory. We went from a place where design was an afterthought to having strategic design conversations and on-site user research and testing within 20 months.
Key takeaways
- Maturity is driven by working and insisting on our processes. If you make your process visible you can get buy-in and engagement from your teammates
- Using familiar software that tracks work at your organization with a simple template is an inexpensive and quick way to help everyone think about outcomes instead of features, and to make your workload visible
- This is an endless task because you can always do better, and so do your processes. Keep iterating! (but enjoy the journey)
Pitfalls
I am not saying that Jira will solve your life. This success had to do with:
- The openness of our team and the fact that TriNetX is a young organization.
- Our willingness to let others help shape our process key
- A relentless fight for a seat at the table
Remember: making your process visible allows your organization to discuss it, mold it, criticize it, agree upon it, and improve it
P.S. Thanks to Lauren Armstrong for her invaluable feedback!
