Prototype Client Onboarding Automation

Map and prototype a client onboarding flow with safe exception handling.

Introduction

30 Second Summary

Sending company information for review can feel simple until one document is missing. Follow-up emails pile up while the client waits without a clear status.

In this project, you will redesign a fictional US commercial-client onboarding flow as a compact case study. You will use human-centered design to shape safe exception handling for the automated flow.

What You'll Build

A stakeholder can follow your case study from manual handoffs to a clickable prototype that routes an incomplete packet to human review.

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

A presentation-ready current-state service map that makes manual handoffs visible. You can point to each owner plus the two pain points.
A future-state service blueprint you can trace from automated completeness checks to human exception review. Its Given, When, Then acceptance criteria support a prioritized MVP slice.
A three-screen clickable Figma prototype that carries stakeholders from validation to the missing signer authorization exception.
Secret Mission: Add a request-update and resubmission loop so the client can correct an incomplete submission.

Are there any prerequisites?

You need a Windows device with internet access. Some Agile experience is helpful.

Before We Start

Before any mapping or prototyping begins, lock in the user problem that guides every decision in this project. Your goal is to reduce manual onboarding handoffs while preserving human judgment when an exception needs review.

Set Up Your Design Workspace

Your problem statement is locked in. Now you need a verified browser so setup friction does not interrupt the work.

A current Microsoft Edge browser will host the workspace. A free Figma Starter account provides FigJam for mapping plus Figma Design for prototyping.

In this step, get ready to:

Verify Microsoft Edge compatibility.
Create a free Figma Starter account for the fictional case study.
Prepare the named mapping and prototype drafts.

Verify Microsoft Edge compatibility

Figma's browser app requires Microsoft Edge version 121 or later. The browser's settings page checks for available updates.

Press the Windows key to open Windows Search.
Type Microsoft Edge into the search field.
Select the Microsoft Edge result if it appears.
Load edge://settings/help in the address bar if Edge opens.

✔️ Edge 121 or later is up to date

The settings page reports that Edge is up to date. Your installed version must also meet Figma's browser requirement.

Confirm the displayed Edge version is 121 or later.
Keep Edge open for the remaining setup.

Your browser is ready to load both Figma tools.

ⓧ I see an older version

The settings page automatically checks for an Edge update. Let the check finish before leaving the page.

Allow the available update to install.
Select Restart if Edge prompts you.
Return to edge://settings/help after Edge restarts.
Confirm Edge reports that it is up to date.
Confirm the displayed version is 121 or later.

The update clears the browser compatibility requirement.

ⓧ Microsoft Edge is missing

Windows Search may return no Microsoft Edge result. The official download page provides the Windows installer.

Visit https://www.microsoft.com/edge/download in an existing browser.
Download Microsoft Edge for Windows.
Complete the installation prompts.
Open Microsoft Edge through Windows Search.
Load edge://settings/help in the address bar.
Confirm Edge reports that it is up to date.
Confirm the displayed version is 121 or later.

Microsoft Edge is now installed and ready for the Figma workspace.

Edge Still Not Ready?

If the update does not finish or Edge does not reopen, help me troubleshoot my Microsoft Edge compatibility check. You can also follow the official Microsoft Edge update guide.

Create your free Figma Starter account

Using your email address can feel more personal than the design work. Every case-study detail in your drafts stays fictional.

Open a new tab in Edge.
Load https://www.figma.com/signup in the new tab.
Choose your preferred sign-up method.
Enter the requested account details.
Select Sign up.
Complete email verification if Figma requires it.

Why Use One Figma Account?

Figma Starter keeps the mapping board and prototype under one account. A separate diagramming platform would add a tool handoff before prototyping.

The Starter plan is listed as Free. It includes unlimited drafts for this project.

Keep Starter selected if Figma asks you to choose a plan.
Decline any paid upgrade option.
Return to the Figma tab after completing email verification.
Confirm the signup page has been replaced by your signed-in Figma workspace.

Keep the Case Fictional

Use only invented educational case data in this project. Do not add real customer details or information from a live banking process.

Your free Figma Starter account is now signed in. It is ready to hold the two project drafts.

Having Trouble Creating the Account?

If signup or email verification does not complete, help me troubleshoot my Figma account setup. You can also use Figma's official account creation guide.

Create and verify both design drafts

The FigJam draft holds the process maps. The Figma Design draft holds the clickable prototype.

The current draft name can be easy to miss because it sits in the top bar. Take a moment to locate it before renaming each draft.

