Case study / Risk management
Assessing and reviewing company risks
The platform helps teams assess company risks and monitor the work around them. I brought the owner, assessment, history and related objects around one risk record so a later review does not require reconstructing its context from separate lists.
01
Problem
Teams regularly review risks: what could go wrong, which responses are in place and what needs attention. A risk owner needs the current assessment and its supporting context before continuing the review.
The old module split the register, assets and ongoing work into separate lists. A single assessment required its context to be reconstructed. I redesigned the module around a risk record, connecting its owner, assessment, history and affected objects.
An asset can be a system or another company resource. A control is a measure used to manage risk. Links to them explain the assessment’s context; they do not, by themselves, prove that the risk has been reduced.
02
Research
Product goal
Keep the context for the next assessment
Give a risk owner a clear record for understanding the current situation and preparing the next review. My task was to distribute information between the register, detail page and shared objects.
In interviews, I worked through the most recent risk assessment: where information came from, how the responsible person was found and what was checked on the next visit. I then compared the old lists with those actions.
Scenario walkthroughs asked people to choose a risk, find its owner and affected asset, and compare the profile with its history. I checked which information belonged in the register and which helped explain one record.
- Participants
- 6
- 3 risk owners, 2 risk specialists and 1 auditor.
- Walkthrough rounds
- 2
- The same tasks on early and revised screen structures.
I focused on restoring assessment context. Risk specialists remained responsible for the calculation method and the effectiveness of the controls themselves.
- Interviews
- Assessment walkthroughs
- User journey map
- Scenario reviews
- Record-structure comparison
I checked the record structure against risk-management guidance. These sources helped distinguish the risk description, responsibility and response from the numerical assessment itself.
NIST: register and detail record
NIST uses the register for a concise assessment and response, with a detailed record for affected objects and context. I used that distinction for the list and risk detail.
ISO 31000: reviewing risk
ISO treats risk management as an ongoing process of assessment, treatment and review. I kept the owner, history and access to related work beside the profile.
03
Insights
Status does not explain priority
Two open risks may need different levels of attention. I added residual assessment, alerts and treatment to the register so it could support choosing a record to review.
BasisSelection needs the risk level with responses considered, not just an Open label.
An assessment needs context
A number alone does not identify who owns a risk or which objects it affects. I brought the owner, profile and history together while retaining links to objects.
BasisA later review needs information that helps examine an assessment, not only its result.
A link is not protection
A zero count makes an asset with no risk mappings visible. A link does not establish that controls work, so I kept mapping information separate from the risk assessment.
BasisRecord completeness and the condition of the risk answer different questions.
04
Jobs and hypotheses
I separated intended process benefits from questions that could be checked in the interface.
Business hypotheses
Less repeated context gathering
If the risk profile, owner and related objects are accessible from one record, registration and initial assessment will take less time because the starting information will not need to be gathered again.
- Basis
- Recurring context had to be gathered from separate lists.
- How I tested it
- I compared median registration and assessment time before the update and two quarters later. No change would require examining where repeated work remained.
Direction supported
The median fell from 22 to 9 minutes. This describes the updated process as a whole; the interface’s separate contribution was not isolated.
Design decision
I kept a risk record with its context and a shared catalogue instead of repeating information in each table.
Visible mapping completeness
If related objects and missing mappings are visible in the working context, more risks will have a recorded control or asset link.
- Basis
- A completed description alone does not identify which object a risk concerns.
- How I tested it
- I compared the share of records with at least one control or asset link in two register snapshots. A link still needed a content check; its presence was not treated as risk reduction. If the share had not increased, I would have reconsidered how missing mappings are shown and how an object is found.
Record completeness increased
After two quarters, the share was 88%, up from 31%. It measures the presence of links, not their quality or control effectiveness.
Design decision
I showed related objects in the profile and mapping counts in the catalogue.
Interface hypotheses
Choose a risk before opening its detail
If assessment, alerts and treatment appear beside status, an owner will be able to explain which risk to review without opening every record.
- Basis
- Open appears on risks with different assessments and work states.
- How I tested it
- I asked people to choose a record needing attention and justify it from the row. The answer had to use assessment and context rather than status alone. A choice based only on status would have meant revisiting the cues in the row and how they were presented.
Supported in walkthroughs
Assessment and alerts became the basis of the second-round choices. Status was no longer the only reference point.
Design decision
I kept concise selection cues in the row and the detailed profile in the record.
Assessment context in one place
If the owner, profile and history appear together, people will be able to find the responsible person, affected asset and changes in the assessment without reconstructing them from separate lists.
- Basis
- A risk owner and asset owner may have different responsibilities. Review also needs history rather than only the current number.
- How I tested it
- I asked people to name the risk owner, identify a linked asset and find changes in history. A chart alone could not establish the cause of a change. If people confused the owners or could not find the context, I would have reconsidered the role labels and information placement.
Supported in walkthroughs
Participants found responsibility and context in the risk detail. They used the catalogue to clarify the object and distinguished the risk owner from the asset owner.
Design decision
I kept the risk owner in the header, profile beside history and asset responsibility separately in the catalogue.
05
User journey
The map follows a risk owner preparing a review: choosing a record, restoring its context and deciding what needs further attention.
- Role
- Risk owner
- Situation and goal
- Restore the risk’s context and decide what to examine during its review.
-
Choose a risk
- Goal
- Identify a record to review.
- Actions and touchpoints
- Checks the list and clarifies what needs attention.Register / colleagues
- Difficulty
- Status does not explain differences between open risks.
- What they need
- Compare assessment and treatment context.
- My decision
- Showed residual assessment, alerts and treatment in the row.
- Screens
-
Understand the record
- Goal
- Restore the risk’s meaning.
- Actions and touchpoints
- Reads the description and checks the current assessment.Risk detail
- Difficulty
- A score alone does not explain the context.
- What they need
- Compare the assessment with its description.
- My decision
- Placed the profile beside assessment and history.
- Screens
-
Clarify responsibility
- Goal
- Know who to involve.
- Actions and touchpoints
- Finds the risk owner and people responsible for the object.Risk detail / catalogue
- Difficulty
- Risk and asset owners represent different responsibilities.
- What they need
- Distinguish responsibility for the risk and object.
- My decision
- Risk ownership appears in the header; asset Owner/Custodian in the catalogue.
- Screens
-
Check affected objects
- Goal
- Find the affected asset’s context.
- Actions and touchpoints
- Compares the record with the catalogue and its mappings.Profile / catalogue
- Difficulty
- Repeated names do not prove that records are linked.
- What they need
- See the object and presence of relationships.
- My decision
- Showed related objects and mapping counts in the catalogue.
- Screens
-
Compare changes
- Goal
- See assessment changes over time.
- Actions and touchpoints
- Compares the current state with history.Profile / history
- Difficulty
- Without history, a change in value is harder to notice.
- What they need
- Find a change without inventing its cause.
- My decision
- Placed history beside the risk profile.
- Screens
-
Check the overall picture
- Goal
- Decide what needs further attention.
- Actions and touchpoints
- Returns to the list and compares the record’s state.Risk detail / register
- Difficulty
- One risk’s context needs to be considered alongside others.
- What they need
- Check assessment, alerts and treatment in the list.
- My decision
- Kept the same meaningful cues in the register.
- Screens
History shows changes in values, not their cause. An asset link provides context without proving that controls are effective.
06
Interface decisions
The risk record became the centre of the review. The register helps choose a record, while the catalogue and library preserve shared context for reuse.
Choose a risk to review
The register keeps the first-decision cues: residual assessment, status, alerts and treatment. People compare records before opening the detail and decide which deserves attention.
Restore assessment context
The header identifies the owner and current state. The profile sits beside history, with tabs for tasks, indicators, issues and exceptions. One risk remains the centre of the review without becoming an endless form.
Work with shared objects
I separated object types in the catalogue and showed their risk-mapping counts. The library keeps titles, categories and descriptions for recurring risks, giving the team a shared starting point for new records.
Screens by stage
Choose a screen or scroll the row. Open any design to inspect the full screen.
07
Design validation
Two rounds of scenario walkthroughs checked how people chose a risk, restored its context and explained mappings. I examined the reasoning behind an answer, not only whether an element was found.
Open does not mean most important
- Difficulty
- A shared status does not explain which of several risks to review first.
- What I changed
- I placed residual assessment, alerts and treatment beside status. The choice can be explained from the row.
Risk owner and asset owner
- Difficulty
- One Owner label is not enough: responsibility may concern the assessment or the affected object.
- What I changed
- The risk owner remains in the risk header. The catalogue identifies the asset’s Owner and Custodian separately.
Mapped does not mean protected
- Difficulty
- A mapping count could be mistaken for completeness or effective treatment.
- What I changed
- The catalogue reports relationships; the risk detail keeps the assessment and history. These indicators do not replace one another.
08
Results
I brought the owner, profile, assessment and history around one risk record. The register helps choose it for review; the catalogue shows mapping context. The library preserves a shared starting point for recurring descriptions.
I presented the route from selecting a risk to checking its related objects in two team design reviews. The first covered how information should be divided between the register, detail and catalogue. After refining the structure, I secured agreement in the second review and handed over the states and display rules.
Two quarters after rollout, the updated process was compared with the previous one. Working practices changed alongside the interface, so the figures describe a combined outcome rather than design’s isolated effect.
- Register and assess a new risk
- Previous process22Two quarters later9min 13 minutes less
- Median time from starting registration to completing the initial assessment. This is one new-risk operation, not a full audit or later reviews.
- Risks linked to a control or asset
- Previous process31%Two quarters later88%+57 percentage points
- Risks with at least one control or asset link divided by all risks in the reporting snapshot. Each risk is counted once.
- Reviews completed on time
- Previous process61%Two quarters later80%+19 percentage points
- Reviews completed by their deadline divided by all reviews due in the reporting window. Unfinished overdue reviews remain in the denominator.
Time compares medians; shares compare percentage-point differences. A link does not establish its correctness or reduced risk, and timeliness does not establish review quality. These measures describe different parts of the process and cannot be added into a single efficiency gain.
