Atlas Agent: Creating an AI transaction coordinator tool
An AI platform that supports coordinators and selling agents in the property closing process.
How to create a platform that can manage closing real estate properties?
- Product design
- UX flows
- UI
- Design system
- Prototyping
Atlas Agent helps transaction coordinators and selling agents with the property closing process.
Client relations, tracking transactions, and automating workflows.
As lead, I set the design direction, ran reviews with the CEO, and divided the feature work across the design team.
- Role
- Lead UX/UI Designer
- Timeline
- 12 months
- Design Team
- CEO, 3 UX/UI designers, 1 UX researcher
- Tools
- Problem
The platform was lacking in design structure
When I contacted the owner, we started with just the landing page design at the time. Atlas Agent was an idea, but nothing complete; it was a project in progress, but it was lacking a design process and identity.
The path wasn’t clear.
We knew what we wanted to build, but there wasn't a pipeline where we could actually say, “We need to launch on this day.”
3 types of users
The platform needed to work for 3 different types of users: buyer/seller, buyer agent, and listing agent.
- Approach
We prioritize 4 features.
Onboarding process
How the user goes from signing up to creating their first listing.
User system
How to manage members and admins in multiple teams.
Dashboard panel
How to manage listings, who has access, and what they can see.
Upload files and add items
How to upload, prioritize, and create files.
- Discovery
Understanding the complexity of the property closing cycle.
The process of buying a property in the USA involves multiple systems that we took into consideration for the building process.
There are 3 types of users involved in this type of transaction. Not all of the users need to have complete access, and only some of them will have management access.
Buyer/Seller
Clients involved in this transaction: they don't manage the closing, but can submit paperwork (files and signatures).
Buyer Agent
In charge of the buying side: manage all the paperwork for the buyer during the closing.
Listing Agent
The one who controls the listing, usually the admin of the dashboard, controls all the transactions, representing the selling side.
- Information Architecture
I design a structure that can be scaled and adapted, divided into listing creation, space management, file upload, tracking process, and closing.
The listings are classified into 3 states.
- Needs attention
- Good standing
- Closed
A progress tracker follows the listing through those states until the transaction closes.
- Core Flows
4 core flows that make all the operations work.
Onboarding process
Design to reduce the time to value (TTV); the user goes directly to creating a listing and inviting members after signing in.
User system
I designed a user flow for each user type.
Buyer / Seller view: it's the same as a member and has limited permissions
Owner view: it's the owner of the space and controls the platform and the teams.
Admin view: they can manage the listings where they are Admins.
This system was more for big companies with multiple teams.
Upload files and add items
The admin and owner can upload files and add items (like tasks), send them to other members, and ask for the information needed.
Dashboard panel
The dashboard was designed as a split space, one side for agents and one for clients. That decision didn't survive testing.
- Competitive pattern analysis
I design inspired by how Slack's structure processes members, files, and notifications.
- Design Decisions
We made multiple iterations, redesigning three or five times, based on user feedback and introspection.
I used to fill space in the UI instead of prioritizing the platform’s core function. This allowed me to be more open and make better decisions based on the user.
- Dashboard
We didn’t make states; when a first-time user reached the platform, they found this screen, with no direction on where to start.
Users asked us to focus more on the listing; they felt the rest of the functionality was noise.
1 Design: Too much noise.
No hover state when you were on the home screen.
Not enough contrast and spacing.
The core function was just a small section in the dashboard.
This feature didn't have an empty state, just a small piece of information about what was missing.
2 Design: Usability and design issues
More issues with the text being too small, plus icons that didn't need to be there.
Still, contrast issues with too much radius.
Icons were extremely small and impossible to click.
It wasn't relevant to have an activity feed on home, and users preferred to discard it rather than see it.
The more reliable design focuses only on the listing, including the rest of the features on the listing page, rather than the home page. This allows users to easily see which listings are pending, closed, or active.
We removed all extraneous information and focused on the essentials: grid personalization for listings and the core statuses (needs attention, good standing, closed, and recently added).
3 Design: Focus completely on the listing prioritization
Replace notifications with team management, and change teams more easily.
Edit Listing config for quick actions such as delete or change status.
View personalization from card to list view.
Add a filter status to search faster for the type of listing.
- Listing
The first design repeats patterns similar to those we fixed on the dashboard.
We started with unnecessarily heavy contrast, type that was too large, unnecessary icons, and inconsistent iconography.
1 Design: Too many colors fighting each other
Icons weren't consistent with the rest of the iconography.
Multiple colors fight for attention; the contrast, no symbol tells me this is an accordion.
Badges didn't pass contrast; icons and text were too small and fighting each other. Icons weren't consistent (you can tell one is different from the rest).
2 Design: Too many features fighting for attention
The track process was fighting with the dashboard space; the number and the text were fighting each other, with the copy too small and looking trapped inside the content.
The three spaces didn't make sense; from a dev perspective it was even more work, rather than having just one space and giving permissions and views to specific users.
The next step text was too small to read; most users decided to take it out because they want to have their own pipeline.
The user access was distracting the user from the main task in the listing; having it always open wasn't needed.
Prioritize the listed work that the agent needs to complete (pending tasks).
An agent’s day focuses directly on their pending items. When they access a listing, the first thing they see is the tasks requiring their attention, whether related to a file or a specific task.
If they want to see the listing’s progress, they can view it in the progress tracker tab, along with the listed members below.
3 Design: Just tasks and what needs my attention
Limit the title to a certain amount of text; use the space to show the complete title on one line.
Minimalist card design, with just enough color to show it needs attention.
Add another tab to see the progress tracker instead, so it isn't a distraction for the user.
Replace the accordion with a table design that shows all the items involved in the listing.
Control the members on the side; it gives enough information to see who is in this listing and who to add.
Include a card section to show the cards that need attention (what my priority is to do).
Show how many items were completed.
Show by task and item which tasks were completed, denied, or signed.
We reworked the communication with the user in every state
We developed multiple state and notification systems to keep the user informed about their progress when they upload a file, finish a task, have nothing pending, or when a new user joins.
Toast Notification
Empty State
Add New Members
Upload Files
- Final Design
The final design resulted from multiple iterations and back-and-forth discussions to create a product that works for selling agents.
This involved removing unnecessary functions, prioritizing tasks, monitoring progress, and managing members.
- Outcome
We didn't validate enough.
On the launch date, we started getting users. Multiple investors were in talks to invest in the company. Unfortunately, no deal closed during due diligence.
The company closed five months later because it could not obtain capital to continue operating.
- What I would do differently
Participate more in the testing with users
This project helped me improve my eye for design and learn how to design SaaS. Feedback reached me through the executive rather than from the sessions I sat in.
What I would do differently is test more and faster in the process, implementing cohort analysis to measure the impact of changes.
Reduce inconsistencies with a better design system and keep it updated.