Chapter 2: How Do We Work? (Eng)
With our partner Ortak, we don’t just provide design consultancy :) We integrate into their team and create a strong product design bond together!
Chapter I : Hello ortak!
We’re Not Just Consultants, We’re Part of the Team!
At the beginning of the process, we decided to follow the Scrum framework for project design and development, and we started implementing this fantastic method through Jira. We set our sprint duration to 2 weeks. To ensure teams could follow each other’s progress and work in sync, we invited one hero participant from each team to our meetings.
Time Management of a Sprint
We began with Grooming meetings. In these meetings, we discussed the tasks that would be included in this sprint, their objectives, expectations, and overall details. As the design team, we asked ourselves, “Can we complete these tasks within these 2 weeks?” Based on our conclusion, we added the tasks to the sprint.
In Jira, we created columns for “To-Do,” “In Progress,” “Review,” “Blockers,” and “Completed.” Thanks to these wonderful columns, each team member could track their tasks’ progress and observe what others were working on. It was a true synchronization fest!
Product-Design-Business Preparation;
After the Grooming meeting, we eagerly dived into benchmarks as the design team! We examined applications in the industry and different sectors for each task title.
By marking the flows we liked, we narrowed down our focus from a broad field to a specific area. We quickly created our own collage screens by cutting and pasting the screens from the benchmarks.
Collage Method
And here we are, ready for the Product-Design meeting! In this meeting, we enthusiastically shared the research we conducted with the product and management team. We went through the key points, learned which flows they were close to, brainstormed, and ended the meeting by creating wireframes while sticking to the decisions we made through alternatives.
Open TopicsLow-Fidelity
The Superpower of Our Designs:
Using our design system with ease, we design high-quality wireframes quickly by using components agreed upon with the product team. We add arrows to the flows using Figma plugins to make tracking easier for them. We hold Low-Fidelity meetings with at least one representative from the frontend and backend teams.
Each flow is evaluated by the entire team, and after stating their opinions, we decide on the most suitable flow through voting. When making decisions, we give the developer team time for research on technical feasibility and effort until the next meeting.
High-Fidelity
Based on the decisions made in the meeting, we review the user experience in the screens and focus on interface design. We create designs that fit the application’s language. After completing the designs, we hold High-Fidelity meetings with participation from the development and product teams to discuss the experience, effort, and technical feasibility of the screens. Finally, we determine the flow we will proceed with.
In the High-Fidelity meeting, we check and adjust the experience and interface design of the identified flow based on the decisions made.
Handover
The entire team participates in the Handover meeting. Here, as the design team, we present the final version of the flow. By collecting opinions from the entire team, we finalize the designs. We write down technical decisions on the screens.
If there is an unresolved issue, we carry it over to the next sprint and go through the same process again. Of course, we don’t stop with our designs here; we continue to follow their progress in the software development.
Meetings Galore… Dear Team, you’re expected at the meeting door :)
When the joke “We should put a stop to these 3-hour long meetings” came up, it was time for a radical change. We set out to discuss all the observed issues and come up with a solution. We identified several factors that influence meeting dynamics, such as which team would attend, how many people would be there, and the intensity of the topic/flow.
We observed that shaping the meetings according to the needs increased productivity. We tried various methods like determining the number of participants, selecting representatives, changing the meeting sequence, and deciding when each team was needed.
Defining a Rule Set;
To put an end to lengthy and unproductive meetings, we created a template. Before the meeting, we prepared all the topic titles and their presentation/discussion durations that could be covered within an hour and shared them through communication channels. We aimed to complete each topic on time with the help of a timer, and after a while, the system became well-established.
Creating Meeting Types;
This was a system we felt the need for and developed over time. It evolved into two different structures: Stable and Flexible. Stable meetings were used for tasks with specific user scenarios, while flexible ones were for fragmented tasks, concepts, detailed analyses, and large tasks that required more thought.
Low-Fi, Hi-Fi, Handover: A meeting where the stages of a flow, from the idea phase to the final version, are presented. Each coded flow went through these meetings before becoming a reality.
Product-Design-Business: Research findings related to the subject to be added to the application are shared, and if the flow is already determined, alternatives are created to ensure everyone understands the working process. If we are working on a subject with no defined boundaries, we spend extra time on innovations and solution proposals, creating concept screens and flows.
Design-Product Grooming (Mini): This was a meeting we discovered the need for over time. We work together with the product team to answer all the questions that arise while creating the flow and make decisions based on alternatives. (30 mins)
Reporting Meeting Outcomes;
Every topic discussed in Low-Fi, Hi-Fi, and Handover meetings was documented in text form. This allowed us to quickly transmit unfinished tasks to the product team with the “open issues” tag, maintain a magnificent MVP+ idea pool, and access reports for past decisions.
You can check out version 1.1.30 in the production environment…
Before presenting each flow to the user, we put them through various tests. For both iOS and Android, we review the consistency of the coded flow and design, list any errors and shortcomings, and share the findings with the testing team to decide what should be transferred to the software. Then, in Jira, we leave comments on the task in the “UI Review” column and check again after the updates.
To ensure the continuity of the experience in all conditions, we work on small versions of critical pages and strive to reach a consensus with our development team.
During this process, we noticed that involving the development team before the final designs allowed them to predict effort beforehand. Thus, we minimized last-minute mandatory changes. Consulting a capable person at the right time made us feel like we were testing the results while developing.
In cases where some tasks became complicated, we communicated directly with the programmer responsible for coding that task through short calls. This way, we prevented misunderstandings and took quick action through clear communication.
Jeff Romi Daily Meetings: Enhancing the Power of Design Together
Our daily meetings are attended by all designers in the Jeff Romi team. Each designer shares their work related to the project with others. We provide feedback to each other and discuss how we can make things better. The advantage this brings to our partner is the evaluation of the product and project from different designer perspectives.
As a result, each designer adds their magical touch and contributes to the development of projects. Enriched by diverse perspectives and experiences, designs embark on a magical journey toward a common goal.3 Musketeers :D
The Three Musketeers:
The design team consists of 3 people: 2 designers and Mentor Jeff. So, how do we manage our projects? As we mentioned, we asked for 3–4 days to create a design system when we took over the project. During these days, we created basic rules and a design language through lengthy meetings to align ourselves. We can divide this process into big tasks and small tasks. For big tasks, we fragmented the versions created through benchmark screens in meetings where we discussed our research together. We shared these versions within our team for wireframe-level refinement. We presented the resulting wireframes to each other through Slack huddle. We discussed and made revisions here. When everyone in the team agreed on the final versions of the versions, the screens were ready to be presented to our partners.
For small tasks, as the design team, we were well-versed in our design language and distributed the tasks according to our strengths. Once the screens were ready, we presented them to each other through Slack huddle and made improvements. Sometimes, as a team of two designers, we couldn’t make decisions. In such cases, we showed and explained it to Jeff as a third eye, and he provided his feedback on the flow without any bias.
