Ash Sathe

SmartBricks.
Five judgments.
One defensible handoff.

I designed the review journey that helps an investment analyst understand an AI led analysis, challenge the inputs and prepare it for VP review.

AREAS OF WORK

Research

Product design

User journeys

Prototyping

YEAR

2026

PROJECT

Feature level project

01 CHALLENGE

From analysed deal to VP review.

Smart Bricks had already analysed a new £80m UK logistics acquisition. It had reviewed the documents, applied the firm’s mandate and identified five material items that needed the analyst’s judgement.

My challenge was to design the next part and help the analyst understand the deal, check the evidence, challenge the numbers and approve the analysis for their VP or investment committee.

The brief allowed one working day. I focused on this desktop review journey and the components it needed.

  1. 01

    Understand the investment. Show the recommendation, returns and main risks together.

  2. 02

    Review the five material items. Keep the source, proposed input and effect on returns close to the decision.

  3. 03

    Approve a clear version. Send the changes, reasons and supporting evidence with the analysis.

The opening screen brings the investment view and the five review items together.

02 RESEARCH

Understanding the company and the problem.

I started with Smart Bricks’ website, its investment firm pages and the challenge. I looked at how the company brings deal documents, market research and the firm’s own investment rules into one review.

The main problem was clear: the system can do thousands of things, but the analyst should not have to check them one by one. The interface needed to show what mattered and make the supporting work easy to inspect.

Company context, analyst needs and the decisions they led to.
  1. 01

    Company context. The product connects firm knowledge, deal information, specialist analysis and financial models. The review needs to keep those sources distinct.

  2. 02

    Analyst’s task. A recommendation needs enough detail to question it. The five items become the starting point, with the rest of the analysis available in the background.

  3. 03

    VP’s task. The next reviewer needs to see what changed, why it changed and which version was approved.

Problem framing across the business, analyst and engineering needs.

03 SYSTEM FLOW

Keep the work behind each decision available.

The Client Brain brings the firm’s mandate and investment approach. The Deal Brain holds the understanding of the opportunity. Specialist agents investigate the deal, and the financial models calculate the results.

The analyst sees a short review queue. Each item can lead back to a document, an AI recommendation, a firm rule or a calculation. They do not need to manage the agents that produced it.

The system flow explains what happens before the analyst opens the deal.

04 USER JOURNEY

A review that can go deeper without starting again.

I used the FigJam journey to connect the overview, review queue, evidence, changes and approval. The analyst can accept a proposal, change it, test a downside or raise a question for their VP.

An unresolved material item stays open. The analyst returns to the same queue after each decision, with progress visible throughout.

The original connected journey from the deal overview to VP review. Enlarge to read the branches.
  1. 01

    Open the deal and understand Smart Bricks’ investment view.

  2. 02

    Work through the five items, checking evidence where needed.

  3. 03

    Preview a change and record the reason before applying it.

  4. 04

    Review the completed decisions, approve the version and send it to the VP.

05 DESIGN ITERATIONS

Make the next decision easier to find.

I worked through a few layouts to decide what should appear first. The main change was giving the recommendation and review queue more space, while moving supporting detail into the review itself.

The analyst can read the investment view, compare it with the fund’s requirements and open the five items that need a decision. Each item leads to the evidence behind it.

06 PRODUCT DESIGN

Review the evidence, then make the call.

I kept the main interactions in the deal workspace. The analyst can see the source and the proposed input, make a choice and return to the queue.

Start with the five items.

Each row says what needs a decision and why it matters. A rent conflict, a judgement about exit yield and a cost estimate are different problems, so the labels explain the difference.

The queue puts open decisions first and keeps completed findings available.

Compare the evidence beside the decision.

The rent roll and lease disagree on Unit 2. Showing both extracts side by side lets the analyst compare them without leaving the review. The selected figure and reason are kept with the decision.

The source conflict is visible before the analyst chooses the figure.

Show how the recommendation was formed.

The evidence drawer separates comparable sales, AI adjustments, the firm’s rule and the financial calculation. This makes it possible to question one part without treating the whole recommendation as a black box.

The source trail stays beside the exit yield review.

07 RETURNS & VALUATION

Make the effect of a change clear.

The chart shows exit yield on the horizontal axis and levered IRR on the vertical axis. The fund’s 12% hurdle stays visible, so the analyst can see where a more cautious exit yield takes the return below the requirement.

The graph identifies its model run. The change preview then uses the current run, including decisions already made. This matters because the rent correction and the yield change both affect the final return.

Base case sensitivity before the rent correction. Each point shows a tested exit yield.

Preview before applying the change.

The analyst sees the return, equity multiple and valuation together. They add a reason before applying the new yield. The original proposal remains visible for comparison.

The updated preview reflects the current run after the rent correction.

08 AI INTERACTION

Use AI to test a question about this deal.

The brief allows conversation, but the analyst’s main task is still the review. I kept scenario testing inside the deal, with the current model version and inputs attached.

For example, the analyst can ask what happens if the Unit 3 tenant leaves. The response shows the downside, where each input came from and the option to save it for IC. It does not replace the base case automatically.

Scenario testing supports a decision already in progress. The financial engine calculates the return.

09 APPROVAL & HANDOFF

Check the changes before sending them on.

The analyst finishes the remaining items, then reviews all five decisions together. The approval screen lists the changes, their reasons and the resulting investment case.

The vendor’s rent memo remains a follow up. The model uses the binding lease figure. The handoff includes the approved version and its evidence. The confirmation names what was sent, so the analyst knows the VP will review the same analysis.

The remaining items use the same review pattern.
A final check of the decisions and returns before approval.
The memo carries the reviewed changes and downside case.
The confirmation records the version and recipient.

10 DESIGN RATIONALE

What I prioritised.

I focused on the point where the analyst takes responsibility for the analysis. Five clear decisions, traceable evidence, a preview of changes and a versioned handoff support that task.

Sourcing, portfolio monitoring and the underlying financial engine sit outside this challenge. The navigation gives the review a place in the wider product, but those areas are not new flows in this work.

With more time, I would review the journey with analysts and VPs: can they find the source of a disputed number, understand the effect of a change and tell which version is ready to send?