Open figjam.new in a new Edge tab.
Select the current draft name in the top bar.
Replace the name with Citi US Onboarding Automation Map.
Press Enter to save the name.

You should see a blank editable FigJam board named Citi US Onboarding Automation Map.

Open figma.new in another new Edge tab.
Select the current file name in the top bar.
Replace the name with Citi US Onboarding Automation Prototype.
Press Enter to save the name.

You should see a blank editable Figma Design canvas named Citi US Onboarding Automation Prototype.

Before you reload both tabs, predict whether each draft will preserve its name and editable state.

Switch back to the Citi US Onboarding Automation Map tab.
Select Reload in the Edge toolbar.
Confirm the tab still shows Citi US Onboarding Automation Map.
Confirm the FigJam whiteboard remains editable.
Switch back to the Citi US Onboarding Automation Prototype tab.
Select Reload in the Edge toolbar.
Confirm the tab still shows Citi US Onboarding Automation Prototype.
Confirm the Figma Design canvas remains editable.

Your workspace is ready. The named mapping board and prototype canvas both survive a reload in Edge.

Drafts Not Editable After Reload?

Confirm you are still signed into the Figma account that created the drafts.
Recreate the mapping board from figjam.new if the first tab opened the wrong Figma product.
Recreate the prototype canvas from figma.new if the second tab opened the wrong Figma product.
Ask for help with restoring editable access to both Figma drafts.

Your browser is ready for the design sprint. Next, you will turn Maya Chen's fictional onboarding goal into a current-state service map.

Map the Manual Onboarding Experience

Your editable FigJam board is ready for the fictional onboarding case. The next challenge is seeing the process through Maya Chen's experience.

A current-state service map connects the client's journey to the work behind the scenes. Seeing those handoffs first reveals what later automation must improve.

In this step, get ready to:

Create a case card for Maya Chen with her role and onboarding goal.
Build a three-row map of the manual onboarding experience.
Mark the handoff owners and two visible pain points.

Create Maya's case card

A persona keeps the map tied to one user's goal. Maya's case card gives every later handoff a concrete point of view.

Switch back to the Citi US Onboarding Automation Map tab from earlier.
Choose a rectangle from the shape controls in the left toolbar.
Drag the rectangle onto the upper-left area of the canvas.

You should see an empty card with enough space for Maya's details.

Double-click inside the rectangle to edit its text.
Type Maya Chen, Finance manager at fictional Harborline Foods LLC, and Goal: Submit a complete company profile, ownership declaration, and signer authorization without chasing status by email. on separate lines.

Maya's name should appear above her role and goal. The case now has a specific fictional user at its center.

Build the three-row service map

Why map the current state first?

The current state gives each later automation idea a baseline. It shows where work moves between the client, onboarding specialist, and reviewer.

A future design can target a visible handoff or pain point. That keeps the redesign tied to Maya's journey.

Create a rectangular row label below the case card using the shape controls in the left toolbar.
Type Client actions inside the row label.

The first lane now has a clear place for actions Maya performs herself.

Press Control + D twice to create two copies of the row label.
Move the two copies into a vertical stack beneath the first label.

You should see three aligned row labels on the left side of the canvas.

Replace the middle label with Client-visible touchpoints.
Replace the bottom label with Backstage work.

The map now separates client activity from visible communication and internal work.

Add a small shape labeled Start application to the left side of the Client actions row.
Add a shape labeled Submit information to its right in the same row.

The opening part of Maya's journey now runs from starting the application to submitting her information.

Add a shape labeled Manual completeness review to the Backstage work row after submission.
Add a shape labeled Clarification by email when something is missing to the Client-visible touchpoints row after the manual review.

The map now shows how an internal review creates an email touchpoint when information is missing.

Add a shape labeled Approval review to the Backstage work row after the clarification step.
Add a shape labeled Status received to the Client-visible touchpoints row at the right end of the map.

All six stages should now move from left to right across the three rows.

Link the nodes with connectors in this order: Start application to Submit information to Manual completeness review to Clarification by email when something is missing to Approval review to Status received.

The connected route should cross between the client-facing rows and the backstage row as ownership changes.

Connectors not staying attached?

Select the loose connector endpoint.
Drag the endpoint onto the edge of its destination shape until it attaches.
Help me attach the connectors to my FigJam shapes.

Mark owners and pain points

Owner labels make responsibility visible at each stage. Pain-point markers show where Maya experiences repeated work or loses certainty about progress.

