Projected.ai, financial planning for founders

Projected.ai is for founders and CFOs who are responsible for their company's numbers but do not come from a finance background. They want to forecast, run scenarios, plan hires and see the impact of decisions before they make them. They do not want to learn double-entry bookkeeping first.

The brief was a web product where users could sign up to the beta, input their own data, get a working forecast and then layer scenarios on top. It had to feel approachable on the first visit and still be credible enough that someone with a finance background would trust it.

I started with discovery: short interviews with founders and operators about how they actually plan their numbers today. Most were using a spreadsheet they did not fully trust. The recurring word was anxiety, not curiosity.

From those conversations I built two core personas and a journey map covering signup, first inputs, first forecast and the moment they tried a scenario. That journey became the spine of the product.

Before drawing screens I built the design system. Doing this early meant every later decision sat on shared tokens and components instead of being invented per page, and made handover much cleaner for the engineering team.

I pulled a moodboard of finance and SaaS products users already trusted and ran a competitor review across the planning tools they had tried and abandoned. The pattern was clear: the credible ones felt calm and quiet, the abandoned ones felt loud and busy.

That gave us a clear visual direction: generous whitespace, restrained colour, charts that read at a glance, type used to create hierarchy instead of decoration.

Once a user signed up to the beta, the very first job was putting their own numbers into the tool. This is the moment most finance products lose people. The screen has to look simple, the field names have to be plain, and the user has to feel like they are answering questions rather than filling in a form.

I designed the input flow as a short, guided sequence. One concept per step, plain-language labels, examples in the placeholder, and a quiet progress indicator so people knew how much was left. No jargon until the user had earned the right to ignore it.

Later steps in the same flow. The pattern stays consistent so by step three the user is no longer learning the interface, only answering the next question.

The dashboard was the highest-stakes screen in the product. It had to give a non-finance user an immediate sense of where the company stood and let a finance-literate user drill into the detail without feeling that the surface was hiding things from them.

It went through several sprints and rounds of testing before being approved. We landed on a layout that put the headline numbers and the cashflow chart above the fold, with scenario controls and breakdowns sitting one scroll below. The chart became the anchor: it is what people looked at first and what they pointed at when they talked about the screen.

A second view of the dashboard pattern, showing how the same components recombine for different data states.

Every flow was prototyped in Figma to a level where I could click through it as if it were the live product. That meant we could test signup, inputs, dashboard and scenarios with real users on a Tuesday and brief the engineering team on the changes by Friday.

Prototyping at that depth also caught problems that static frames could not. The transition between input and dashboard, for example, was the moment people felt either rewarded or confused. Designing it as an actual flow made the issue visible early.

Alongside the app I designed a set of landing pages on projected.ai, with different versions aimed at different audiences: founders, CFOs and operators. Each version led with the pain that audience had named in research, then walked through the same product but with different priorities.

Responsive layouts were designed at the same time as desktop, not retrofitted. The component library covered the same patterns in both directions.

The same components and tokens carried across breakpoints. Mobile was not a stripped-down afterthought.

The marketing team wanted to announce the beta on social without needing a designer for every post. I designed a small set of templates in the product's visual language, set up in Figma with clear text slots and image rules so anyone in the team could ship a post that still looked like the brand.

An internal stakeholder pushed to add an info icon next to almost every field, on the basis that this audience was new to finance. Their instinct was kind but it would have turned every screen into a wall of tiny question marks.

I went back to the research. People who did not know a term usually skipped it, came back later, or asked someone. Very few people clicked info icons in the tools they were already using. Adding them everywhere would not help, it would just add noise.

We agreed a rule instead: definitions appear on hover for terms the user is required to act on. Everything else stays clean. The result was a calmer interface that still met the original need.

This was an early-stage SaaS project, so the outcomes below are about how the product behaved in testing and how the team kept building, not live analytics published online.

I ran moderated usability sessions on the prototype with people who matched the personas: founders without a finance background and operators who were comfortable with numbers but new to forecasting tools.

Tasks were specific. Sign up to the beta, get to your first dashboard, change one assumption and tell me what happened to your runway. Watching people do those tasks end to end was what shaped the input flow and the dashboard, not opinion.

Findings were turned into a prioritised list of changes the team could action sprint by sprint.

The biggest thing this project taught me is that for products tied to money or risk, calmness is a design feature, not a style. People came in anxious. Anything loud, anything that felt clever for its own sake, made them more anxious. Things that felt quiet, predictable and considered made them trust the tool.

It also reinforced how how much a design system pays you back when the team is small and the surface area is big. Doing the system first meant the second landing page took a day, not a week, and that the engineering team never had to guess what a button should look like.

The work covered the core beta experience and the marketing surface around it. On the way out I left the team with a prioritised list of where to take it next.

Handover was treated as a deliverable. I worked closely with the engineering lead to make sure every component in the Figma library had a clear name, a clear use, and an example of how it composed into a real screen.

The pack covered the design system, the prototyped flows with annotations, the research summary and the prioritised next steps. Everything was in one place so the team could keep moving once the engagement ended.