AuditBoard
Three shared surfaces across five risk products. One shared foundation.
I spent four years at AuditBoard shipping three risk products from zero: TPRM, ESG, and ORM. Each new team rebuilt the same assessment, object page, and hierarchy its own way. I made the bet that those three surfaces should become shared primitives instead of five redesigns, and ran the alignment across five risk teams.
Challenge
Customers using multiple risk products saw a different assessment in every module. Same company, same risk data, different surfaces. Engineering rebuilt the same primitives at least three times.
- Assessment
- Single view for both admin and respondents.
- Object page
- Lack of info architecture and layers of stacked accordions.
- Taxonomy
- Flat hierarchy. Risk scores could not roll up.
Process
Before redesigning anything, I had to answer one question: could one assessment model work across five risk verticals? I sat in on customer research calls, joined sales on prospect demos, and met with internal SMEs. Risk teams built their programs around frameworks (enterprise, operational, third party, ESG) to meet regulatory requirements, with assessments as a core mechanism.
Assessments are the one surface touching every risk vertical and every customer role. The call I made was to build the new assessment as a shared component from the start, not as a one-off for the product in front of me.
The design system team argued for one pattern across every product in the company. I scoped mine to the risk verticals. The broader you go, the more generic the solution gets, and that became an alignment challenge.
I treated the shared model as a hypothesis. If five verticals needed different assessment logic, then it would nullify my hypothesis. The research tested whether a shared surface should exist. I spoke to customers in five different verticals who described the same problem with assessments.
Solution
Customers using multiple risk products saw five versions of the same core objects. I consolidated those into three shared surfaces: assessments, object pages, and hierarchies.
The shared assessment component
The spreadsheet served managers and left other roles working around it. I replaced it with a schema-driven form: templates with question types, conditional logic, attachments, and a formula layer for the risk score.
The respondent experience was the bigger redesign. We retrofitted features onto the spreadsheet as a stopgap while the new assessment was built in parallel.
I redesigned the respondent experience as a simple form, with a navigation pane for moving between sections and focusing on one question at a time.
“Department heads already see risk management as a burden, similar to compliance training. The spreadsheet made it more challenging.”
The component shipped as a shared schema and two separate views for managers and respondents. Five products used it, four risk and one audit. The shared design system grew from pairing sessions.
Aligning five risk products on a shared object page
Five risk product teams were each replacing the long-scroll object page, which had grown by accordion accumulation over years. I pushed for one shared pattern instead.
Pairing sessions with product managers and engineers produced a shared structure of tabs and nested sections. Every object type across every risk product rendered from the same template, with modules choosing which tabs to show.
- I led
- Alignment across five risk products, pairing sessions, contributed to shared design system coherence.
- I didn't lead
- Tabbed and section content for each module. Each designer owned how their team used the shared template.
A risk and entity hierarchy
Risks and entities were stored as flat types, though every customer's program ran on a hierarchy. Parent risks contained child risks, entities contained sub-entities, severity rolled up from children. Neither hierarchy was supported.
I designed the hierarchy for enterprise risk first. Scores rolled from level 4 risks up through parents to the owning entity, so severity reflected live risk state instead of a static field.
We tested with seven customers. The integrated view landed, but every customer raised permissions. Our cascading-permissions assumption missed the shared-risk case across business units. Customers wanted sibling views. The pattern extended to operational risk.
Impact
By end of 2024, five risk products were building on the same assessment and object-page foundation.
The convergence happened in pieces. The assessment pattern landed in one product, migrated into another, and became the default as new modules were created.
An insurance customer deal stalled for months on the old assessment. It closed once sales showed the new version.
Reflection
Stay with one team before generalizing. The pattern came from solving one domain fully before abstracting anything.
The temptation at every step was to generalize early, to design the shared component for all the products that might eventually need it instead of for the team in front of me.
The other risk teams argued that each team should just ship their own patterns. That works if customers only use one product. Ours used multiple risk products together, so they saw the inconsistencies in every workflow that crossed products.