Add Owner: client beneath Start application and Submit information.
Add Owner: onboarding specialist beneath Manual completeness review, Clarification by email when something is missing, and Status received.

Most of the manual coordination now sits visibly with the onboarding specialist.

Add Owner: reviewer beneath Approval review.
Add a note labeled Pain point: repeated clarification beside the email clarification shape.

The first pain-point marker now identifies the loop that forces Maya to provide more information.

Change the pain-point note to a contrasting fill color.
Press Control + D to duplicate the pain-point note.

You should see two matching markers in the same contrasting color.

Move the duplicate beside Status received.
Replace its text with Pain point: uncertain status.

Before you trace the route, where do you expect ownership to move away from the client for the first time?

Trace the connectors from Start application to Status received one stage at a time.
Point to the repeated clarification marker.
Point to the uncertain status marker.
Name the owner shown beneath every stage.

You should reach Status received after following all six stages. You should be able to identify both pain points while naming an owner for every handoff.

Strong work. Your map now exposes the friction that a redesign needs to address.

Your current-state map makes the manual journey testable. Next, you will see what happens when that same linear process is simply moved online.

Test the Naive Automation

Your current-state service map makes every manual handoff visible. Moving the same sequence online does not prove that the process can handle incomplete information.

In this step, you will copy the flow in FigJam. You will test an incomplete packet before changing the model.

In this step, get ready to:

Duplicate the current sequence as a simple online flow.
Trace a missing-document packet through the copied flow.
Capture the test result on the board.

Duplicate the current flow

A copied flow protects your current-state evidence. It also gives the online idea a separate test area.

Switch back to the Citi US Onboarding Automation Map FigJam draft from earlier.
Pan to an unused area beside the current-state map.
Drag a selection box around the six process cards plus their connectors.
Press Ctrl+D to duplicate the selected flow.

You should see a second copy of the complete sequence. The original current-state map remains unchanged.

Select the section tool from the bottom toolbar.
Drag a section around the copied sequence.

The duplicated cards should now sit inside their own section boundary.

Click the new section title.
Enter Naive digitization as the section name.

You should see Naive digitization above the copied flow.

Double-click the copied Submit information label to select its text.
Type Online upload as the replacement label.

The second card now represents a digital intake point.

Double-click the copied Manual completeness review label to select its text.
Type Automatic routing to Approval review as the replacement label.

The third card now sends uploaded packets directly toward approval review.

Select the copied Clarification by email when something is missing card.
Press the Delete key.

The copied flow no longer includes the email clarification step.

Select the copied standalone Approval review card.
Press the Delete key.

The routing card now represents the direct handoff into approval review.

Drag a connector from Automatic routing to Approval review to Status received.
Arrange the four cards in one horizontal line.

You should now be able to read the copied sequence from Start application to Online upload to Automatic routing to Approval review to Status received.

Why keep the original map?

The current-state map is your baseline. Keeping it intact lets you compare the manual journey with the proposed digital flow.

Missing part of the copied flow?

Undo the duplicate if the copied connectors overlap the original map.
Repeat the selection around all six original process cards plus their connectors.
Ask for help with duplicating the current-state flow in FigJam.

Trace the incomplete packet

A happy-path flow only proves that expected information can move forward. A missing document tests what the model does when the packet is incomplete.

Before you trace it, where do you think a packet with no signer authorization will stop?

Select the sticky-note control from the bottom toolbar.
Place a new sticky beside Start application.

You should see a blank sticky beside the first card.

Type Signer authorization missing on the sticky.
Drag the sticky onto Start application.

The sticky now represents one incomplete packet entering the digitized process.

Move the sticky to Online upload along the first connector.

The online upload accepts the packet without changing its route.

Move the sticky to Automatic routing to Approval review along the next connector.

You should see the incomplete packet reach approval review. Its missing signer authorization never changes the route.

You found the weak point before implementation. The test has turned a process concern into visible evidence.

Why does the test fail?

The flow contains routing without a decision point. Every packet follows the same path.

The model has no exception path for incomplete information. A case can enter review without being separated for additional attention.

Mark the unsafe handoff

A failure note preserves what the test revealed. Stakeholders can see the exact point where the model breaks down.

Select the sticky-note control from the bottom toolbar.
Place a new sticky beside Automatic routing to Approval review.

You should see a blank note beside the approval-review handoff.

Click inside the new sticky.
Type Unsafe handoff: incomplete packet can reach the reviewer.

The note now states the specific failure exposed by the test.

Open the sticky's fill color control in the toolbar.
Select a red fill.

