Draftit
Role and responsibility
At Draftit, I took on a broad product design role spanning research, interaction design, prototyping and visual direction. My scope went beyond delivering screens, I worked with stakeholders and developers to define which problems were worth solving, not just how to solve them.
The platform served municipalities managing legally sensitive case workflows. That context meant every design decision had to balance usability improvement against regulatory integrity and real technical constraints. I acted as the bridge between user needs, business goals and engineering feasibility.
The problem
The brief was to modernise an incident reporting system running on paper.
The real problem, uncovered in early workshops, was different.
Administrators weren't failing to manage cases, they were failing to see them. Cases sat unresolved for months not because of bad process, but because the tool gave no overview. Nobody could tell what was open, what was stuck, or what needed attention today. The system held the data. It just never surfaced it.
The objective became: build a dashboard where the answer to "what do I need to do right now?" is visible within three seconds of opening the page, without clicking anything.
Final production
Final production
The outcome was a modernised and more cohesive platform experience that improved clarity without oversimplifying domain complexity.
The redesigned dashboard shifted from passive information display to actionable overview. Case officers gained clearer visibility into workload distribution, case status and prioritisation.
Navigation became more structured and predictable. Key workflows required fewer steps, and visual consistency reduced cognitive load across modules.
Most importantly, the platform became better aligned with how users actually worked, not just how the system was originally structured.
The process
Discovery
The discovery phase focused on understanding the actual structure of case officers' daily decision-making, not just their stated frustrations, but the sequence of questions they needed to answer every morning.
Through workshops and stakeholder sessions, we identified the core systemic failure: the tool was a passive archive. It stored cases. It never prioritised them. Critical and overdue cases were invisible unless someone manually searched for them. Dashboard metrics existed but were built around data categories, not user decisions.
The most important insight was that efficiency for these users wasn't about speed. It was about reducing the mental overhead of operating inside a legally complex process with no clear signal of where to focus.
Define
We translated insights into four design principles, then used them to evaluate every structural decision:
Support decision-making, not documentation — every component should answer a question, not just display a number
Minimise context switching — critical information should surface without requiring navigation
Strengthen visual hierarchy — priority and status should be impossible to miss
Design for scalability — patterns that support the product's future, not just its current state
The most consequential structural decision was to invert the conventional case management layout. Most tools of this type open with a table, which puts the user in a list of 80 items with no context. I reversed that deliberately: context first, detail second. The table becomes the endpoint of an informed scan, not the starting point.
The dashboard is structured in four layers, each answering a progressively more specific question:
Is anything on fire? — the alert banner, visible only when something is overdue
What's the overall state? — four stat cards: Critical, Pending, In Progress, Resolved
Where is the pressure? — the chart row: school load, case volume trend, status breakdown
What specifically needs action? — the case table and quick actions panel, reached only after full context
A decision worth explaining: the alert banner
There was a reasonable argument for handling overdue cases through a filter in the case table, a more conventional pattern that adds less visual weight. The problem: it requires the user to know to look for the problem. The banner removes that dependency entirely. In a legally time-sensitive workflow where a missed case has real consequences, proactive surfacing isn't a convenience, it's the point.
Finalization
During finalisation, the work shifted to system coherence and implementation precision. Working closely with developers, we aligned component logic with technical constraints, ensured consistency across modules, and maintained accessibility across data-heavy views. The result wasn't a visual refresh, it was a structural rebuild of how the platform supports daily decision-making.
Outcome
The redesigned platform shifted from passive information display to actionable overview. Case officers gained immediate visibility into workload distribution, case status and prioritisation, without having to navigate, filter, or mentally reconstruct the system state from disconnected screens.
Navigation became more structured and predictable. Key workflows required fewer steps. Visual consistency reduced cognitive load across modules. Most importantly, the platform became aligned with how administrators actually work, not with how the system was originally structured.
Improved efficiency in high-frequency administrative workflows
Reduced cognitive load in legally complex processes
Scalable UI patterns established for future development
Platform shifted from functional archive to active decision-support system
Reflection
If I were doing it again, I'd have pushed for a structured observation session in the first two weeks, watching administrators work in the existing system before running any workshops. The workshops gave us the language of the problem. Direct observation would have given us the texture of it faster.