How I solved back and forth between designers <> Devs <> stakeholders by establishing design process guidelines
System / process design for Pixis
System Design, Strategy, Template
Me (Strategy),
Jai Dev (guidance)
December 2023 - March 2024
-> Check out the Presentation <-
High Redevelopment Efforts
Difficulty Translating Product Direction into Outcomes
Design amnesia hampered innovation since each problem was like starting from scratch
Inconsistent Documentation and Handoff
Communication Gaps
Rapid Scope Changes
Pressure for High-Fidelity Designs
Pixis, as a startup, lacked a standardized process for designers. Each designer had their own style of documenting and handing off designs, leading to inconsistently organized Figma files. This inconsistency caused a significant learning curve whenever someone accessed a Figma file, resulting in frequent back-and-forth communication between designers and non-designers (PMs, stakeholders, developers). To foster a cohesive team environment and solve this issue scalably, I initiated a project to streamline the design process.
I am a fanboy of Spotify’s design team. I used to read their design articles (I still do). So, without thinking twice, I went through all their resources and blogs for design processes. I spent almost a week researching. Finally, I prepared a solution for our team, and I thought I nailed it.
In the process and upon revisting the above values I realised that What applies to their company is definitely not going to apply to ours.
In a startup like ours, I cannot just go ahead and come up with rules and expect others to follow. You may ask designers to follow some guidelines, but you definitely cannot expect other teams to follow your guidelines. Even if you forcefully try to, it will just become bureaucratic, leading to more delays. In the end, everyone will blame you.
For instance, I wanted to split the process into phases and gate each of the phases with hard-stopper approvals. Until a responsible person approves, you cannot go ahead from the research phase to the wireframe phase, which might sound good in theory but in practice, you cannot just go ahead and split the available team and restructure as you want.
When I knew my solution was not going to work, I had to find out what would work. I went ahead interviewing people and mapping user journeys. Some interviews were unstructured and some were structured. Some were in person, some were online. With some guidance from our lead, I really enjoyed the whole process considering it was my very first time. Now I had a list of problems that I needed to form a solution for.
Scope of the project was changing from time to time
No clear understanding of the problem
No transparency was given to designers
Communication gap between Designers-Stakeholders-PMs-Devs
Subjective feedback and personal bias
Gap in understanding the product on many levels
No time to do wireframes, PMs demand for Hi-fi designs
Developed product won’t look like designed product
Developers work on individual levels
They do not refer to our design system; they refer to Material UI
Each developer has their own set of development components
No communication with the respective designers
Some developers do not know how to work with Figma
Animations are eyeballed
If some use cases are missed by the designer, they add them on their own or upon PMs' knowledge (But they do not reach out to designers)
Let's look at some of the key solutions I've designed to solve the above mentioned problems, you can look at the whole solution and learn more about the process here
This project taught me invaluable lessons:
Tailoring Solutions: Solutions must be tailored to fit the specific context of the organization.
Importance of Communication: Clear and open communication is crucial.
Adaptability: Being adaptable and willing to pivot is essential.
Avoiding Assumptions: Assumptions can lead to ineffective solutions; validation is key.
Continuous Feedback: Feedback should be an integral part of the problem-solving process.