The red failure note should stand out beside the approval-review handoff.

Before you replay the trace, do you think the unchanged linear flow will stop the packet this time?

Move the Signer authorization missing sticky back to Start application.
Move the sticky to Online upload along the first connector.
Move the sticky to Automatic routing to Approval review along the second connector.

You should see the incomplete packet reach Approval review again. The red note identifies the unsafe handoff created by the missing branch.

Does your trace end somewhere else?

Check that no branch connector leaves Online upload.
Confirm that the only next card is Automatic routing to Approval review.
Ask for help with checking the connectors in the naive FigJam flow.

Your failed test has made the missing safety branch visible. Next, you will use that evidence to design a safer automation model with testable Agile requirements.

Design Safe Automation and the Backlog

The failed test on your FigJam board sent an incomplete packet straight to approval review. That result shows how faster routing can preserve an unsafe handoff.

Safe process automation needs explicit decisions for complete packets. It also needs a human path for exceptions.

You will capture those decisions in a future-state service blueprint. You will translate the design into prioritized user stories with testable acceptance criteria.

An MVP boundary will keep the first release focused on safe routing.

In this step, get ready to:

Build a future-state service blueprint with a safe exception branch.
Create three prioritized user stories with Given, When, Then acceptance scenarios.
Separate MVP scope from future work.

Build the future-state service blueprint

A service blueprint maps what the client does across a service. It exposes the visible responses and backstage work that support each action.

Why Use a Service Blueprint?

Your naive flow showed movement from upload to review. The service blueprint adds the decision logic that controls that movement.

Separating client actions from backstage checks makes every handoff visible. The exception queue gives incomplete packets a safe destination.

Switch back to the Citi US Onboarding Automation Map FigJam draft from earlier.
Add a large heading beside the Naive digitization section using the text Future-state service blueprint.

You should see a clearly separated space for the redesigned flow beside the failed version.

Add three horizontal row labels using Client actions, Front stage, and Back stage.
Arrange the three row labels vertically with enough room for cards and connectors.

You should now see three distinct lanes. Each lane gives one part of the service a visible home.

Add Submit information and View packet status to the Client actions row.
Add Status confirmation, Ready for approval review, and Needs review to the Front stage row.

The client lane now shows the submission and status-checking moments. The front-stage lane shows the responses the client can receive.

Add Required-field check, Document-presence check, and Human exception queue to the Back stage row.
Connect Submit information to Required-field check.

The start of the automated path is now visible beneath the client submission.

Connect Required-field check to Document-presence check.
Draw the complete-packet branch from Document-presence check to Ready for approval review.

You should see a complete packet pass through both automated checks before it reaches approval-ready status.

Draw the incomplete-packet branch from Document-presence check to Needs review.
Connect Needs review to Human exception queue.

You should see the flow split before approval review. The incomplete packet now lands with a human who can apply judgment.

Connect both outcome cards to Status confirmation.
Connect Status confirmation to View packet status.

That is the critical safety decision in place. Every packet receives a visible status without bypassing the exception path.

Branch Hard to Follow?

Move Ready for approval review and Needs review farther apart so each branch has its own space.
Reconnect any loose line to the edge of its destination card.
Ask for help with the layout if the complete and exception paths still overlap.

Create the prioritized user stories

A user story captures one outcome from a person's point of view. Acceptance criteria define the observable behavior that proves the story works.

Add the heading Prioritized MVP backlog beneath the future-state blueprint.

This heading creates a clear boundary between the service model and the delivery backlog.

Create the highest-priority card with the label MVP 1 using this story: As a client finance manager, I want immediate confirmation of my packet status so that I know whether action is required.
Add this acceptance scenario below the story: Given a packet is submitted When validation runs Then the client sees immediate confirmation of the packet status.

The first story makes status confirmation part of the initial release. Its scenario gives the team one visible result to test.

Create the second-priority card with the label MVP 2 using this story: As an onboarding specialist, I want incomplete packets routed to an exception queue so that I can focus on cases needing judgment.
Add this acceptance scenario below the story: Given signer authorization is absent When validation runs Then the case status becomes Needs review and the case appears in the exception queue.

The second story covers the branch that the naive flow missed. Its scenario ties the missing document directly to human review.

Create the third-priority card with the label MVP 3 using this story: As an approval reviewer, I want only complete packets routed to review so that avoidable rework is reduced.
Add this acceptance scenario below the story: Given required fields and required documents are present When validation runs Then the case status becomes Ready for approval review.

