Untangling the Delivery System Behind an Inconsistent Product
what i did
As a Design Lead on a large federal product, my official role was to lead a team and guide the design standards of the product we were building. Unofficially, my role was also to improve the way the rest of the organization engaged with design and implemented our designs in an effort to create a more user centered product.
Even prior to when I started in this role, the recurring feedback from the client was that the product we were building looked inconsistent throughout and did not look or feel like one single product. Early on the problem was framed as an issue limited to the design team I was leading, and that was where I was instructed to focus my efforts.
However, once I investigated further the root causes extended beyond the design team and were instead a result of how different teams collaborated, communicated, and delivered work.
I used my Service Design background and various mapping techniques to figure out what was really going on. I facilitated conversations across teams to understand root causes and co-designed solutions with them to find a better way of working together. As a result I improved the overall consistency of the product, lowered friction across design, product, and engineering teams, and reduced avoidable development work that had to be redone.
Why it mattered
This issue around “consistency” had been a challenge on this project from even before I joined the team, and had gone misdiagnosed for a long time. This project shows my ability to challenge internal assumptions and define complicated problems in order to pave the right path forward.
My intention in writing this case study is not to be disparaging to where I was working, but to highlight much we were actually able to improve as a result of my efforts. The collaboration practices and process improvements I introduced increased cross-functional alignment, reduced development rework and feature rebuilds, and ultimately saved both time and engineering resources.
My roles
UX Design Lead
Service Designer (unofficially)
tools
Miro
The power of persuasion and clear communication
What I Made
Ecosystem maps
Multilayer process maps
Process improvements
understanding the landscape
A new team structure
Due to the recurring feedback from the client about an inconsistent looking product, designers were transitioned by leadership from being embedded members of each development team to becoming a centralized resource each team could request designs from.
The goal of this was to give the design team more autonomy and reset the relationship between product owners and designers. While product owners defined the requirements of the design, occasionally they were also dictating the look of the design as well and it was contributing to some of the inconsistencies we were seeing.
Going forward all communication between the development teams and the designer would be filtered through the Business Analyst (BA) on each team.
This model was also to encourage the designers to communicate with each other more and establish design standards that would eventually lead to a more consistent looking application. However, designers were already doing this. Designs and handoff specifications were highly detailed and thoughtfully produced. There was also significant effort put into maintaining consistency and adherence to the design system.
It’s not to say this new team structure didn’t achieve what it was meant to, but it was only focusing on the symptom of a much more complicated breakdown in process. My experience in design taught me that there’s almost always more lurking beneath the surface, and I took it upon myself to finally figure out the root causes of what was happening.
Gathering data
To understand all of the moving parts, people, and processes in front of me I did some informal discovery research as I got my bearings in this new role. I observed processes unfold and gathered enough information to map out the steps that take place from when a design need is first identified to when its ultimately implemented. I also mapped out who was involved in this process and what their degree of influence was.
My goal with this was to understand as much as I could about what was happening outside of the design team because in this new team set up that was a major blind spot.
I had very little visibility into what was happening before a design request got to our backlog or what happened after designs were handed off. I was able to start piecing together the end to end process by establishing rapport with the business analysts I was working with and just start asking them questions about what was actually happening in the parts of the process I wasn’t a part of. I also took the opportunity to ask them what challenges they were dealing with as they were moving through the same process we were. Like us, they were also frustrated by the continuous stakeholder feedback about the product’s inconsistencies and not sure what to do about it. Finding common ground ultimately helped us work together toward a shared solution.
Lack of access to devs
While I was able to gather information from the point of view of the Business Analysts, there was still an importance perspective I was missing for a long time, and it proved to be very challenging to get. I still didn’t know what the developers were experiencing or what challenges they were having.
In this new team structure, we were supposed to go through the Business Analysts (BAs) whenever we had a question about anything related to requirements or implementation. They were also instructed to handle the design to development handoff process entirely. So we had zero access to developers.
Whenever I asked directly who the developers were I was often met with skepticism or just confusion as to why I was trying to communicate with them instead of through the BA. In Agile, there’s typically an effort to protect developers’ time from unnecessary requests and meetings, which is totally understandable. However, good designer and developer communication is incredibly necessary. As proven in the end, limiting this communication actually contributes to rework efforts that take away from the developer’s time and effort when it could be allocated to something more valuable.
Early on I realized I was battling an internal culture that didn't fully understand how design fit into the product development processes. The majority of people I worked with had never worked with designers, so they didn’t understand the importance of having an open line of communication between design and development.
It's hard to say, whether this lack of access to the developers predated the new team structure or not, and to this day I never really found out for sure. However one thing was certain, under the new team structure any chance of face time we would have had with the developers to build that rapport no longer existed.
It’s also important to remember that this was a federal contract, so there were hundreds, if not thousands of people on our Microsoft Teams directory and no org chart available. We couldn’t just DM a developer, we had no idea who they even were or how to find them.
I hypothesized that this lack of direct access could be contributing to the consistency issue, but I just didn't know exactly how…yet.
Mapping what I knew
the step by step process
In another effort of understanding the environment I was working in, I documented the step by step process of how a design moved from the request to implementation phase.
I was able to identify that there were two handoffs happening. One before a design is made and one after. In both cases the BAs were facilitating these handoffs. One handoff involved communicating the requirements gathered from the product owner and documenting them in a ticket that would land on our design backlog. The other involved downloading design assets from our ticket and then re-uploading them into a separate development ticket.
At this point you may be wondering why we weren’t just using Figma Dev Mode. Since this was a government contract, there were several tooling constraints that resulted in this and it’s explained a bit more in the key insights.
While it's not uncommon for the BA’s role to be facilitating these handoffs in an Agile environment, them being the sole hinge and translator in which the success of this process relies on carried a lot of risk. Not to mention the added stress and pressure on them.
People involved
Given that my only line of communication was with the BAs on each team, and occasionally the Scrum master, I needed to get a better understanding of who else was involved in the building of this product and what their level of influence was when it came to the way an interface looked after it was built.
I made an ecosystem map that detailed the different people involved as well as different “touch points” whether they were documents, assets, or routine meetings involved in the process.
I want to note that when I made this ecosystem map at the start of the process it was based on incomplete information and my general understanding of how product development worked and what I’d observed so far in this role. I was still missing the developer’s perspective and was having trouble getting it due to the lack of access explained above, but this was still a helpful baseline.
After making this map I was able to determine that theoretically the designers and developers had the most direct influence over how the interface of the product would look, so they’re closest to the center. We were the ones moving button components around in Figma or writing code. Knowing what I know now, I underestimated the influence of the other factors in the outer circles. The map below shifted entirely as I learned more.
Game of Telephone
The BAs being the sole line of communication in these handoffs created a game of telephone that resulted in a lot getting lost in translation.
A recurring challenge was that the designers often had very technical questions about a component’s code or how something would be implemented. We were having to ask these questions through the BA, they would relay it to the developer, and then their answers would get back to us.
The reverse was also happening. If developers were implementing a design and they had a question about a detail on the specs or were running into an issue with a component’s code, they were trying to troubleshoot it through the BA. Most times we wouldn’t even know there was an issue while implementing the design until after it was already demo’d to the client. By that time the implementation of the design looked entirely different than what we handed off which further contributed to the inconsistencies in the product.
The designers painstakingly ensured that what we were handing off was consistent with the rest of the application and followed the same design patterns throughout. So it was incredibly frustrating to see the implementation not match that, contribute to the inconsistency issue, and not have any means to intervene or course correct before the client demo.
This was starting to confirm my hypothesis that the issue of inconsistencies in the product were actually rooted in parts of the process the design team wasn’t involved with and had no visibility into.
The shift
Keeping an open mind
One thing I prioritized while going through this experience was empathy and an open mind. I never wanted to point fingers to one person or team as the reason why we were having this larger issue. I made a conscientious effort to keep the focus on the flaws in the process and not the people involved in it. I believe that most people want to do their jobs well, and it’s often a result of other factors that prevent them from doing so.
This mindset proved to be very valuable with what happened next.
THe meeting that changed everything
After some time, I was finally able to speak with the developers of one team directly. This unfortunately was a result of several other issues coming to a head, and it forced the organization to acknowledge that a lack of access between design and development was causing more issues than it was solving.
There had been a major miscommunication around a set of designs that were delivered. However shortly after the designs were delivered the development effort was reassigned to a new team. Somewhere in that transition, the designs and specifications were lost in the shuffle. The developers were attempting to build without designs or specs to reference, which slowed development and put the team at risk of missing a contractual deadline.
We were not made aware of any of this until the last minute, when a flood of questions started coming through the BA and Scrum Master. They were relaying questions from the developers, but every single question had already been answered in the designs and specifications we had created.
I pushed for us to speak with the developers directly. I explained that relaying questions secondhand was slowing our ability to resolve the issue, and given the deadline pressure, the team agreed. For the first time, the developers, designers, BAs, and Scrum Masters were all in the same room together.
Within minutes, the original designer pulled up the assets and specifications needed for development, and it immediately became clear that it was the developer’s first time seeing them. That shifted the conversation entirely. The issue had originally been framed as the designer not providing the right information in the specs, but the real problem was that the specs had never made it to the developers in the first place.
Everyone involved was balancing an overwhelming amount of work, and mistakes happen. But the meeting revealed how little visibility design and development actually had into each other’s workflows under the new team structure. It made me start to question what other issues were happening behind the scenes that we couldn’t see, and how much they were contributing to the broader consistency problems we were seeing across the product.
The Cost of Silos
Had there been a direct line of communication between development and design, the situation detailed above could have been course corrected much earlier.
Any time developers are forced to build without finalized designs and specifications inconsistencies become much more likely. Details like spacing, component variants, interaction patterns, and accessibility requirements can easily be implemented incorrectly or interpreted differently across teams.
While a single incorrect button variant may seem minor in isolation, these small inconsistencies were compounding across the product and surfacing in negative client feedback that threatened the overall success of the work.
At this point, I had identified one potential driver behind the product consistency issues. But after speaking with additional development teams, it became clear the problem extended beyond communication alone.
Finding the sources of inconsistency
Inconsistency was the tip of the iceberg
After identifying communication breakdowns between design and development as one possible contributor to the product inconsistencies, I wanted to better understand how widespread the issue actually was and where else inconsistencies were being introduced throughout the delivery process.
I attended sprint demos across multiple development teams and documented inconsistencies between the implemented product and the designs that were handed off. I would capture screenshots of the implemented design, compare them against the original design specifications, and then follow up directly with teams to understand how those differences occurred.
As I investigated further, I learned that the inconsistencies were not isolated to a single team and they weren’t all caused by the same issue.
In some cases, developers implemented components differently because product owners requested changes during development that conflicted with established design system guidance. In others, inconsistencies originated from acceptance criteria written in development tickets that contradicted the approved designs.
One particularly revealing example involved the language used within homepage cards and button labels. The implemented copy differed significantly from the designs, despite extensive work being done during the design process to ensure the language was both usable and more accessible for screen reader users.
After speaking with the team, I discovered the developers had followed the acceptance criteria written within the ticket rather than the attached designs. This exposed a deeper operational issue: there was no shared understanding around whether the ticket requirements or the approved design specifications should serve as the source of truth during implementation.
The more teams I spoke with, the clearer it became that these inconsistencies were symptoms of broader structural and operational gaps across the Agile Release Train.
To better understand the full system and house all of the information I was learning through these meetings, I created a multi-layer process map that documented the flow of work from initial design request through final implementation. The map captured the tools, touchpoints, and pain points experienced by designers, business analysts, and developers throughout the process. Once I was able to see everything in front of me I could start synthesizing it into larger themes and tease out which pain points had easy solutions from the much more complicated ones.
Key Insights and improvements
Fragmented Communication & Organizational Silos
Rigid communication structures created delays, misunderstandings, and a loss of context across teams. Problems that could’ve been flagged earlier weren’t caught until the very end, many of these contribute to the larger consistency issue.
Competing Sources of Truth & Unclear Ownership
Teams lacked a shared understanding of who owned implementation decisions and which artifacts should serve as the authoritative source during development. The extensive work the design team was doing to ensure consistency was constantly being negated by external influences.
Delivery Processes Misaligned With Iterative Work
Rigid PI planning and early scope/acceptance criteria definition created a mismatch between planning artifacts and evolving designs. Development tickets written months prior that were never updated to match the final design led to outdated requirements being carried into implementation leading to increased product inconsistencies.
Unrealistic Delivery Expectations
Teams were operating in a reactive delivery environment that prioritized speed and short-term delivery pressures over sustainable collaboration and quality control. It was extremely common for teams to bypass design and go straight to building, many times without the knowledge of the design team. More times than not, that development work had to be redone as a result of it being inconsistent with the rest of the product.
Limited Visibility Across the Delivery Lifecycle
Teams operated with fragmented visibility into the broader product and delivery ecosystem. This made proactive collaboration, informed decision-making, and early detection of potential issues difficult. Issues in implementations contributing to the the inconsistency problem weren’t caught until development was done and everyone had to move on to the next thing.
Tooling & Contract Constraints
The tools available to teams combined with federal contract constraints created operational friction that slowed delivery and increased the likelihood of implementation inconsistencies. Tools that would’ve drastically improved design and development alignment were completely off the table.
the Constraints beyond the scope of design
While mapping pain points and the general ecosystem revealed larger systemic and organizational issues, collaborating directly with developers, BAs, and Scrum Masters allowed us to identify several opportunities to improve how teams worked together day to day.
Not every issue could be solved at the design team level. Some challenges were rooted in broader organizational dynamics, including leadership alignment around design authority, client expectations, contractor structures, and tooling limitations that extended beyond my direct scope of influence.
One example was our inability to use Figma Dev Mode during implementation. Because the project was staffed across multiple contracting companies, tooling access varied by organization. While the designers all belonged to the same contractor and had access to paid Figma seats, developers were distributed across different companies that each independently determined whether to invest in Dev Mode access for their teams.
Although I advocated for broader tooling access throughout the project, this ultimately highlighted how operational factors were directly impacting collaboration and implementation quality.
Despite these larger constraints, I was still able to facilitate several meaningful process improvements across design, BA, and development workflows.
An updated ecosystem
The more I synthesized what I was observing across teams, the more I realized that my original understanding of the ecosystem was incomplete. I had initially mapped the system based on assumptions from more traditional product development environments, where design, product, and engineering roles have relatively predictable boundaries and influence.
However, in this environment that model didn’t hold up. Stakeholders who would typically have limited impact on the final product’s look were actually shaping implementation decisions and the resulting interface significantly.
Once my understanding of how influence and decision-making actually flowed across the organization matched reality it became much clearer which problems I could realistically address within my role, and which required longer-term organizational change across leadership and culture.
This shift allowed me to prioritize improvements that could be implemented quickly, while still acknowledging larger systemic issues that were beyond my direct control. Over time, these focused changes contributed to more consistent implementations and improved clarity across teams in how design fit into the delivery process.
IMPROVEMENTS INTRODUCED
Structured Ticket Templates for BAs
I created a ticket template to help BAs better understand the level and type of information needed before design work could begin. The template also included guidance on writing requirements that were descriptive enough to communicate user and business needs without becoming overly prescriptive about the UI solution itself.
Establishing Design Lead-Time Expectations
A recurring challenge was unrealistic turnaround expectations for design work. Product owners and Scrum Masters often lacked understanding into the amount of effort required to create thoughtful designs and specifications, which sometimes positioned design as a delivery bottleneck.
To address this, I worked with teams to establish clearer expectations around design lead times and the level of fidelity appropriate for different stages of planning and refinement.
Introducing Low-Fidelity Wireframes Earlier in the Process
Rather than producing fully high-fidelity mockups for every planning and refinement session, we aligned on using low-fidelity wireframes earlier in the process.
This gave teams enough context to estimate development effort and identify technical concerns without requiring designers to invest significant time into polished solutions that were still likely to evolve.
Unexpectedly, the wireframing process also became a collaborative refinement tool. Creating early concepts helped surface ambiguous or incomplete requirements much earlier than before, improving alignment between design, BAs, and product owners.
Creating Clearer Lines of Communication Between Design and Development
To reduce friction during implementation, the design team began including designer names directly within exported mockups and specification documents so developers knew exactly who to contact with questions.
Now that the line of communication, we also began proactively checking in with developers throughout implementation rather than waiting until work was complete. This created opportunities to catch inconsistencies earlier and encouraged developers to flag situations where acceptance criteria conflicted with approved designs before implementation diverged too far.