Meridian GRC: Audit Engagement Redesign

Design a GRC audit workflow from PM brief to clickable Figma prototype.

Introduction

30 Second Summary

Internal audit teams at large companies juggle dozens of active reviews at any given time. Without a clear way to see which audits are on track and which are falling behind, managers spend hours every week opening individual records and compiling status updates that are already outdated by the time they hit send.

In this project, you will complete a product design case study for Meridian GRC, a fictional enterprise GRC (Governance, Risk, and Compliance) platform used by internal audit teams. Starting from a PM brief with stakeholder interviews, you'll map the current audit workflow, prioritize which problem to solve, and design a focused solution as a high-fidelity clickable prototype in Figma.

What You'll Build

Picture opening your Figma file in a portfolio review and walking a design interviewer through your complete process, from annotated workflow maps and a prioritization framework all the way to a polished clickable prototype that solves a real enterprise workflow problem.

By the end of this project, you'll have:

A current-state audit lifecycle map you can walk a reviewer through, showing where the workflow breaks down with entity relationships and pain points annotated from stakeholder evidence.
A problem prioritization framework with a testable hypothesis connecting two stakeholder problems, plus HMW statements and concept sketches that document your design thinking process.
A polished, clickable Figma prototype you can demo end-to-end, showing the core solution with realistic audit data and domain-appropriate interaction patterns.
Secret Mission: Design an executive risk summary view that surfaces audit health for leadership reporting.

Are there any prerequisites?

This project assumes you're comfortable creating components, using auto layout, and building prototypes in Figma. If you're new to Figma, complete a beginner Figma tutorial first.

Before We Start

You're about to work through a product design case study for Meridian GRC, a fictional enterprise governance, risk, and compliance platform. Before diving into Figma, let's lock in what you're building and why the process matters.

Set Up Your Figma File and Review the PM Brief

Jumping straight into screens without a structured file leads to disorganized designs and decisions disconnected from real user problems. Every design choice in this case study needs to trace back to stakeholder pain.

In this step, you'll set up your Figma file with a clear page structure, build a lightweight design system, and review the PM brief that defines the problems you'll solve.

In this step, get ready to:

Create and organize a Figma file with four dedicated pages.
Build a design system foundation with status tokens, severity palette, type scale, and reusable components.
Review the PM brief and identify the two priority problems and three stakeholders.

Create your Figma file and organize pages

A case study project needs distinct spaces for each phase of design work. Separating discovery artifacts from wireframes and high-fidelity screens keeps your file navigable for both you and anyone reviewing your portfolio.

In Figma, click the + button in the top left of the toolbar to create a new design file.
Double-click the default file name at the top center of the canvas.
Rename it to Meridian GRC - Audit Engagement Redesign.

Your file starts with one page called Page 1. You need four pages to match the phases of your case study.

In the left panel, double-click Page 1 to rename it to Discovery.
Click the + icon next to the page list header to add a second page.
Name it Wireframes.
Add a third page named Hi-Fi.
Add a fourth page named Prototype.

You should now see four pages listed in the left panel: Discovery, Wireframes, Hi-Fi, and Prototype.

Click the Discovery page to navigate to it.
Press F to activate the frame tool, then click and drag on the canvas to create a frame.
In the right panel under Design, set the frame width to 1200 and height to 800.
Double-click the frame name in the left layers panel and rename it to PM Brief.

Your Discovery page now has a dedicated frame where you'll place the brief content later in this step.

Don't see all four pages?

Make sure you're looking at the pages list at the top of the left panel, not the layers list below it. Each page appears as a separate entry above the layer tree.

Help me find and organize my pages in Figma.

Build your design system foundation

A GRC platform uses color to communicate status and severity at a glance. Building these tokens now means every screen you design later will use consistent, meaningful colors instead of ad-hoc picks.

You'll create three sets of design tokens on the Discovery page: status colors, severity colors, and a type scale.

Make sure you're on the Discovery page.
Create a small colored rectangle on the canvas for your first status color.
Select the rectangle and in the right panel under Fill, click the color swatch and enter #94A3B8.
Click the Styles icon (four dots) next to the fill color, then click the + to create a new color style.
Name this style Status/Draft and click Create style.
Repeat this process to create the remaining four status color styles:

Status/In Progress: #3B82F6 (blue).
Status/Complete: #22C55E (green).
Status/Overdue: #EF4444 (red).
Status/Pending Review: #F59E0B (amber).

Check the Styles icon in the right panel to confirm you see five status color styles listed.

Why color tokens instead of raw hex values?

Color styles let you update a value in one place and have every component using that style update automatically. If a stakeholder asks you to make "Overdue" a darker red, you change the style once instead of hunting through dozens of frames.

Now create the severity palette. These colors communicate how critical a finding is, which is distinct from its workflow status.

Using the same process, create five severity color styles:

