8–10
Auditors across roles, seniority levels, and three countries involved throughout the process
00Overview
Auditing large and complex organizations is a multi-phase process governed by ISA standards, but those standards define what must be done, not how. In practice, audit firms fill that gap with a patchwork of tools: Excel workbooks, proprietary templates, and specialized software, each covering a different slice of the process. Auditors piece their work together across these disconnected systems with no shared structure and no single source of truth. At a firm the size of Cedra, where auditors operate at different seniority levels, carry different responsibilities, and each have their own preferred ways of working, that fragmentation compounds. Every team, every office, every auditor follows their own approach.
Cedra set out to change that by building a unified auditing platform: one tool where auditors of every role and level of seniority can carry out the full audit lifecycle, from understanding the client entity and assessing risk, through planning and executing procedures, to internal review, sign-off, and closure. The platform needed to bring structure and consistency to a firm where none existed, while remaining flexible enough to support audits of varying scale and complexity. This project covers the UX design of that platform, across its most foundational and complex modules.
01Challenges
Designing a unified platform for a fragmented, multi-role audit environment surfaced challenges that went beyond the interface:
01
No consistent pattern of working. Across the firm, auditors had deeply different preferences, habits, and workflows. Without a shared baseline to design from, every decision required judgment calls backed by research rather than existing conventions to follow.
02
Conflicting stakeholder expectations. Management on the client side pushed for heavy automation and AI-driven flows. Auditors pushed back, arguing that the legal weight and financial scale of audit decisions made human control non-negotiable. Bridging that gap without compromising either side was a core design tension throughout the project.
03
Key processes were manual and untraceable. Risk assessment and audit planning were done inconsistently across individuals and offices, with no structured connection between decisions, financial data, and procedures. Building traceability into a system where none had existed before required designing new logic, not just new screens.
04
Tight project timeline. The scope was large and the complexity high, which meant design decisions had to be made quickly, validated continuously, and kept aligned with development in parallel.
02Solution
The platform covers the full audit lifecycle in a single tool. Auditors begin with ISA 315, documenting their understanding of the client entity: the business model, internal controls, fraud considerations, and key processes. As they work through this phase, any identified risks can be assessed directly in context. When they move into the formal risk assessment and planning phase, those risks are pre-populated, already connected to the relevant financial statement lines and their related assertions. From there, auditors define the procedures that respond to each risk, assign ownership, set timelines, and can request any missing documentation directly from the client, all within the same environment.
The result is a fully traceable chain: from business understanding through risk, to procedures, to execution. Nothing lives in a spreadsheet, nothing is carried across manually.
End-to-end audit workflow — from entity understanding through to final reporting, all within a single connected platform.
Three distinct roles interact with the platform. Each role enters a tailored default view that surfaces exactly what they need to act on, without requiring them to navigate to it.
Design Principles
Clarity across roles and levels. The platform had to be equally usable by a junior performer and a signing auditor. Every flow, every screen was designed to be understood without prior knowledge of how the tool works, because expecting users to learn a new system on top of a complex domain was not realistic.
Suggestions, not decisions. Rather than automating decisions, the system makes intelligent suggestions based on context: materiality benchmarks based on financial data, likely risks based on financial statement lines, related procedures based on identified risks. Auditors review and confirm. The legal and financial stakes of auditing made it clear that the system earns trust by informing, not by taking over.
Domain before design. With no established patterns to follow, the only way to make good decisions was to deeply understand the domain first. That meant studying ISA standards, running continuous workshops with auditors, and synthesizing what real users needed rather than applying generic UX conventions to a space that didn't fit them.
03Process
01
Domain immersion before design
Before sketching anything, I spent significant time learning the domain from scratch. I had no prior knowledge of auditing or ISA standards, so the first step was reading: understanding what ISA 315 requires, how the audit process unfolds from the initial KYC phase through to sign-off, and how auditors think about risk, materiality, and evidence. Only once I had enough grounding to hold a meaningful conversation with real auditors did I move forward.
Key decision
Invest in domain knowledge before touching any design work.
Why
Designing for a regulated, high-stakes domain without understanding it produces solutions that look right but don't work in practice.
02
Listening before proposing
I began working with a group of eight to ten auditors across different roles and offices in Sweden, Norway, and Denmark. The early sessions were deliberate listening exercises: no solutions, no wireframes, just understanding how each person currently works and where the friction sits. The key finding was that there was no consistent pattern to design from. Every auditor operated differently, and each country had its own rules around areas like tax auditing, which would later require adapted flows for those specific sections.
Key decision
Work with a cross-role, cross-office group from the start rather than a single representative user.
Why
A solution shaped around one auditor's preferences would have failed the rest. The diversity of the group was the point.
03
Two-tier testing loop
Once I had enough to start proposing, the team established a two-tier rhythm for testing and feedback. Online daily sessions were used to walk auditors through wireframes section by section, gathering reactions and catching issues in individual flows before they compounded. Once a month, the whole group came onsite for a full-day session where they could interact with the prototype themselves and move through the entire audit flow end to end. The distinction mattered: section-level feedback needed focused, low-stakes conversations. Full-flow feedback needed the whole group, a working prototype, and enough time to surface the connections and gaps between steps.
Key decision
Separate section-level testing from full-flow testing rather than running both in the same sessions.
Why
Testing everything at once obscures whether a problem is local to one screen or a symptom of how the whole flow is structured.
Early wireframe from the risk assessment flow, used in section-level testing sessions with the auditor working group.
04
Drawing the line on automation
Throughout the project there was real pressure from management to build a highly automated, AI-driven platform. Auditors pushed back, and their argument was grounded in professional responsibility: at the end of every audit, it is the auditor who signs their name and closes the year. The legal and financial stakes made full automation not just undesirable but wrong for this context. The design decision was deliberate and principled: AI and smart suggestions belong in the product, but every consequential action requires human confirmation. The system informs. The auditor decides.
Key decision
Position AI as a suggestion layer, not a decision-making layer.
Why
When the person using the system carries legal responsibility for the output, removing their agency is not a feature. It is a liability.
05
Solving the navigation problem
The most complex design challenge was risk assessment and planning. The data was inherently layered: financial statement lines sit at the top, each carrying associated risks, each risk requiring an audit response and one or more procedures. Auditors needed to navigate between lines, see current and prior year values side by side, assess risk in context, and define procedures, all without losing sight of the overall picture. They also needed access to the materiality assessment from within this flow, because materiality thresholds directly inform which risks matter.
The structural answer was a financial statement overview as the anchor: all FS lines visible at once with their current and prior year values. From there, auditors drill into any line to assess risk, document their rationale, select their audit response, and define procedures, either from a library, from prior year, or custom. Every action stays connected to the line that triggered it, so the audit record remains traceable throughout.
The role dimension added another layer. A performer arriving in the system wanted their task queue. A signing auditor wanted to see what awaited their signature. A reviewing auditor wanted to see what needed their review. The solution was role-aware entry points into the same connected data, not separate flows, but different default views of a single audit record.
Key decision
Use a hierarchical FS line overview as the navigation anchor rather than a flat task list.
Why
Auditors think in terms of financial areas, not abstract tasks. Organising the experience around FS lines mirrors how they already think about risk.
The traceability chain — every procedure is connected back to the assertion, FS line, and risk that justified it.
06
Validating for legal correctness, not just usability
A critical part of working with this group was recognising that auditor feedback served two distinct purposes: usability and legal accuracy. A flow that felt intuitive could still be wrong if it didn't align with how ISA standards require a specific step to be documented or sequenced. The auditors were the legal domain experts, and testing with them was as much about confirming correctness as finding friction. This was especially true for country-specific sections, where tax auditing rules differ across Sweden, Norway, and Denmark, and the design needed to reflect those differences in the flow itself.
Key decision
Treat legal validation as a design requirement built into every testing cycle, not a sign-off at the end.
Why
Getting the logic wrong early would have meant redesigning entire flows later under greater time pressure.
04Key features
01
Entity understanding (ISA 315)
When a new client is onboarded and passes KYC, auditors begin by documenting their understanding of the entity: business model, working area, employment, financial situation, fraud risk, and internal controls. For returning clients, prior year documentation is reused as a starting point and updated where the business has changed. At any point during this phase, auditors can flag potential risks directly in context, creating a continuous thread between understanding and assessment.
Impact
Replaces unstructured documentation with a guided, ISA-aligned record that directly feeds into risk assessment.
Entity understanding interface — auditors document business context, internal controls, and flag risks directly in context.
02
Financial data import and smart mapping
Auditors import financial data (quarterly, half-year, or annual) and map accounts to financial statement lines. For first-time clients this is done manually. For returning clients, the system offers smart mapping based on the previous year's mapping or the BAS control plan, a standard account structure template, significantly reducing the manual effort involved.
Impact
Turns raw financial data into structured, mapped input that becomes the foundation for materiality calculation, risk assessment, and planning.
Financial data import and mapping interface — accounts are mapped to FS lines using smart suggestions or manually.
03
Materiality assessment
Once financial data is mapped, auditors calculate materiality and select the benchmark that will guide the rest of the audit. The system suggests the appropriate benchmark and threshold based on the mapped financial data, giving auditors a recommended starting point while preserving their ability to review and override it.
Impact
Speeds up a typically manual calculation and ensures consistency in how materiality thresholds are set across the firm.
04
Risk assessment and planning
The core of the platform. Auditors see all financial statement lines with current and prior year values side by side. Drilling into any line opens the risk layer: auditors assess risk across multiple dimensions, document their rationale, select their audit response, and define the procedures that follow. Procedures can be pulled from a library, carried over from the prior year, or created from scratch. Each procedure is assigned to a team member with a planned timeline and a list of required client documentation. An overview panel keeps the full risk picture visible throughout, showing the distribution of risk levels and outstanding procedures across the entire audit.
Impact
Replaces fragmented, manual risk documentation with a connected, traceable system where every risk links to a financial area, an assertion, and a procedure.
Risk assessment interface — FS line overview with the drill-in panel showing risk levels, assertions, and linked procedures.
05
Internal review workflow
A multi-role review system where completed work is submitted for preliminary or final review. Reviewers can comment, approve, or return work with feedback. Final approvals lock the relevant steps, with controlled reopening available if needed. Each role arrives at a tailored view of the same audit record: performers see their task queue, reviewers see what is pending their input, and signing auditors see what awaits their signature.
Impact
Replaces informal sign-off processes with a structured, traceable workflow that mirrors real audit team accountability.
05Impact
Despite a tight timeline and a domain that required learning from scratch, the engagement moved faster than the client expected. Auditors who had been sceptical early on engaged actively by the later stages, and the client expressed genuine surprise at the pace and quality of progress given the complexity of what was being designed. The work established a solid UX foundation for a platform that had not previously existed in any structured form.
3
Full-day onsite workshops run with the complete group across the engagement
4
Core audit modules designed end-to-end, covering the full audit lifecycle
06Learning
L1
You cannot design for everyone, and trying to will produce a product that works for no one
Working with a group of auditors who each had different habits, preferences, and ways of working made it clear early on that the goal was not consensus. If every preference had been accommodated, the result would have been an incoherent product that satisfied no single user well. The designer's role is to listen to everyone and then make a decision, one that is grounded in research, domain knowledge, and a clear point of view about what the product needs to be.
Next step
As more modules are built and tested in real use, continue validating that the decisions made hold up across the broader user base, not just the working group.
L2
Designing in a regulated domain means becoming a practitioner of that domain, not just its interface
Coming into this project with no background in auditing or ISA standards, the biggest shift was realising that good UX decisions here were inseparable from domain understanding. It was not enough to know how to design a form or a flow. The structure of the logic, the sequence of steps, the relationships between data, all of it had to reflect how auditing actually works, legally and professionally. Domain knowledge was not preparation for the design work. It was part of the design work.
Next step
Apply domain knowledge proactively in upcoming modules rather than reactively, using what has already been learned to anticipate complexity before it surfaces in testing.
L3
Holding a principled design position under conflicting stakeholder pressure requires both evidence and confidence
The tension between what management wanted and what auditors needed was real and sustained. The temptation in that situation is to find a compromise that makes both sides quieter rather than a solution that is actually right. What made it possible to hold the line on decisions like AI as a suggestion layer was having a clear rationale grounded in the domain: auditors carry legal responsibility for the audit, which means removing their control is not a shortcut to efficiency. It is a risk. Evidence gives the designer the standing to hold that position even when the pressure to do otherwise is high.
Next step
Document design rationale more explicitly and earlier in the process, so that when stakeholder pressure increases, the reasoning is already written down and shareable rather than reconstructed under pressure.
If I were starting this project again, I would push for domain immersion sessions with auditors even earlier, before any design work began. The time spent learning ISA standards independently was necessary, but some of the most valuable understanding came from conversations with the working group. Getting into those conversations sooner would have compressed the learning curve and given the design work a stronger foundation from the start.