Saturn CoPlanner App
Saturn is a YC backed operating system for financial advice firms based in the UK. Saturn handles data and workflows for financial advisers making them more efficient. Saturn makes the data the core of your operations by gathering meeting data to aid compliance
Saturn
Deliverables
CoPlanner App Redesign
Year
2024
Role
Product Design




The Problem
Advisers distract themselves and might make clients uncomfortable by constantly writing notes.
Some of the information might be missing if only hand-written notes are taken
Advisers need an update on their client’s personal circumstances before their meeting.



Why the problem?
Advisers are people-persons and love engaging with their clients.
Financial advisers are common for HNIs that need a face to connect to their immense wealth.
Advisers manage about 100 clients. You can imagine how hard it is to remember your own family’s dates, imagine 100’s of clients and families. Paraplanners do this job. Before advisers meet their client, Paraplanners get their client’s file with their history, important dates and give the adviser a run-down of their client so they’re prepared.
How the advice process happens?
New clients undergo onboarding meetings while existing clients receive annual reviews or special check-ins for major life changes.
Advisers or assistants take meeting notes (85% vs 15%) which are then processed by admin staff. Follow-up client communications ensure understanding and document agreements.
If needed, paraplanners research and prepare recommendation documents. For new product recommendations, a detailed suitability letter is created demonstrating regulatory compliance. Otherwise, a review letter summarizes meeting outcomes.

How important is the CoPlanner App?
About 65% of the meetings that financial advisers do, are in-person meetings as they want to be with the client and give them personal attention. That means, 60% of our users were having this problem.
We wanted to create a simple solution that advisers could use on-the-go and be unobtrusive and work the same way as the online note-taker. Let’s now look at who are my stakeholders, and what are they’re needs.
The Old Saturn CoPlanner App
Luckily we have a good base to start with, something that users are comfortable with, which is the old CoPlanner app. Down below is a picture. The brief was very simple, to redesign the app with the current features, but get a roadmap of the CoPlanner app to see where we can go next. The old app was already proven in the features it provided.

Who are my stakeholders?
It is super important to know who we’re building for and what their role would be in the problem we’re solving. Below is a chart showing the roles in a traditional advice firm. I would be building for financial advisers. I then understood the needs, pain points and gains of each stakeholder to get to the crux of the problem. We're solving mainly for Advisers with the new CoPlanner App.
Let's analyse each stakeholder
Before we define business and design goals, let's narrow down what we should focus on. The brief mentioned only a rekin, but I wanted to explore the possibilities in giving a better experience to the end user. So I did a bit of research on our clients and got their personas.I then worked on their wants, pain points. We would need this as these are the needs that will be solved coming forward and give the CoPlanner app a product roadmap for where it should be in the next few years. For version 1, we need a set of solid features that solve the core problem, but make sure that it's feasible from a tech side. Here's where I would like to learn from.
Financial advisers are the primary users of CoPlanner, serving as the crucial interface between the system and clients. Their real-time meeting documentation needs drive core functionality requirements. Advisers' compliance obligations shape privacy controls, while their client rapport concerns influence the app's unobtrusive design. Their position at the center of the information flow makes them the most critical stakeholder for feature prioritization.


Paraplanners transform adviser meeting outputs into actionable financial recommendations, making them critical downstream users of CoPlanner. They rely on comprehensive, structured data to draft advice documents and perform calculations. Their need for complete, context-rich information drives the app's documentation quality standards. As technical specialists working across multiple client cases, paraplanners' efficiency requirements shape CoPlanner's organization and information retrieval features.


Administrators serve as operational linchpins, coordinating client onboarding and maintaining accurate records across multiple systems. Their role in CoPlanner focuses on data consistency and workflow efficiency. They require streamlined access to client information to schedule meetings, process documentation, and maintain compliance records. Administrators' need for a single source of truth drives the app's data integration capabilities and multi-participant management features.

Business and Design Goals
Before we define business and design goals, let's narrow down what we should focus on. The brief mentioned only a rekin, but I wanted to explore the possibilities in giving a better experience to the end user. So I did a bit of research on our clients and got their personas.I then worked on their wants, pain points. We would need this as these are the needs that will be solved coming forward and give the CoPlanner app a product roadmap for where it should be in the next few years. For version 1, we need a set of solid features that solve the core problem, but make sure that it's feasible from a tech side. Here's where I would like to learn from.
For this release, we wanted to only focus on the most important needs to make the Saturn CoPlanner app a viable product. Therefore I looked at solving only for tech needs + Adviser need + Business needs for this version. Below is are the goals looked at.