Severity/Critical: #DC2626.
Severity/High: #F97316.
Severity/Medium: #EAB308.
Severity/Low: #3B82F6.
Severity/Informational: #6B7280.

Check the Styles panel again to confirm you now see ten total color styles (five status, five severity).

Next, define the type scale. Consistent text sizing keeps your screens polished and readable.

Press T to activate the text tool and type a sample word on the canvas.
Select the text, then in the right panel set the font size to 24 and the weight to Semi Bold.
Click the Styles icon (four dots) next to the text properties, then click + to create a new text style.
Name it Page Title and click Create style.
Repeat to create three more text styles:

Section Heading: 18px, Semi Bold.
Body: 14px, Regular.
Caption: 12px, Regular.

Check the text styles list in the right panel to confirm all four styles appear.

Finally, build two reusable components that you'll use across your screens: a status badge and a severity chip.

Draw a rounded rectangle on the canvas (corner radius around 12px to create a pill shape).
Apply the Status/In Progress color style to its fill.
Add a text label inside it reading In Progress using white text and the Caption text style.
Select both the rectangle and the text label.
Apply auto layout by pressing Shift+A. Set horizontal padding to 12 and vertical padding to 4.
Right-click the auto layout frame and select Create component (or press Cmd+Option+K on macOS or Ctrl+Alt+K on Windows).
Rename the component to Status Badge in the layers panel.

You should see the component icon (four diamonds) appear next to the name in the layers panel. Your status badge is now reusable.

Create a second component for the severity chip using the same approach: a smaller filled rectangle (corner radius around 4px for a tag shape) with the Severity/Critical color style.
Add a white text label reading Critical using the Caption text style.
Select both elements and press Shift+A for auto layout. Set horizontal padding to 8 and vertical padding to 2.
Right-click and select Create component.
Rename it to Severity Chip in the layers panel.

Open the Assets panel in the left sidebar (click the book icon or press Option+2 on macOS or Alt+2 on Windows). You should see both Status Badge and Severity Chip listed as local components.

Components not showing in Assets?

Make sure you used Create component (not Group). Components have a purple diamond icon in the layers panel. Groups have a dotted rectangle icon.

Help me turn my grouped elements into a reusable Figma component.

Review the PM brief and capture key takeaways

The PM brief is the source of truth for every design decision you'll make. It describes a fictional enterprise SaaS platform called Meridian GRC and the problems its users face. Read through it carefully, then you'll summarize your takeaways on the Discovery page.

Here is the full PM brief. Read each section and pay attention to phrases that signal pain points.

Product Context

Meridian GRC is an enterprise SaaS platform used by internal audit teams to manage audit engagements, track observations and findings, assess risks, and monitor corrective actions. The platform currently supports approximately 200 enterprise customers.

The audit management module has not been significantly updated in 18 months. Support ticket volume related to audit workflow friction has increased 40% quarter-over-quarter.

Priority Problems

P1: Audit managers lack clear visibility into overall audit engagement status. They cannot assess which engagements are on track, at risk, or overdue without manually opening each engagement individually.

P2: Auditors experience fragmentation between recording observations during fieldwork and creating corrective actions. These are separate flows in separate parts of the product, causing context loss and delayed remediation.

Stakeholder: Sarah Chen, Audit Manager

"I have six active engagements right now and I cannot tell you which ones are on track without opening each one and scrolling through the findings log. By the time I compile a status update for leadership, the data is already stale. I need to see the health of all my engagements at a glance, not dig through each one."

Stakeholder: James Okafor, Senior Auditor

"When I record an observation during fieldwork, I flag it and move on. But creating the corrective action is a completely separate flow. Different screen, different form. I have to re-enter context that I already captured in the observation. Half the time the CA gets created days later because I forget, and by then the details are wrong or incomplete."

Stakeholder: Maria Torres, Chief Audit Executive (CAE)

"I report audit health to the board quarterly. Right now my team manually assembles a PowerPoint from data they pull from three different views. I want to open Meridian and see a risk-informed picture of where we stand. Which engagements have critical findings? How many corrective actions are overdue? Are we covering the right risk areas?"

Current Workflow Context

Audit engagements follow a lifecycle: Planning, Fieldwork, Reporting, Remediation.
Observations are classified by type: Major Non-Conformity, Minor Non-Conformity, Observation, Opportunity for Improvement (OFI).
Corrective actions track through statuses: Open, In Progress, Resolved, Verified.
Key roles: CAE (executive oversight), Audit Manager (engagement oversight), Senior Auditor / Auditor (fieldwork execution).

The current UI presents audits, observations, and corrective actions as separate list views accessible from a left sidebar. There is no workspace or unified engagement view.

Success Metrics

Reduce time-to-status-update for audit managers (currently ~25 min per engagement).
Increase observation-to-corrective-action linkage rate (currently ~60% of observations have a linked CA).
Reduce mean time from observation creation to corrective action creation (currently ~4.2 days).

