This is part of a Design in Agile series. Here I try to tackle How should final design approval work in an agile organization?
Ideally it’s serial and linear. PM/PO write requirements. These include design by designers or PM. PM approves. Developers give the OK. Then we build it. But, practically, the process can be non-linear, iterative and messy.
Specifically, say a product manager has a new feature that also involves UI additions. Say it’s a proactive PM with a high level of UX/UI knowledge, and the UI changes are relatively small. So the PM creates a mock-up on her own. Then the design team can review, make changes or proposals to PM. If research and validation has to happen, then cool. The PM can approve. Then it needs to go to the dev and is soon in production. This is ideal. Simple, right?
Reality, though, is a bit more messy. But the messiness is where the magic happens. Some reasons for that beautiful mess:
- Changing product definitions due to customer research, formal or informal feedback
- Lack of back-end support for UI design
- Unforeseen front-end development complexity
- Unforeseen edge case
- Changed scope
- Human error
Reasons final design approval is not actually final.
- Changing product definitions. the initial idea and requirements can and do change. Why? Because learning happens, and more data leads to a better solution.
- Customer research. For example, based on customer research. Maybe a customer — including UI or not necessarily — and provided critical feedback that the solution is insufficient or wrong for some reason. This is OK, and good. Since the feature requirements have to be changed, the UI also has to be changed to reflect that. So, that means that even though the design may have been approved, it needs to be re-approved. Another reason the product definition changes can be based on changing strategic decisions. For example, even if the local feature/product is immaculate, a larger decision that impacts the entire product line or feature line may have shifted. And it could have repercussions for the local feature/product. Like if your feature is muffins, and the supplier changes the flour supplier, then the new muffin recipe may need to be tweaked.
- Formal feedback. ‘Black hat’ sessions, usability studies customer tickets or other events of collecting feedback that are conducted can shed light on problems with design that we were not previously aware of.
- Informal stakeholder feedback. Same idea as above, but could be another stakeholder reviewed the proposed solution. Like someone from customer delivery. Or sales/pre-sales. Or another PM. From Devs. Even after approval, when handoff to developers happen, sometimes developer will suggest a better way to do it. While this is annoying for the designer and PM who have to re-define and re-design, it’s actually awesome for the product, and ergo the PM and designer. Of course, ideally all relevant stakeholders review the solution earlier, to minimize these changes, but scheduling and coordinating feedback in medium to large organizations is not always an easy and straightforward feat.
- Lack of back-end support. It could be that the proposed UI solution that has been approved, is not actually easy to support in terms of back-end development. This could happen for several reasons:
- Misunderstanding. The designer(s) involved, and sometimes even the PMs, can misunderstood the API behavior. This shouldn’t happen, but it does. The decision-makers then have to decide whether to change the BE in order to supported desired UI, or to adapt the UI in order to support the BE functionality that has already been developed.
- Errant API documentation. This can be related to the point above but doesn’t have to be. Sometimes the API documentation is flawed, so the front-end design based on API documentation will not work. Like the designer(s) and PMs thought that there was API support to look up EntityTypesABC.properties123 based on API calling EntityType.Def. But actually, there is no way to get properties123 of EntityTypesABC from the id of EntitityType.Def. Yikes.
- Change in architecture HLD or LLD or data model. Sometimes even after approval of UI design, the BE design changes, and requires the UI design to change. Like, it was a bit more tricky to implement the BE design the way initially planned, so a decision was made to do the easy low-resource Backend solution. But, alas, this means that the approved UI solution is no longer supported. Back to the design drawing table.
- Unforeseen front-end development complexity. The UI developers thought it was feasible, and it turns out to be more complex than anticipated.
- Unforeseen edge case. Sometimes only when developing you realize that your design or requirements did not cover a critical use case. This can throw everything off.
- Changed scope. This is clearly a PM no-no. But say an urgent customer requirement or support request comes in. And we have limited resources for both FE and BE development. So this sometimes means that the UI design will pay the price, and be forced to find a lower-dev-cost temporary design workaround. These temporary design work-arounds have a way of becoming permanent, unfortunately.
- Human error. Sometimes the PM or other decision-maker simply overlooked part of the solution. The solution was never really sufficient, though it was approved. Or, the PM changed her mind upon ‘second glance’. This happens, because PMs are also humans. And this can also indicate growth and product maturity. A solution that seemed appealing is no longer sufficient, because it for some reason now shows its ugly inelegance, that it managed to hide before. Indeed, the human brain is not capable of noticing everything always, and we do a lot to filter out noise. Sometimes we filter out too much, and notice it later.
What to do when you have to re-design, re-approve?
First, don’t get too emotional. Remember that it’s actually good for the product. And remember that it is NEVER personal (or shouldn’t be). Once that is settled, there are a few options for how to move forward. Selecting the best option depends on when the re-approval needs to happen, the amount of work necessary to re-design/re-define, and the urgency (to get to customer, or to provide work for developers).
Option 1 — Start over. This means go through all the phases necessary previously for initial approval. Have the same meeting as before, with same stakeholders, etc. This can be painstaking, and requires patience and usually time.
Option 2 — quiet small-group approval. This usually involves a small meeting with few people, or even an email, stating the new design or proposal is approved. It needs to be documented wherever the requirements are, so if this is done in a chat or one-on-one meeting, or in email, make sure the record gets to the place of official source of truth. Because if it doesn’t, there is going to be ambiguity and frustration. ‘But you said it was OK if we…’ You want to avoid these hearsay broken-telephone historical re-enactment conversations. It’s a drag and timesuck for all involved.
Option 3 — change nothing now, and create new story/task for change later. This option favors consistency over correctness. This literally means you are OK with developing something you know needs to be changed. Sometimes it’s the right call though, if requiring a change will be extremely disruptive and throw off the timeline, and if you can live with the errant design until later when you have resources and time to fix it.
Conclusion & Recap
We’ve explored some reasons designs need to be approved again and again. We discussed some options we have when this happens (and it does!). In terms of mindset, this can be frustrating, but should be embraced as an opportunity for improvement.
Thanks for reading.
About this Series
This is an article in a series on Design in Agile based on my experiences.
About the Author
I’m a UX Designer turned Product Manager, with experience in startups, freelance, and international B2B companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.
