Document Manager

The challenge

Document Manager needed a significant UX overhaul across four workstreams: approval workflows, notification rules, a completed and approved view, and document referencing and category management, all within tight sprint timelines.

At the same time, the company was rolling out a major overhaul of its design system, moving to a new shadcn based library with the help of AI. That left designers in a period of limbo: the components we would normally design with were still being built, so it was not always clear what we could safely rely on.

My role and team

I was embedded in a pillar team as its designer, working alongside a product owner, a QA, a lead developer and three senior developers. I worked most closely with my product owner. We ran a weekly PO and UX sync to check in on work in progress and, just as importantly, to plan and prioritise the work for upcoming sprints.

Being part of one stable team meant we could keep improving how we worked together, which mattered a great deal during the design system transition.

Designing while the system was in flux

With the component library still being built and deadlines tight, I needed a fast way to show design ideas, so I started prototyping in Figma Make. It worked well at first, but two limitations surfaced. The developers would sometimes find that the exact component I had shown did not yet exist, and Figma Make does not let you leave comments, so I had no clean way to gather feedback.

To close the feedback gap, I would present the prototype live and also export the screens into a Figma file where the whole team could comment.

The review process we built

Out of that we shaped a review loop that worked: an initial design review with my product owner, then a QA review, then a presentation to the developers. Comments came back, I iterated, presented again, and the design was usually signed off after two passes.

The feasibility pivot

The completed and approved view is where this was tested. When I presented the designs, the developers judged them unfeasible in the time we had. Rather than lose the sprint, we pivoted to a simpler interim solution and changed our process, which we discussed at the sprint review.

We added a quick design feasibility check, where I shared some of my ideas with the developers earlier in the process, before the designs were fully worked up. That one change cut a lot of risk out of the later stages.

How the tooling evolved

Figma Make helped early on, but as the work grew it became too slow, and after each change it would lose memory or parts of the prototype would shift. Once the shadcn library was in place and our modernised app had been moved onto it, using AI, I could design screens in Figma again. That worked far better, because there was no longer any ambiguity about which components existed.

What I delivered

• Approvals: a multi stage approval setup with per stage approver rules, self approval prevention and a validation modal for bulk actions.
• Notification rules: the add and edit workflow for triggers covering on change, on approval and on both, including all the help text.
• Completed and approved view: a feasible interim design, plus the earlier feasibility check that came out of the pivot.
• Component migration: moving the designs onto the new library and documenting the patterns for the team.

Outcome

• All four workstreams delivered on schedule.
• The feasibility check became a standard step in our process, cutting late stage rework.
• The review loop, product owner then QA then developers, became a repeatable rhythm with sign-off in two passes.
• The team moved to sharing designs earlier and in lower fidelity, which reduced surprises at handover.

Reflection

The biggest lesson here was about process, not screens. Designing during a live design system migration meant the ground kept shifting under us, and what kept us productive was a stable team that improved its own way of working as it went.

Being embedded in a pillar, with a weekly product owner and UX sync and a review loop we refined together, meant each problem we hit made the next sprint smoother. That is the real advantage of working as part of a pillar team.