The third story protects the approval reviewer from avoidable rework. You now have one testable story for each key outcome in the blueprint.

What Makes These Scenarios Testable?

Each scenario begins with a specific packet condition. It finishes with a status or routing result that a tester can observe.

The scenarios stay focused on behavior instead of implementation details. That focus keeps the backlog useful before technical design begins.

Define the MVP boundary and verify both paths

The MVP boundary separates the smallest safe release from ideas that still need discovery. This keeps automated validation and human exception handling in scope.

Draw a horizontal line beneath the prioritized story cards.
Add the label MVP above the line.

You should see a clear release boundary beneath the three prioritized stories.

Place Status confirmation, Completeness checks, Exception routing, and Approval-ready routing in the MVP area above the line.

The MVP now covers the smallest flow that reports status and prevents unsafe approval handoffs.

Draw a second horizontal line below the MVP area.
Label the second line Future and needs validation.

The board now has a separate space for assumptions that require more discovery.

Place Automated risk decisions and External-system integrations below the Future and needs validation line.

Those ideas are visibly outside the MVP. The case study stays focused on completeness checks and exception handling.

Before you trace the two packets, which branch do you expect each one to take?

Trace a packet with every required field and document through the future-state blueprint.

You should finish at Ready for approval review. This path maps to the approval-reviewer story and its Given, When, Then scenario.

Trace the Signer authorization missing test case through the future-state blueprint.

You should finish at Needs review before reaching the Human exception queue. This path maps to the onboarding-specialist story and its Given, When, Then scenario.

You have replaced the unsafe linear handoff with two testable paths. Complete packets continue to approval while exceptions stay with a human reviewer.

Your future-state model now has safe decision logic and a focused delivery backlog. Next, you will turn the exception path into a clickable stakeholder experience.

Prototype the Exception Review

The blueprint now catches incomplete packets before they reach approval review. Stakeholders still need to experience that decision before anyone invests in implementation.

A clickable low-fidelity prototype in Figma Design turns the exception path into a flow that stakeholders can test.

In this step, get ready to:

Build three neutral screens for the fictional onboarding case.
Connect the validation controls to the correct destination screens.
Preview the flow to confirm that incomplete information reaches exception review.

Build the three prototype screens

Low-fidelity screens use simple shapes plus clear labels to test the workflow. A neutral layout keeps attention on the exception decision.

Why Use Figma Design Here?

Your Starter account includes Figma Design plus FigJam. This keeps the blueprint and prototype inside the same account.

The screens only need enough detail to make each decision visible. Fast feedback matters more than polished styling at this stage.

Switch back to the Figma Design draft named Citi US Onboarding Automation Prototype from earlier.
Use neutral shapes filled only with invented case data.
Activate the Frame tool by pressing F.
Select the Desktop preset in the right sidebar.
Double-click the new frame name in the Layers panel.
Enter Application summary as the frame name.

You should see one blank desktop frame named Application summary on the canvas.

Activate the Rectangle tool by pressing R.
Draw neutral rectangles for the screen structure.
Activate the Text tool by pressing T.
Add Application summary near the top of the frame.
Add text layers for Company profile, Ownership declaration, plus Signer authorization.
Add Run validation inside the control rectangle.
Add Fictional educational case study at the bottom of the frame.

The first screen now summarizes the fictional packet. Its control gives the stakeholder a clear next action.

Select the Application summary frame in the Layers panel.
Duplicate the frame by pressing Ctrl+D.
Drag the duplicate to the right of the original frame.
Rename the duplicate Validation result.
Replace the screen heading with Validation result.
Add Needs review as the prominent status.
Replace Run validation with Open exception.

You should now see a second frame that makes the failed validation visible. The footer remains in place because the screen came from the first frame.

Select the Validation result frame.
Duplicate the frame by pressing Ctrl+D.
Drag the duplicate to the right of Validation result.
Rename the duplicate Exception review.
Replace the screen heading with Exception review.
Replace Needs review with Signer authorization missing.
Replace Open exception with Request update.

The canvas should now show three desktop frames in sequence. Each screen represents one visible stage of the exception path.

Confirm that every frame displays Fictional educational case study in its footer.
Confirm that every name in the Layers panel matches its visible screen heading.
Confirm that no real customer data appears anywhere on the canvas.

Connect the exception path

A prototype interaction turns a visible control into a clickable hotspot. Each interaction needs a trigger plus a destination.

Select the Run validation text layer inside Application summary.
Select the Prototype tab in the right sidebar.
Drag the plus icon from the selected layer to the Validation result frame.
Select On click for Trigger in the interaction details.
Select Navigate to for Action.
Confirm that Destination displays Validation result.

