<aside> 🎩 Role / User Experience & Service Designer Lead
</aside>
<aside> ✅ Task/ Create an efficient process between Design and Development junior teams.
</aside>
<aside> ♥️ Client / Internal.
</aside>
<aside> 💡 Keywords/ Agile, Teamwork, Product design, Processes
</aside>
The company I worked for received investment dedicated entirely to I+D, and as a result, a team of junior Developers and junior Product Designers were hired. The good thing was that they were full of talent and vision but with a lack of previous experience working with others.
The purpose of this process was to support the design team and development team so that they could work more efficiently by optimizing our ways of working.
The first struggle was to put in order efficient and useful processes for our design team. Even if you familiarize yourself with tons of guidelines, best practices, and examples... Nothing is set in stone, so I always had to remind myself to be humble and understand that those processes would need to be adapted to our circumstances (For example, the fact of having a hard time gathering a user focus group for a few hours in a room due to the nature of our industry).
I was lucky enough to be working closely with a core team of product designers, content designers, and user researchers, and their aim was also to facilitate better flows and collaboration channels between development and them. Although the development team had very skilled people, as mentioned there was a lack of previous experience working with designers for all of them, so we had to brainstorm together which ones would be the dynamics that would suit for both teams.
The objective it was to encourage the questions and understanding of the functionality so we could reach better conclusions not only for the current development but also for future versions.
<aside> ☝🏽 This flow of interactions kicks off in the middle of the design process, once the research and conclussions sessions were already finished between everyone.
</aside>
Presentation of early screens to solve doubts and concerns from both sides before jumping to the final screens.
Session in which the UI team will present the functionality and will go over the file structure.
Dev team will have 72h to review the file and present their doubts & questions.
UI and Development team should have a couple of screen review sessions before implementation.
Developers should create a checklist of items to be fixed. If not doable, those items to be fixed should be moved into
Issues Raised on the Kanban board.
Soon, the need for a Product Owner (And a Product Manager too) responsible arose.
Together, we ended up defining the following main commitments and working to understand how we could turn these goals into actionable steps. For example, "Maintain a holistic view of the design team's capacity and facilitate the flow of design projects" would translate to measuring the average time it takes to create the first MVP of a new functionality. This was only for guidance (Keep in mind that at this point, we were still far from having a Product Owner and Product Manager roles that would help us manage and prioritize the roadmap), so we could understand the team's capacity and plan accordingly.