Now that you've read the brief, capture your key takeaways in your Figma file.

Switch to the Discovery page in your Figma file.
Inside or next to your PM Brief frame, add a text block summarizing the product context: what Meridian GRC is, who uses it, and the 40% support ticket increase.
Add the two priority problems in your own words, labeling them P1 (audit manager visibility) and P2 (observation-to-CA fragmentation).
List the three stakeholders by name and role: Sarah Chen (Audit Manager), James Okafor (Senior Auditor), Maria Torres (CAE).
Add the three success metrics with their current baseline numbers.
Note any phrases from the stakeholder quotes that jumped out as pain point signals.

Summarize, don't copy-paste

Writing the brief in your own words forces you to process the information rather than passively scanning it. In a portfolio review, you'll need to walk someone through these problems conversationally. Your summary is your first rehearsal.

Before you move on, test whether the brief content actually stuck. Can you answer these two questions without scrolling back up?

What are the two priority problems, and which stakeholder does each primarily affect?
What current metric would improve if the observation-to-CA flow were streamlined?

✔️ I can answer both

Nice. You've internalized the core problems and the data behind them. That understanding will drive every design decision from here.

ⓧ I need to re-read parts of the brief

Scroll back up to the Priority Problems and Success Metrics callouts. P1 is Sarah's visibility gap (25 min per engagement to compile status). P2 is James's fragmentation (60% linkage rate, 4.2-day delay). Maria's reporting pain connects to both.

Update your Figma summary with any details you missed before continuing.

What does the current UI look like?

The brief describes audits, observations, and corrective actions as separate list views behind a left sidebar. There is no unified workspace. This means an auditor recording a fieldwork observation has to navigate to a completely different section to create the corrective action for it.

Keep this architecture in mind. In Step 2, you'll map exactly where these handoffs break down.

Your Figma file is organized, your design system foundation is in place, and you know the two problems you're solving and the people behind them. Next up, you'll map the current audit workflow to see exactly where those problems live in the process.

Map the Current-State Audit Workflow

Your Figma file is structured, your design system foundation is in place, and the PM brief is fresh in your mind. You know the two priority problems and the three stakeholders behind them.

Reading about problems in text does not reveal whether they share a root cause or sit at different points in the workflow. In this step, you'll build a visual map of the current audit lifecycle, diagram how the data entities connect, and overlay stakeholder pain points directly onto the workflow.

In this step, get ready to:

Build a horizontal lifecycle map of the four audit phases with key activities in each.
Diagram entity relationships showing how audit data connects across the workflow.
Annotate pain points from stakeholder evidence onto the diagrams.

Build the horizontal audit lifecycle map

The audit lifecycle has four sequential phases. Mapping them side-by-side reveals where data flows forward and where the process can loop back.

Switch to the Discovery page in your Figma file.
Create a new frame below your PM Brief frame.
Title the frame "Audit Lifecycle Map" using your Section Heading style (18px semibold).
Draw four rectangles in a horizontal row, one for each audit phase.
Label them left to right: Planning, Fieldwork, Reporting, Remediation.

You should see four labeled phase boxes arranged horizontally across your frame.

Inside the Planning rectangle, add four activity labels: "Define scope," "Conduct risk assessment," "Assign audit team," "Create engagement plan."
Inside Fieldwork, add: "Execute test procedures," "Collect evidence," "Record observations," "Classify severity."
Inside Reporting, add: "Compile findings," "Assign severity ratings," "Draft audit report," "Conduct stakeholder review."
Inside Remediation, add: "Create corrective actions," "Assign owners and due dates," "Track status (Open / In Progress / Resolved / Verified)," "Verify closure."

Keep activities visually subordinate

Use your Caption style (12px regular) for the activity labels inside each phase. This keeps them readable without competing with the phase names for visual weight.

Draw forward arrows connecting each phase to the next: Planning to Fieldwork, Fieldwork to Reporting, Reporting to Remediation.
Add a dotted return arrow from Remediation back to Fieldwork.

Why the return arrow?

When a corrective action is verified during Remediation, the verification may uncover new issues that send the engagement back into Fieldwork. This feedback loop is a critical part of the audit lifecycle that purely linear diagrams miss.

Your lifecycle map should now show all four phases with their activities, forward arrows connecting them in sequence, and a dotted return loop from Remediation to Fieldwork.

Map looking cramped or cluttered?

If the activities crowd the phase rectangles, stretch them taller or arrange the activities as a vertical list within each box. Make sure your phase labels use the Section Heading style so they stand out from the smaller activity text.

Help me lay out my lifecycle map

Diagram the entity relationships

The lifecycle shows the sequence of work, but it does not show how the data objects relate to each other. An entity relationship diagram maps the connections that the product either supports well or leaves broken.

Below your lifecycle map, create a new section titled "Entity Relationships" using your Section Heading style.
Draw four entity boxes and label them: Audit Engagement, Observation/Finding, Risk/Control, and Corrective Action.