A connection line should now lead from Run validation to the second frame. This interaction turns the summary screen into the start of the test.

Connection Line Missing?

Select the Run validation layer again before dragging the plus icon.
Confirm that Validation result is a top-level frame.
Ask for help with the first prototype connection.

Select the Open exception text layer inside Validation result.
Drag the plus icon from the selected layer to the Exception review frame.
Select On click for Trigger.
Select Navigate to for Action.
Confirm that Destination displays Exception review.

The second connection line should lead from Open exception to the third frame. Your static screens now form one clickable exception path.

Second Connection Going to the Wrong Screen?

Select the Open exception layer to inspect its interaction details.
Set Destination to Exception review.
Ask for help correcting the prototype destination.

Preview the exception flow

The flow starting point tells Preview which frame to show first. Setting it on the summary screen lets stakeholders experience the decision in the intended order.

Select the Application summary frame.
Locate Flow starting point in the Prototype tab.
Click the plus sign if the frame has no starting point marker.

You should see a starting point marker beside Application summary. Figma may have created it automatically when you added the first connection.

Before you test the flow, consider which screen each control should reveal.

Select Preview to open the inline prototype preview.

Preview should open on Application summary. The screen should show the visible Run validation control.

Click Run validation.

You should move to Validation result. The prominent status should read Needs review.

Click Open exception.

You should move to Exception review. The screen should display Signer authorization missing plus the Request update control.

Preview Not Following the Flow?

Confirm that Application summary has the flow starting point marker.
Inspect each hotspot to confirm that its destination matches the next top-level frame.
Ask for help testing the complete prototype flow.

That is the exception path working. Your prototype now demonstrates how an incomplete packet reaches human review before approval.

Secret mission

Add the Client Recovery Loop

Catching an incomplete packet protects the approval process. Add a fourth screen that explains the missing item. Close the loop with resubmission that returns the case to validation.

Clean Up Your Resources

Figma Starter is free for this project. Your two drafts create no ongoing project cost.

Choose what happens to your drafts next. The options below cover keeping them available, pausing your work, or deleting them.

Resources you used:

Your FigJam draft named Citi US Onboarding Automation Map with the service maps, automation models, recovery loop, Agile backlog, and acceptance criteria.
Your Figma Design draft named Citi US Onboarding Automation Prototype with the tested four-screen clickable prototype.

Keep everything running

No action needed. Choose this option if you plan to share the case study or extend its recovery loop.

Keep the Citi US Onboarding Automation Map draft in your Figma account.
Keep the Citi US Onboarding Automation Prototype draft in your Figma account.

Pause - I'll come back to this later

Signing out ends your active Figma session. Both drafts stay associated with your account for later.

Sign out of your Figma account.
Close the Citi US Onboarding Automation Map browser tab.
Close the Citi US Onboarding Automation Prototype browser tab.
Return to your Figma account when you want to continue working.

Delete - I don't want to use this again

Use this option when you do not want to use the case study again. Your free Figma Starter account remains available.

In the Figma file browser locate the Citi US Onboarding Automation Map draft.
Use Delete to remove the Citi US Onboarding Automation Map draft.
In the Figma file browser locate the Citi US Onboarding Automation Prototype draft.
Use Delete to remove the Citi US Onboarding Automation Prototype draft.
Refresh the Figma file browser.

You should no longer see either draft in the file browser.

Close the Citi US Onboarding Automation Map browser tab.
Close the Citi US Onboarding Automation Prototype browser tab.

No cloud service or automation remains running.

Nice Work!

You did it. You built a presentation-ready fictional commercial-client onboarding case study that traces a missing-document scenario from manual bottlenecks through safe exception handling.

You've learned how to:

Built a current-state service map in FigJam that shows Maya Chen's journey through manual handoffs. Tested the naive digitization with missing signer authorization to expose the unsafe handoff.
Designed a future-state service blueprint with automated completeness checks plus a human exception queue. Converted the blueprint into an Agile backlog with three prioritized user stories, Given, When, Then acceptance scenarios, and an MVP slice.
Built a three-screen clickable prototype in Figma Design that routes an incomplete packet from validation to human exception review. Replayed the flow in Preview to confirm that every status matches the blueprint.
Secret Mission: Added an Update requested recovery loop that lets the client resubmit missing information. Aligned the four-screen flow with the recovery user story and acceptance scenario.

Ready to quiz yourself?