Solutionising
Now that we know what we want from the solution, let’s start diverging on how we can solve this! I first made flowcharts of main flows There were initially 10 flows that have been extracted and can be possible, however we only went with the 4 main ones listed below. I then broke down the action into segments, related pain points and then what opportunities or the approach I can use to solve them. Here they are:
Meeting Recording Flow
This flowchart details the end-to-end process for recording meetings, from setup to processing. It addresses compliance concerns with sensitive segments handling, participant consent, and clear UI warnings. The flow ensures proper documentation with auto-tagging speakers, timestamped action items, and unified storage that links records to client profiles for easy retrieval.
Lofi Screens
Here are the wireframes I have created according to what we need. On the left would be the home screen, where the adviser would be able to see all their meetings for that day and in the future. They can prepare for the meeting with a feature we can call meeting prep.
Meeting PrepThe problem of the adviser not getting time to get an idea about the client's circumstances gets solved by giving a notification before the meeting to brush up on the client. From a technical side, this was possible as the data gets assimilated through the Saturn cloud and gets sent to the adviser 10 mins before the client's meeting.
Past Meetings Flow (Status)
This diagram shows how users access and interact with previous meeting records. Features include visual status indicators, role-based views, advanced filtering, and full-text search capabilities. Users can review consolidated meeting details, add annotations, link meetings to tasks, and share content while maintaining confidentiality of sensitive segments.
Lofi Screens
Here are the wireframes for meeting details, this is after they have recorded a meeting and want to access the meeting recording.
Adding contextWhat was important and a new feature, was being able to listen to the recording, delete and share the recording if in-case a paraplanner or admin staff wanted to obtain it. It is sent to the Saturn cloud but we were recieving complaints that it should be able to be accessed by the adviser, to send it via Teams to their paraplanners and be able to add context.
How My Day Looks (Home)
This flow illustrates the daily scheduling experience with calendar integration. It emphasizes two-way sync with external calendars, guided scheduling, conflict resolution, and meeting labeling. Smart features include auto-notifications, pre-meeting alerts, and post-meeting actions that streamline workflow management. The red text wasn't looked into as it was a limitation from the tech-side.
Lofi Screens
Here are the wireframes for the home screen where the adviser would land. We wanted to keep this contextual and be like the name suggest "CoPlanner". It should help you with your needs. Hence, we made it extremely simple with whatever the adviser needs access to would be available and timed.
Next Best Action
This contextual feature intelligently suggests the most important task for the adviser to focus on next. By analyzing client data, meeting schedules, and outstanding actions, it provides timely prompts that improve productivity and ensure critical client needs aren't overlooked.
Calendar View
The condensed calendar view offers a space-efficient way to display upcoming meetings. The swipe-up gesture reveals more detailed scheduling information, balancing at-a-glance awareness with comprehensive planning capabilities when needed.
Prominent Record Button
Positioning the record button front and center prioritizes the core meeting documentation functionality. By relocating less frequently used navigation elements, the design emphasizes the primary action of capturing meeting details, making it immediately accessible during client sessions.
Now that we have the basics of what features we’re building along with the flows, let’s jump into making wireframes.
wireframes of possible features and solutions. At this step, we make sure that the app is functionally right. Not looking into the aesthetics so we can iterate fast! This step is crucial to decide what we're going to make. This is where we explore more features from the tech-side to see what's possible and what isn't. For example,
1 feature we couldn't get working due to a tech limitation was the adviser getting live updates on the meeting status and if they've covered all the agenda points and any remaining points they have to cover.
Bringing it all together

I took this time to diverge on the different styles that could be made. Even though Saturn does have a visual language, Saturn CoPlanner needed a new identity that was also familiar. I wanted CoPlanner to be more physical. Layers that show that it's a mix between physical and digital. Here are a few design languages I explored after scouring Pinterest for ideas.


![]() | The design prioritizes meetings as the central user experience. Every element—from the prominent record button to contextual meeting prep insights—creates a focused environment where client sessions become the gravitational center. The 3D visual treatment draws attention to upcoming meetings and preparation tools, ensuring advisers always have the right information at the right moment. |
Lots of meetings with the developers to know what’s feasible and what isn’t. Some very fuzzy pictures cz I was focusing on the process. Some features that I would have loved our users to have got pushback due to a lack of time. | ![]() |
Documentation and Handover

Once the use-cases and documentation was complete, it was time to handover the designs to the dev team that needed to convey the product designs.