Now connect the entities with labeled lines that show how data flows between them.

Draw a line from Audit Engagement to Observation/Finding and label it "contains" with a 1-to-many cardinality notation.
Draw a line from Observation/Finding to Risk/Control and label it "tests" with a many-to-many cardinality notation.
Draw a line from Observation/Finding to Corrective Action and label it "generates" with a 1-to-many cardinality.
Add attributes to the Corrective Action box: owner, due date, status, and priority.
Mark the line between Observation/Finding and Corrective Action as a dashed or red line to indicate this is the broken connection in the current product.
Add a note next to the dashed line indicating which connections exist in the current product and which are weak or manual.

What does the broken link reveal?

The PM brief tells you that observations and corrective actions live in separate flows. Your entity diagram makes the consequence visible: only 60% of observations have a linked corrective action, and the average gap between creating an observation and creating its corrective action is 4.2 days.

That dashed line is not just a diagram notation. It represents the exact fragmentation that James Okafor described in his interview.

Your entity relationship diagram should now show four connected entities with labeled cardinality lines. The observation-to-corrective-action connection should be visually distinct as the broken link.

Not sure how to show cardinality?

A simple approach is to write "1" and "*" (or "many") at each end of the connecting line. For the many-to-many connection between Observation/Finding and Risk/Control, write "*" on both ends. This does not need to follow formal UML notation. Clarity matters more than convention here.

Help me diagram entity relationships in Figma

Overlay pain points from stakeholder evidence

The diagrams show the structure. Now you need to show where it hurts. Red annotation callouts placed at specific workflow touchpoints connect the abstract pain points from the PM brief to concrete locations in the lifecycle.

