Design Process & Org Optimization
Reduce “decision fatigue”, debt and increase consistency by optimizing the delivery process.
Problem
We noticed that features were beginning to take longer to deliver. We were spending too much time discussing design decisions that were already made in the past. Our handover process wasn't developer agnostic and needed to be rather bulky depending on which developer was doing work. We were accumulating design and tech debt. UI was simply, not easy to ship outside of the feature delivery space and our UI was becoming inconsistent the futher we added onto the product.
Solution
I conducted an investigation, looking at our existing process and identifying where and how we could streamline things, ruduce debt and not create any bloat. Bring our issues to light and be fully transparent. Ultimately become more relient on Figma to: Handover designs to developers using Dev Mode. Utilize variables to start storing design decision. Start using Storybook for the front-end. I created a presentation which brought to light all of our challenges and how we plan to tackle them going forward.
I brought to light all of the challenges we're facing and shed light on how they were effecting us.
Since delivering new features and upgrades is a top priority for the Leetify startup, most of our UI updates were handled through the “new feature pipeline.” This meant we had to bundle design changes impacting the UI outside the scope of the project as well.
The reality is that we sometimes overlooked parts of the product, or developers would prioritize certain implementations based on time constraints. As a result, some intended changes never made it into the product, leading to an inconsistent user experience and various other issues.
The root of the problem was that we lacked a simple, streamlined process for making design changes outside of the feature delivery pipeline that effected all parts of the product using the same design.
On the developer handover side, while all developers were full stack, some had stronger front-end skills than others, and each had their own approach to handling roadblocks.
The dev handover issues, along with the previously mentioned challenges, led to the creation of a dev support layer while working on new projects. This introduced context switching, which ultimately slowed down future design work.
Each developer had different requirements for handovers and varying strengths in their working relationship with me as the designer. As a result, I had to adapt my workflow and handoff process based on the specific developer involved in the project.
The goal for both myself and the business was to create a more agnostic environment and establish a system that worked consistently and effectively for all developers, regardless of individual differences.
We also needed to adapt our design process, as design decisions required constant review and validation to ensure that the solutions and the reasoning behind them remained sound and up to date.
Introducing design tokens.
The goal for both myself and the business was to create a more agnostic environment and establish a system that worked consistently and effectively for all developers, regardless of individual differences.
Going forward - When we design new updates and features we'd make sure that whatever we were using was converted to a variable and any component we shipped was using these variables. Our variables would match the front-end so that design and dev are talking the same language (using alias's and component tokens).
