Respect Does Not Mean Skipping Review

I start development from a design, then find myself asking the designer questions once I am already writing code.

How should this screen work on a narrow display? Is this value different from the existing component on purpose? What should guide the implementation when the design system does not cover this case? I need answers to keep working, but they are not decisions I can make on my own.

We clarify something and update the design. I add a style override to fit it to an existing component. Then QA reviews the screen. Sometimes a decision that was never made becomes visible, or a temporary implementation does not match the design. I ask again and make another change.

One omission can be a mistake. Everyone misses things. I do too when I write code, and someone else often catches it in review.

But when the same kind of issue shows up on the next task, I start asking different questions.

Should we stop after fixing this screen? Could we ask the same question earlier next time?

What frustrated me was not that the design was imperfect. It was that we kept postponing the work of finding gaps until development was already under way.

“Everyone is busy” did not explain enough

In the environment I worked in, one designer supported two development teams. The design standards and final decisions belonged to a separate organization, and developers on the team could not change those standards on their own.

I understood the designer’s situation too. They were preparing the next work for two teams while answering questions about screens already in development and handling fixes from QA. When a request did not fit the existing design system, they also had to seek decisions they could not make themselves.

Telling one designer to be more careful does not solve a gap that appears under those conditions. Asking someone who already has too little time to pay more attention does not give them more time to do the work.

Still, understanding the situation did not make me comfortable with leaving the process as it was.

The checks skipped because there was too little time for design still had to happen during development. When a developer asked a question, the designer had to stop and answer. If QA found an issue, we had to change code that was already written and check the updated screen again.

Skipping a check during design did not make the work disappear. In my experience, several people in development and QA had to check and correct things later.

I could understand the choice to implement a rough version first to keep a schedule. Sometimes we have to lower the level of finish or defer a decision. But we should also know what we are deferring and what rework we are accepting because of it.

If that cost stays invisible, work that moved quickly at first can leave developers making repeated fixes later.

I try to wait before blaming a person for the problem. I want to look first for something we can change about the way the work is done.

The first question I wanted to ask was not who had done a bad job.

Why were we waiting until development began to resolve these open questions?

Rechecking what was already decided

The existence of a design system made that question harder to ignore.

If we already have shared components and standards, I think we should be able to reuse them for repeated patterns. We should not have to reinterpret the size or spacing of an existing button on every screen, then add a code exception just to bring it back in line.

Of course, a design system cannot define every screen.

Buttons and input fields do not settle a complex workflow. We may still need to decide how a table should appear on a narrow screen, which feature should be most visible, or what to do when an existing rule does not cover the situation.

I know there are challenges in design that I do not see. A developer’s view—“just use the component”—cannot explain the whole process.

That is why I wanted to distinguish between two kinds of work:

Where a new decision is needed, and where an existing decision needs to be applied correctly.

When a design differs from an existing standard, we need to know whether the exception was intentional or something was missed. If the design system has no rule for the case, it should be clear who will decide. If no decision has been made yet, that should be visible too.

Could we check these things once before handoff instead of asking developers to discover and investigate them while implementing the design?

I was not expecting every design problem to be solved by copying and pasting an existing component. I wanted to avoid spending time rechecking things that had already been decided.

Respecting expertise is not the same as waiving review

In development, we explain how we plan to implement something and have the work reviewed.

We share the approach, how it affects existing code, and the risks we expect. After writing the code, someone else reads it and asks questions. They check for missed conditions, whether the standards were followed, and whether the design will be difficult to change later.

I do not think that process disrespects a developer’s expertise. Even expert decisions need an explanation, and their author can miss something another person sees.

Shouldn’t design have a corresponding review?

We could explain which existing standards apply, where a new decision is needed, and what has been checked before handing the work to development.

As I was thinking about this, I found a statement I wanted to keep:

Respect design expertise and decision-making authority. Then check whether existing standards were followed, what remains undecided, and whether the work is ready for development. Just as code receives review, design deliverables should be reviewed too.

I am not asking for the authority to make design decisions.

I am not saying developers should make the final call about good or bad design, or change the user experience because a different option is easier to implement. The people who hold that authority should decide the direction and any exceptions.

Review should not spread a decision across so many people that no one owns it. Every task needs a final decision-maker. The DRI (Directly Responsible Individual) leading the work should gather the input and review findings, decide what to do, and own the execution and outcome.

Having a DRI should not prevent people from asking questions. Having several reviewers should not blur responsibility either. Reviewers surface missing evidence and risks. The DRI decides whether to accept them or make an exception, then records why.

