Built Design Reviews with Developers

I am learning to understand the developer’s thoughts about designers.

The relationship between developer and designer has always been vital in the product development process. The designer crafts the product, and the developer brings it into reality.

However, it’s not uncommon to hear developers say, “We cannot achieve this design,” after a design showcase. It can be due to the need for more collaboration between designers and developers. As designers, we must understand that developers play a significant role in executing the product and that their insights into technical feasibility and ideas can significantly help.

When I became a part of the product team at my recent company, everyone from the India and China team welcomed me with big smiles as they were searching for a designer from the start of the project. They got one (that’s me) after 1.5 years of the product journey; they managed their UX work with a designer who was supporting from the US, and the developer team could meet the designer weekly once. Adjusting their timezone and finding a standard time was a pain.

I was excited about the project and never felt so welcomed by developers on the team. I’m just kidding; their curiosity was something else.

But what is a ‘Built Design?Review’?

It evaluates whether the developed product aligns with the design teams' creative vision and user experience. In other words, reviewing the developed project helps verify that all graphic and technical components are displayed and function correctly.?

One real-life example I would like to share with you all is when I was working with my recent company as a product designer:

Collaboration with developers has always been one of the toughest. After a month on the project, I started recognizing a pattern in our cooperation. Once the design demo gets shipped to developers and a handoff with all guidelines, I saw they would create a ticket in Jira. After the end of the screen’s development, developers would post a screenshot on Jira, tag me, and ask me to review and get a signoff on their implemented design.

This process was so chaotic at times; as a designer, I had to keep track of Jira tickets and comments, review the design, and get on immediate calls to pass on feedback, with no track of what feedback was and a lot of back forth (sometimes my half of the day went into just reviewing and replying on the tickets). Sometimes, my Jira notifications would get lost in a pile of emails.

I also started attending standups daily; though it was not mandatory for designers, it helped me understand what was happening in the team.

As we were an on-premise product, we did not have an actual production to install on a Mac. Hence, Screenshots were the only way for me to review or for a developer to share their screen and inspect each component (A significant pain and time-consuming process)

I devised a plan to improve the design review call, which occurred once a week while the team was working with a US-based designer.

Can we save everyone’s time and create a tracker in Confluence? The product manager could provide a priority list indicating which developer is working on which feature, part of the feature, and the release date. We could also know how many developers will showcase their work for review every call.

To explain this idea, I created a tracker. I set a 30-minute call with our team to help them understand the problem with the current process (1 designer = 10 developers), which was the ratio—a big ratio to consider.

Can you imagine?

I explained a tracker and said, “Let’s have a one-hour call on Tuesday/ Thursday or Monday /Friday. We chose Monday and Friday. Monday is the start of the day. Some people in China feel comfortable with this because of the time zone. They can start fresh, get review comments, and know how much is on the table for the week. Friday was suitable for my Indian colleague’s developers, as they said, “I could prepare a plan on Friday, and on Monday, I could start with the implementation.”

We also had an async check-in on teams on Wednesday or sync if required so they are not stuck and can immediately start the next call.

Our product was timebound, and we had to make quicker decisions for our release and improve our processes to enhance our productivity smartly; we had clients to onboard after every?release.

Coming back to our collaboration process, I asked for screenshots of the screens a day before or four hours before the design review call, which saved me time in the actual meeting. On review day, first thing in the morning, I asked for nominators for today’s review and got screenshots. That way, I know what part of the feature to expect a review from and which developers to expect a review from.

The next step was documentation. I believe in documentation a lot.

Documentation is a must-have thing for designers as well.

I would then tag the participants on Confluence (mandatory participant: product manager, lead developer, and developer who was executing ). Sometimes, this session would be fun, where we played games like how many issues, who spotted them, how to resolve them, how to categorize the problems, etc.

My documentation included:

• Name of participants
• Feature name/screen presentated
• Screenshot of screen
• Developers name
• Feedback on UI/content/layout/translation (these categories would help to tag responsible people to resolve issues)
• Date reviewed
• Next showcase date
• Design Figma link
• Statuses (review done, technical blocker, design blocker).

This live documentation helps everyone on the team to be on the same page.

Collaboration allows us to identify the solution, considering time, effort, and technology. While working in my recent company, I tried several ways to collaborate with developers. It helped my team and me understand developers’ ways of working and building our relationship.

This write-up should be shorter. But I am sure you will get something valuable at the end of the article.

Below are different ways I have tried to improve collaboration with developers

1. Guidelines for developers

Often, developers are a group of teams working isolated from product teams; Ia guide on the roles and responsibilities of the product owner roles and responsibilities are CX, Stakeholders, developers, QA, etc. This part of the process helps identify which team member inputs are required when, at what stage, and why.

Developers occasionally know who is doing what and what to expect from everyone. Is this a guiding principle? It helped me and could help you. Fingers crossed.

2. 1:1 meet bi-weekly or monthly with developers

When everything in the team was going well, I felt a slightly uncomfortable scenario in which developers were not responding to problems related to design to the designer; maybe they thought these problems could be solved by the product owner or via the product owner through me.

I had a good relationship with my QA colleague as she was my friend; she told me, “I get many design issues while I check developers’ tickets in QA.” Often, QA used to raise a ticket or attend weekly design UX review calls. Then, this feedback would go back to developers, and we would get into circles.

To understand this problem in-depth, I started having quick 15-minute 1:1 calls with my developers bi-weekly. Coffegan and the agenda was simple:

• Let’s meet and chat about our work.
• Get to know each other’s space.
• Open forum

I then understood that developers thought that as a designer, I did as instructed by product managers, that is, designing screens directly, and that’s all. One of the developers said, “What do you guys study, only figma?” Another one said, “UX means beautiful screens; you guys make our lives tough.”

Then I understood the problem: they need to know the designer’s work and our value in the product life cycle.

I got guidance from my design lead on this problem. We decided to present a session on the role of CX in the product. My design lead conducted this session at one of the upcoming developer events in the USA timezone. (I contributed to the presentation but unfortunately couldn’t present.) The session helped, and I remember everyone talking about the CX presentation from the event. Kudos to P. (He was the design lead and my mentor in the organization.)

3. Office hours

We were three designers working on different parts of the same product. Each team had 10–12 developers, one designer, 1 QA, and 1 product owner.

After analyzing the issue in all three teams, one of my UX colleagues started an office hours initiative. We conducted this session for 30 minutes every Tuesday, and any developer or product owner was welcome to come and talk about design issues, design critiques, processes, and help needed from another team. This session was so fruitful that developers all over teams connected, cross-connected, and utilized similar development components; a lot came out of this session, so we extended it to an hour. On days when we had no agenda, we would give a small talk or a Figma session on any problem, and it would be fun.

One important thing here is our visibility as a designer. As a designer, you create designs and experiences, enhance processes if needed, improve collaboration, and make informed decisions. In the end, it’s the people who come together to make a product successful.

I’ve had some real-life experiences that have taught me the importance of collaboration with developers. I’ve built a better relationship with them by creating guidelines for developers, having 1:1 meetups with them, and setting up office hours. These changes have helped us understand each other’s work and improve the design and product life cycle.

In conclusion, collaboration between designers and developers is essential for creating products that meet users’ needs and expectations. By working together, we can develop better products that significantly impact people’s lives.

I hope some of them will help you. If you want to know more about these, please get in touch with me to discuss this further.

Thank you.