Create a red callout shape using your Overdue color (#EF4444) for the background or border.
Place it at the gap between the Audit Engagement entity and the individual Observation/Finding entities in your entity relationship diagram.
Label it with Sarah Chen's initials (SC) and annotate: "No way to see engagement health without drilling into each one."
Create a second red callout.
Place it on the handoff between the Fieldwork and Remediation phases in your lifecycle map.
Label it with James Okafor's initials (JO) and annotate: "Observation recording and CA creation are disconnected flows."

Two of the three stakeholder annotations are placed. Sarah's marks the engagement-level visibility gap. James's marks the fieldwork-to-remediation handoff where context is lost.

Create a third red callout.
Place it at the output of the Reporting phase in your lifecycle map.
Label it with Maria Torres's initials (MT) and annotate: "Manual compilation from three views for board reporting."

The stakeholder quotes are qualitative evidence. Now add the quantitative data points from the PM brief to reinforce what the numbers say about the broken link.

Add a red annotation near the dashed observation-to-CA link in your entity diagram: "4.2-day avg delay from observation to CA creation."
Add another annotation near the same link: "Only 60% of observations have a linked CA."

What does the clustering tell you?

Notice where the annotations land. James's fragmentation pain point and both quantitative data points all cluster around the same handoff: the observation-to-corrective-action connection. Sarah's visibility problem sits upstream at the engagement level. Maria's reporting problem sits downstream at the output level.

This spatial clustering is the kind of insight that only emerges from mapping. You could not see it from reading the brief alone.

Before you zoom out to assess your full Discovery page, consider: based on the annotations you placed, do the two priority problems cluster around the same workflow handoff, or do they sit at different points in the lifecycle?

Zoom out to see your complete Discovery page. You should see three distinct artifacts: a horizontal lifecycle map with four phases and a return arrow, an entity relationship diagram with four entities and a visually marked broken link, and at least five red annotation callouts placed at specific workflow touchpoints.

Annotations feel disconnected from the diagrams?

Use connector lines or arrows from each red callout to the exact point on the diagram it references. The spatial connection between the annotation and the workflow touchpoint is what makes the map useful for later prioritization.

Help me connect my pain point annotations to the workflow

Your workflow map is complete, and you can see exactly where each problem lives in the audit lifecycle. Next up, you'll use this evidence to prioritize which problem to solve first and frame a focused design challenge.

Prioritize Problems and Frame the Design Challenge

Your Discovery page now maps every friction point in the audit workflow back to real stakeholder evidence. The entity relationship diagram reveals which data connections are fragmented in the current product.

A portfolio case study cannot tackle every problem on the map. Scoring both problems against stakeholder data may reveal that the obvious surface-level fix would not address the root cause if the underlying data flow is broken. Structured prioritization forces that discovery before you commit to a solution direction.

In this step, get ready to:

Plot both priority problems on an impact/effort matrix using stakeholder evidence.
Form a testable hypothesis about how the two problems relate.
Write two HMW statements to frame focused design challenges.

Create the impact/effort matrix and plot both problems

An impact/effort matrix maps each problem's user impact against the effort required to fix it. Problems that land in the high-impact quadrant deserve your focus first.

On the Discovery page, create a new frame below your pain point annotations.
Title the frame "Problem Prioritization" using the Section Heading style (18px semibold).
Inside the frame, draw a large 2x2 grid.
Label the X-axis "Solution Effort" with Low on the left and High on the right.
Label the Y-axis "User Impact" with Low at the bottom and High at the top.

Your empty matrix should now have four clear quadrants. Next you will plot both problems onto it using evidence from the PM brief to justify where each one lands.

How do I score each problem?

For impact, consider how many users are affected, how frequently the problem occurs, and its measurable cost. Sarah spends 25 minutes per engagement compiling status. James faces a 4.2-day average delay between observation and CA creation. Only 60% of observations have a linked corrective action.

For effort, consider how many workflow touchpoints a solution needs to change. Does it require building new data connections, or can it work as a new view on existing data?

Plot P1 ("Audit managers lack visibility into engagement status") as a labeled point on the matrix.
Next to the P1 point, write a short scoring rationale for your impact and effort scores using specific data from the PM brief.
Plot P2 ("Auditors experience observation-to-CA fragmentation") as a labeled point on the matrix.
Next to the P2 point, write a short scoring rationale for your impact and effort scores using specific data from the PM brief.

Step back and look at where each problem landed on the grid. Your rationale should reference specific data points (the 25-minute status compilation time, the 4.2-day delay, the 60% linkage rate) rather than general impressions.

Both problems landed in the same spot?

If both problems feel identical in impact and effort, revisit your effort scoring. P1 (visibility) may only need a new aggregated view on existing data, while P2 (fragmentation) requires changing the data flow between observations and corrective actions. That difference in structural complexity should shift their horizontal positions.

Help me figure out where to plot each problem on the matrix.

Form a hypothesis about how the problems connect

The PM brief presents P1 and P2 as separate issues. Your workflow map from Step 2 may tell a different story. Look at where your red callouts cluster to discover whether these problems share a common root or stand alone.

Return to your annotated audit lifecycle map from Step 2.
Examine where the red callouts cluster. Do both problems trace to the same workflow handoff? Does solving one depend on solving the other?
Below the impact/effort matrix, create a text block titled "Hypothesis" using the Section Heading style (18px semibold).
Write a single statement in this format: "We hypothesize that [relationship between problems], because [evidence from the workflow map]."
Below the hypothesis, add a note listing what evidence would confirm it and what evidence would invalidate it.

What makes a good hypothesis?

A hypothesis is a testable proposition, not a confirmed root cause. It connects what you observed in the workflow map to a specific claim about the problem structure.

A strong hypothesis makes a falsifiable prediction. If you test it during concept exploration and discover you were wrong, that is still valuable analytical work for your case study.

Review your hypothesis on the canvas. The statement should reference a specific pattern from the workflow map, not a generic assumption about the problems being related.

Write two HMW statements to frame the design challenges

HMW (How Might We) statements translate problems into design challenges. The altitude matters. Too broad and the statement gives you no direction. Too narrow and it prescribes a solution before you have explored alternatives.

What is the right altitude for an HMW statement?

Too broad: "How might we improve auditing?" This could mean anything. It gives you no design direction.

Too narrow: "How might we add a Kanban board for corrective actions?" This prescribes a specific UI pattern before you have explored alternatives.

The right altitude names the user, the core tension, and the desired outcome without prescribing a specific screen or pattern. The statement should be specific enough to inspire concrete solution ideas and broad enough to leave room for exploration.

Below the hypothesis, create a text block titled "Design Challenges" using the Section Heading style (18px semibold).
Write HMW statement 1, anchored to P1 (audit manager visibility). Name the user (audit manager), the core tension (cannot assess engagement health without manual effort), and the desired outcome.
Write HMW statement 2, anchored to P2 (observation-to-CA fragmentation). Name the user (auditor), the core tension (context loss between observation and corrective action creation), and the desired outcome.

Test your HMW altitude

Read each statement and ask: can I sketch at least three different solutions to this? If only one solution comes to mind, the statement is too narrow. If the statement could apply to any product, it is too broad. Rewrite until you can picture multiple distinct approaches.

Place both HMW statements prominently below the hypothesis. These will drive your concept exploration in the next step.

Before you zoom out to review the full Discovery page, ask yourself: do your HMW statements feel specific enough to generate concrete solution sketches, or could they apply to any GRC product?

Zoom out on the Discovery page. You should see your 2x2 impact/effort matrix with both problems plotted and justified, a one-sentence hypothesis about their relationship with confirmation criteria, and two HMW statements that name the user, the core tension, and the desired outcome without prescribing a UI pattern.

HMW statements feel too vague?

Check that each statement names a specific user role (audit manager, auditor), not "users" or "the team." The core tension should reference a concrete pain point from the PM brief, not a generic improvement goal.

Help me sharpen my HMW statements for the Meridian GRC case study.

Your Discovery page now has the analytical foundation for a defensible design direction. Next up, you will sketch multiple solution concepts on the Wireframes page and select the strongest direction to prototype.

Explore Solutions and Select a Direction

Your Discovery page now tells a complete analytical story. You mapped the audit workflow, annotated where it fragments, and framed two focused design challenges with HMW statements.

Jumping straight to polished screens would skip the most important portfolio artifact. Interviewers want to see that you explored multiple structural approaches and selected a direction with documented rationale, not just the final answer.

In this step, get ready to:

Sketch 2-3 structurally different concept approaches on the Wireframes page.
Evaluate each concept against three stakeholder-grounded criteria.
Select one direction and define the minimum screen set for prototyping.

Sketch low-fidelity concepts on the Wireframes page

Each concept needs to represent a genuinely different structural approach to your prioritized problem. If your sketches look like variations on the same layout with minor rearrangements, they are not different enough.

Switch to the Wireframes page in your Figma file.
Create a new frame for your first concept. Name it with a label and a one-line description of its core structural idea (e.g., "Concept A: Unified Engagement Workspace").
Inside the frame, sketch the concept using rectangles for screen areas, text labels for content zones, and arrows for navigation flow. No colors, no components, no polish.

Zoom out on the Wireframes page. Your first concept frame should be visible with a rough layout inside it.

Create frames for one or two more concepts, each with a structurally different approach and its own one-line description.

✔️ I'll give it a go!

Go for it. Pull from your HMW statements and the workflow map on your Discovery page. Think about what structural pattern would best address the core tension each statement names.

ⓧ Maybe a little help...

Here are three structurally different directions to consider. Each one solves the problem from a different angle.

Unified engagement workspace: A single tabbed view that embeds observations, findings, and corrective actions within the engagement context. Inline CA creation happens right from the observation, so the auditor never leaves the workspace.
Dashboard-first with drill-down: A summary view shows all engagement statuses at a glance. Clicking into an engagement reveals its observations and CAs. The dashboard surfaces the "health" view the audit manager is missing.
Guided sequential flow: A wizard-style pattern walks the auditor through observation recording and CA creation as connected steps. Each observation ends with a prompt to create the linked corrective action before moving on.

You can use these as starting points, combine elements from multiple patterns, or sketch something entirely different.

Zoom out on your Wireframes page. You should see 2-3 distinct concept frames side by side, each with a one-line description and a rough layout sketch inside.

Concepts looking too similar?

If your sketches feel like the same screen with elements shuffled around, step back and ask: does each concept propose a different information architecture? One should organize content by engagement, another by status or risk, another by workflow step. The structure should differ, not just the layout.

Help me think of structurally different approaches to my prioritized problem.

Evaluate each concept against three criteria

Your HMW statements and stakeholder evidence from the Discovery page are the measuring stick. Each concept needs to earn its place against the same three questions.

Below or beside each concept frame, add a text element with three evaluation lines, one per criterion.
For criterion (a), rate pass, partial, or fail: Does it directly address the prioritized problem with evidence from the stakeholder data?
For criterion (b), rate pass, partial, or fail: Does it integrate into the existing audit workflow rather than creating a parallel flow?
For criterion (c), rate pass, partial, or fail: Is it achievable as a focused prototype with a small number of screens?
Write a short justification next to each rating explaining your reasoning.

Why should a concept fall short?

At least one concept should score partial or fail on criterion (a) or (b). A concept that looks appealing but does not address the root problem is exactly what structured evaluation is designed to catch.

This is part of the case study artifact. A portfolio reviewer wants to see that you explored a direction, tested it against evidence, and ruled it out. That is stronger than only showing the winner.

Review your annotations across all concepts. You should see pass, partial, or fail ratings with justifications for each criterion, and at least one concept that clearly falls short.

Select a direction and define the minimum screen set

The evaluation did the heavy lifting. Now you need to commit to one direction and scope what you will actually prototype.

Identify the concept that scored highest across all three criteria.
Draw a circle or colored border around the selected concept frame to visually mark it as your chosen direction.
Below the selected concept, add a text element with a 2-3 sentence rationale. Explain why this concept scored highest and what trade-offs you are accepting by choosing it over the alternatives.

Your selected direction now has a visual marker and a written rationale. The last piece is scoping the prototype.

Create a new frame on the Wireframes page titled "Minimum Screen Set."
Inside it, list each screen by name. Next to each name, write a one-line description of that screen's purpose.
Draw arrows between the screen names showing the user flow from one screen to the next.

How many screens is enough?

A focused prototype typically needs 3-5 screens to demonstrate one complete user flow. Enough to show the end-to-end experience, but not so many that you are rebuilding the entire product.

Each screen in your list should have a clear reason to exist. If you cannot explain what the user accomplishes on a screen in one sentence, the screen is either too broad or unnecessary.

Before you do a final review, think about what a portfolio reviewer would look for on this page. What artifacts show your design thinking process?

Zoom out on your Wireframes page. You should see 2-3 concept sketches with evaluation annotations, one concept visually marked as the selected direction with a written rationale, and a Minimum Screen Set frame listing each screen with purpose descriptions and flow arrows.

Missing pieces on the page?

Make sure every concept has all three criteria rated, not just the winner. The rejected concepts with their documented shortcomings are just as important as the selected direction.

Check that your screen set has arrows showing the flow. A list of screen names without connections does not communicate how the user moves through the experience.

Help me refine my concept evaluation and screen set for a GRC audit engagement redesign.

Your Wireframes page now documents the full exploration journey from multiple ideas to one focused direction. Next up, you will bring that direction to life as a polished, clickable prototype with realistic GRC data.

Build the High-Fidelity Prototype

Your concept sketches and evaluation from the Wireframes page proved that your selected direction works structurally. You have a circled concept, a rationale, and a defined screen set. Now it is time to turn that skeleton into a polished, interactive prototype that a portfolio reviewer can click through.

A high-fidelity prototype does two things that wireframes cannot. It demonstrates design craft through consistent use of your design system tokens. It also proves domain understanding through realistic GRC data, proper empty states, and interaction details that show you understand how auditors actually work.

In this step, get ready to:

Build polished 1440px screens on the Hi-Fi page using your design system tokens and realistic audit data.
Add interaction details like empty states, status transitions, and contextual corrective action creation.
Wire the complete prototype flow on the Prototype page and verify it end-to-end in present mode.

Build polished screens with realistic GRC data

The difference between a wireframe and a portfolio-ready screen is not just visual polish. It is the data inside the design. Generic placeholder text tells a reviewer you designed shapes. Realistic audit names, finding types, and corrective action details tell them you understand the domain.

Switch to the Hi-Fi page in your Figma file.
Open the Wireframes page in a second tab so you can reference your minimum screen set while building.
For each screen in your minimum screen set, create a new frame on the Hi-Fi page set to 1440px wide (Desktop viewport).
Apply your design system tokens consistently across every screen: use your status badges for engagement and corrective action statuses, severity chips for finding classifications, and the type scale for all text elements.

What counts as realistic GRC data?

Realistic data means using names, types, and values that an actual audit team would recognize. Populate your screens with content like:

Audit engagement names: Q3 SOX Compliance Review, IT Access Controls Audit FY26, Vendor Risk Assessment - Cloud Services.
Observation types: Major Non-Conformity, Minor Non-Conformity, Observation, Opportunity for Improvement (OFI).
Corrective action statuses: Open, In Progress, Resolved, Verified.
Real-sounding owners and due dates: Assigned to: R. Patel, Due: 2026-09-15, Priority: High.

Populate each screen with this kind of realistic data. Avoid generic placeholder text like "Audit 1" or "Finding A."
Maintain consistent spacing, alignment, and component usage across all your screens.

Zoom out on your Hi-Fi page to see all your frames side by side.
Confirm that every screen uses the same type scale, color tokens, status badges, and severity chips from your design system. If any screen has mismatched fonts or hand-picked colors instead of your tokens, fix those now.

Screens look inconsistent?

Check that you are using component instances of your status badges and severity chips, not detached copies. Select a badge, and in the right panel confirm it shows the component name with an instance indicator. Detached copies do not update when you change the source component.

Also verify your text is using the defined type scale styles rather than manually set sizes. Select any text element and check that a style name appears in the Text section of the right panel.

help me fix inconsistent design tokens across my Hi-Fi screens

Add interaction details that demonstrate domain understanding

Polished screens with real data show visual craft. Interaction details show that you have thought about how the product actually behaves. These details are what separate a static mockup from a design that an engineer could build from.

Add empty states with guidance text to any screen or section that could start with no data. For example, an observation list with no entries yet should show text like: No observations recorded yet. Start fieldwork to begin.
Design clear status transition affordances. Show how an auditor moves a corrective action from In Progress to Resolved. This could be a dropdown, a button, or a contextual menu. The affordance must be visible and unambiguous.

Why surface corrective action creation within the observation context?

James Okafor's core pain point from the PM brief is that creating a corrective action is a completely separate flow from recording an observation. He has to re-enter context he already captured.

By surfacing a "Create Corrective Action" action directly within the observation context, you eliminate that context switch. The CA form can pre-populate with details from the observation, reducing the 4.2-day delay and improving the 60% linkage rate.

Add a contextual Create Corrective Action action surfaced within the observation context. This should appear as a button or action link on an observation detail, not as a separate navigation path in the sidebar.
Use progressive disclosure for complex data. Instead of navigating to a full new page for every entity detail, use a detail drawer or expandable row that keeps the learner in context while revealing deeper information.

Review your Hi-Fi page and count how many of these four interaction details you have included: empty states, status transition affordances, contextual CA creation, and progressive disclosure.
You should have all four present across your screens. Each one addresses a specific pain point or workflow gap from the PM brief.

Not sure where to place empty states or drawers?

Return to your entity relationship diagram on the Discovery page. Any entity that appears as a list within another entity (observations within an engagement, CAs within an observation) is a candidate for progressive disclosure. Any list that starts empty during the audit lifecycle needs an empty state.

help me decide where to add empty states and progressive disclosure in my GRC audit screens

Wire the prototype flow and test it end-to-end

A collection of polished screens is not a prototype until a reviewer can click through them. Wiring the flow means connecting every interactive element so someone can experience the audit workflow as a continuous journey, not a slide deck.

Switch to the Prototype page in your Figma file.
Duplicate all your Hi-Fi frames onto this page. Select all frames on the Hi-Fi page, copy them, and paste them onto the Prototype page.
Arrange the duplicated frames in the order of the flow you defined in your minimum screen set.

Switch to the Prototype tab in Figma's right panel.
Connect every interactive element (buttons, list rows, navigation items, action links) to its target screen by dragging a prototype connection from the element to the destination frame.
Ensure every interactive element either advances the flow, opens a detail view, or returns the user to the previous context. No element should lead to a dead end.

Keep back-navigation consistent

Detail views and drawers should always have a way to return to the parent screen. Add a close button, back arrow, or click-outside interaction to every overlay or drill-down. A reviewer who gets stuck on a detail screen will question whether you thought through the full flow.

Before you test the prototype, think about what you expect to happen. Can you click from the first screen all the way through to the end of the workflow without getting stuck? Are there any screens you are not confident are fully connected?

Click the play button (Present) in the top right corner of Figma to launch present mode.
Click through the entire core audit engagement workflow from the first screen to the last.
At each screen, try every clickable element. Confirm that it either navigates forward, opens a detail view, or returns you to the previous screen.

You should be able to walk through the complete workflow without hitting any dead ends. Every button, row, and action link should respond with a transition to the expected screen.

Hitting dead ends in present mode?

Press Escape to exit present mode. Select the element that did not respond and check the Prototype tab in the right panel. Verify that a connection line goes from that element to the correct destination frame.

If the connection exists but does not work, check whether the element is nested inside a group or auto layout frame. You may need to set the interaction on the child element rather than the parent container.

help me debug dead ends in my Figma prototype

Secret mission

Design the Executive Risk Summary View

Maria Torres reports audit health to the board quarterly, but her team manually assembles a PowerPoint from data pulled across three different views. Your challenge is to design an executive risk summary screen that surfaces audit program health for CAE-level reporting. This means shifting from operational detail to strategic summary, aggregating data across engagements into risk-informed KPIs that Maria can present directly.

Clean Up Your Resources

This project runs entirely inside Figma, so there are no cloud resources, servers, or ongoing costs to worry about. Decide whether to keep your case study file as-is, archive it, or delete it entirely.

Resources you used:

Figma file: Meridian GRC - Audit Engagement Redesign (four pages: Discovery, Wireframes, Hi-Fi, Prototype).
Design system components (status badges, severity chips, color tokens, type scale) stored within the Figma file.

Keep everything running

No action needed. Choose this if you plan to continue refining your case study, adding more screens, or polishing the prototype for portfolio presentations.

Your Figma file stays in your recent files and drafts. There is no cost to keeping it.
Consider moving the file into a dedicated portfolio project in Figma to keep your workspace organized.

Pause - I'll come back to this later

Archive the file to keep your Figma workspace tidy while preserving your work.

Right-click the Meridian GRC - Audit Engagement Redesign file in your Figma file browser.
Select Move to project and move it into a folder you use for paused work, or leave it in drafts.
Your file, design system tokens, and prototype connections are all preserved. You can pick up exactly where you left off.

Delete - I don't want to use this again

Remove the Figma file entirely. This deletes all pages, components, and prototype connections.

Right-click the Meridian GRC - Audit Engagement Redesign file in your Figma file browser.
Select Delete.
The file moves to your trash. Figma keeps deleted files in trash for 30 days before permanent removal.

Nice Work!

You just completed a full product design case study for Meridian GRC, going from a PM brief all the way to a polished, clickable Figma prototype. This is the kind of structured, evidence-driven work that stands out in portfolio reviews and design interviews.

You've learned how to:

Mapped a current-state audit workflow with entity relationships and stakeholder-grounded pain point annotations, turning a PM brief into a visual diagnostic of where the process breaks down.
Prioritized design problems using an impact/effort matrix, formed a testable hypothesis, framed HMW statements, and evaluated multiple concept sketches before selecting a direction with documented rationale.
Built a high-fidelity, clickable Figma prototype with realistic GRC data, domain-appropriate interaction patterns, and an end-to-end flow a reviewer can walk through without dead ends.
Completed an optional Secret Mission to push your case study further with a leadership-audience lens on the audit data.

Ready to quiz yourself?