The person who picks up that decision and implements it still needs to be able to ask questions.

Asking why a design differs from a standard, what behavior is undecided, or whether the information is enough to start is not a challenge to authority. It is part of knowing what the work requires.

Developers should not have to take over every basic design check just because they participate in review. A code review does not replace the author’s own checks, and a review of implementation feasibility should not replace the designer’s self-review.

There are things each person should check and things we should check together. I wanted those boundaries to be clearer.

A checklist still leaves decisions to make

That is why I started thinking that design needs a work plan, a checklist before handoff, and the necessary approvals.

I was not imagining a long report. It might be enough to show which existing components apply, what still needs a decision, and whether another group needs to confirm something.

After the work is done, the review could check whether existing standards were applied correctly, whether the necessary screen sizes and states were defined, and whether exceptions and open questions were called out.

We do not need to draw every case from scratch. When an existing rule is enough, we can point to it. The important thing is not how many screens there are, but whether the next person knows what to follow.

But a checklist can become one more task for the designer if we stop there.

If the review shows that something is not ready, who needs to do what next?

If a design decision is needed, the DRI responsible for that work should answer and own the result. If one person cannot support the needs of two teams, we should adjust priorities. If a decision the current task depends on will not arrive in time, we should talk again about scope or schedule.

If we still have to deliver the same scope on the same schedule regardless of what the checklist finds, marking an item as undecided will not change the situation. The developer and designer will end up filling in the gaps during implementation again.

The review I want is not just a process for finding a gap and sending it back to someone. It should give us a way to make a decision and adjust the work in response to what we find.

I am not saying all development should stop until every design is perfect. We can make progress on work that does not depend on an open decision. But that is different from promising to deliver an interface whose behavior is not decided and leaving the remaining judgment to whoever implements it.

Once this process is in place, I think developers could spend less time asking the same questions and revising the same screens.

Making development easier is not a bad outcome. I want to reduce repeated checks for the same omissions, not the collaboration the work actually needs.

I am not saying we should stop asking designers questions. I do not want us to start from the same questions again on the next task.

Faster coding with AI does not remove the open questions

AI makes this issue more visible to me.

I am interested in writing code faster and getting more work done efficiently. But the more I focus on implementation speed, the more I think about what needs to be decided before implementation begins.

Imagine asking AI to turn an ambiguous design into a convincing screen. The fact that a screen exists does not mean the missing decisions have been approved.

We still need to decide what to hide on a narrow screen, whether a value can differ from the design system, and whether an interaction fits the product’s intent. AI can fill in a blank, but that does not give it the authority to decide what belongs there.

AI is more useful here as a consistent first check against agreed criteria than as a decision-maker. It can check whether a required state is missing, whether a value differs from an existing component, and whether open questions are marked—regardless of who is doing the work.

Just as a code review tool can surface failing tests and rule violations before a person conducts the final review, an AI finding should start a conversation. We can explain why an exception is needed and revise the standard if the standard itself is wrong.

The same standard applies to me as a developer. AI writing the code does not remove my responsibility to explain the implementation or review the result.

That is why I do not think AI adoption and handoff standards are separate issues. If we gain the ability to build faster, we should also look at how we check what we are building.

If writing code takes less time but asking about undefined behavior and rebuilding it take just as long, that is not the kind of productivity I want.

This time, I want to improve the handoff too

I cannot yet say what effect this process would have. What I have written is not a proven success story. It is what I want to try after seeing the same problems recur.

If we put it into practice, I would look for fewer questions during development, not just a higher checklist completion rate. I would also want to know whether QA raises fewer late decisions and whether the designer spends less time repeating the same explanation between two teams.

If review takes longer and rework does not go down, we should change the process again. I do not want to say that we improved just because we created a process.

When frustration builds, it is easy to focus on people: Why wasn’t this checked? Why does the same thing keep happening? I do not want to pretend I never feel that way.

But the question I want to stay with is different.

Instead of waiting for someone to be more careful, what can we change about the way we work now? Can we stop leaving the check for existing standards and the list of open decisions to an individual’s spare time or personality?

I do not think respecting someone’s expertise means never asking about their work. It means understanding one another’s decisions and sharing the explanations and checks the next person needs to carry on.

I will have to revise screens again. This time, I also want to look at the handoff that made me revise them, instead of only fixing the code.

Review will reveal different standards and create friction. The next question is how to keep that friction from living only in someone’s mood and memory.

Next: Friction Should Become Part of the System →