Designing clarity into an AI-powered outbound platform

Duration: ~9 months · Collaboration: founder and development team · Status: implemented and released. All product screens in this case study use sample data.

01 — Overview

An outbound sales platform with many moving parts

Houdiny AI is an AI-powered outbound platform. Teams use it to find and organise leads, connect email and LinkedIn sending accounts, build multi-step outreach campaigns and manage replies in one inbox.

The core features already existed when I joined. My work focused on the authenticated web application (not the marketing site) and on how its modules work together as one outbound workflow.

My role: end-to-end product design

1. Evaluating the existing product and its workflows

2. Restructuring navigation and information architecture

3. Redesigning user flows, starting from wireframes

4. High-fidelity UI and consistent interface patterns

5. Onboarding, empty states and contextual guidance

6. Working with the founder and developers through implementation

Modules in the redesign: onboarding, guided product activation, dashboard, lead management, email outreach, campaign builder, LinkedIn automation, sequences, Unibox, email and LinkedIn accounts, profile and billing, and empty states.

02 — The challenge

The product had the functionality. The experience needed clarity.

Evaluating the original application, the problems were less about missing features and more about how existing features were organised, connected and presented.

Original dashboard (A) and original campaign creation (B).

• A · Fragmented information architecture. Navigation mixed different mental models: “My Agents” and “Tasks” sat beside “Campaign Manager”, and leads lived inside Tasks (Scrape List, Enrich Lists) instead of having a home of their own.

• B · Complex workflows. Creating a campaign meant moving through seven full-page steps. The only cues were a “Step 5 of 7” counter and a back arrow, with no persistent view of where you were or what came next.

• C · Inconsistent interface patterns. Pages alternated between centred wizard forms and full-width tables, and many actions ended on their own full-screen confirmation page, so similar tasks looked and behaved differently.

• D · Limited contextual guidance. Help lived on a separate “Get Started” page with a video and long-form text, away from the screens where people actually needed it.

• E · Disconnected modules. CSV upload, column mapping and enrichment sat inside campaign creation, so lead data had no place outside a campaign, and accounts, campaigns and replies felt like separate tools.

Sources: my own use of the product, a screen-by-screen review of the original interface, discussions with the founder, competitor review and conversations with developers. These are design observations, not results from formal user research.

03 — Discovery

Understanding the product before redesigning it

Before changing anything, I needed to understand how the existing modules connected, where the workflows broke down and what the team could realistically build.

1. Product evaluation. Used the product end to end to find where navigation, workflows and hierarchy got in the way.

2. Interface audit. Reviewed the original screens for information density, inconsistent patterns and repeated interactions.

3. Founder discussions. Aligned with the founder on product direction, priorities and design opportunities.

4. Competitor review. Studied relevant outbound tools and adapted useful patterns to Houdiny rather than copying them.

5. Developer collaboration. Worked with developers to understand existing functionality and technical constraints.

A sample of the original screens reviewed in the audit: My Agents, Tasks (Scrape List), campaign CSV upload, column mapping, campaigns listing and Unibox.

04 — Design strategy

One principle: Complexity → Clarity

Houdiny’s complexity was real: leads, accounts, sequences and replies all depend on each other. The goal wasn’t to hide that complexity but to make it easier to read. Three working principles turned that idea into design decisions.

1. Organise around the workflow

• Problem: features scattered across Agents, Tasks and Campaign Manager.

• Design response: navigation rebuilt around the outbound workflow (Leads, Campaigns, Unibox), with Accounts and Team as supporting areas.

• Visible result: each stage of the workflow has one clear home.

2. Make complex tasks easier to follow

• Problem: a seven-page campaign wizard with no overview of progress.

• Design response: five named stages in a persistent stepper, with completed stages checked off.

• Visible result: where you are, and what’s left, is always visible.

3. Create a cohesive product

• Problem: each screen solved its own layout, actions and feedback.

• Design response: a shared page anatomy: summary stats, search with one primary action, then a data table.

• Visible result: different modules read as parts of one product.

This chain is a way of communicating the reasoning. It describes design intent and visible changes, not measured user outcomes.

05 — Information architecture

Restructuring the product around the user’s workflow

The most important structural decision was to organise the application around how outbound work actually flows (find leads, run campaigns, handle replies) instead of around individual features.

Original structure

Reconstructed from the original screens and sidebar navigation.

• Main menu: Dashboard, My Agents, Tasks (campaign tasks, scrape list, enrich lists), Campaign Manager, Unibox, Email Accounts (domains, single sender emails) and My Team.

• New campaign flow: CSV upload → column mapping → enrichment → company info → sequences → schedule → settings.

• System: Subscriptions, Help Center and Logout.

• Lead data was created and managed in more than one place.

Redesigned structure

Reconstructed from the module groups and screens of the redesigned app.

• Home: dashboard and a get-started checklist for new accounts.

• Core workflow: Leads (lead search and filters, lists, import jobs, lead profile) → Campaigns (campaign list, Launchpad builder, campaign detail) → Unibox (replies with lead and campaign context).

• Supporting setup: Accounts (email domains, emails without a domain, LinkedIn) and Team (members, invitations).

• Settings: Profile and billing (profile, invoices, notifications, offers, integrations, subscription).

What changed. Leads became a module of its own. Lists, CSV import and lead search moved out of Tasks and out of campaign creation.

Why. Lead data, campaigns and replies are stages of one job. Giving each stage a single home makes the product’s structure match the work.

How modules connect. Campaigns pull from Leads lists, Schedule picks from connected Accounts, and Unibox shows which campaign each reply came from.

06 — Flagship: campaign builder

Turning a seven-step wizard into five clear stages

Campaign creation is where Houdiny’s complexity comes together: lead data, message sequences, sending accounts, schedules and launch settings. It was the clearest place to apply Complexity → Clarity.

The original experience

Upload or select CSV → Column mapping → Lead enrichment → Company info → Sequences (5 of 7) → Schedule (6 of 7) → Campaign settings → Launched. Each step was a separate full page.

Original campaign creation: lead source step and the schedule step (6 of 7).

1. Lead import buried in the campaign. Uploading and mapping a CSV happened inside campaign creation, so every campaign started with data work.

2. Progress as a counter. “Step 6 of 7” was the only signal of progress, and the steps themselves weren’t named or visible.

3. One-way navigation. A back arrow was the only way to move between steps, which made reviewing earlier choices slow.

Structure first, interface second

Before refining any screen, I mapped the existing steps and regrouped them into stages a person could hold in their head. Visual design came after the structure was agreed with the founder.

1. Map: list every step, input and decision in the original wizard.

2. Group: cluster related inputs into a small number of named stages.

3. Persist: decide what stays visible on every stage: progress, tips, primary action.

4. Refine: iterate the UI with founder feedback and developer input.

Five named stages

1. Basics: name, description and lead source (an existing Houdiny list or a new CSV).

2. Leads: review the leads that will receive the campaign.

3. Sequence: steps, A/B variants and delays, with preview and per-step save.

4. Schedule: sending accounts, timezone, days, interval and start date.

5. Launch: review tracking, out-of-office detection, stop-on-reply and delivery options.

The redesigned campaign builder

Redesigned Launchpad, sequence stage.

1. Persistent stepper. All five stages stay visible; completed stages are checked off.

2. Explicit sequence controls. + Step and + Delay sit directly under the steps they extend.

3. Variants in context. A/B subject variants are added inside the step they belong to.

4. Actions where you edit. Preview and Save Step sit above the message editor.

Basics: lead source chosen up front, with Quick Tips alongside. Schedule: sending accounts and timing in one place. Launch: every launch option reviewed on one page.

Building a sequence, state by state

The sequence stage was designed as a progression of states rather than a single screen, so the structure stays readable as a sequence grows.

1. Initial email. 2. A/B variant and a wait step added. 3. Follow-up email added after the delay.

Before and after: the schedule step

1. Counter → named stages. “Step 6 of 7” became a stepper showing Schedule in the context of all five stages.

2. Accounts with the schedule. Sending accounts are selected on the same stage as timing, as removable chips.

3. Guidance beside the form. Quick Tips explain sending limits, email health and warm-up while you configure.

4. Compact navigation. A slim icon rail replaced the wide text sidebar, giving the form more room.

07 — Supporting story: Leads

Giving lead data a home of its own

In the original app, lead lists were outputs of “Tasks”. In the redesign, Leads became a module where people search, filter, save and organise leads before any campaign exists.

Before: Tasks › Scrape List. After: Leads › Search.

1. From task output to module. Lists used to appear as task results. Now Advanced Search, Saved Leads and Lists sit together under Leads.

2. Filters grouped in one panel. Status, contact data, company, signals, location and job title live in a collapsible left panel.

3. Actions appear with selection. Selecting leads reveals Export, Add to List and Delete, keeping the default view quiet.

Lists: summary stats above a searchable table. Import jobs: CSV imports tracked with progress and status. Lead profile: contact, company and engagement history.

Two filter configurations in the file

The file contains two versions of the filter panel: one built around prospect attributes, the other around leads already in the workspace. Showing both, rather than only the final screen, reflects how the panel was worked through.

Left: the frame labelled “V1” (lead status, owner, contacted status, email, phone, company, education, email signals, buying intent, location, job title). Right: the guided-onboarding version (lead status, source, campaign, tags, list, date created, last activity, email engagement, company name).

08 — Supporting story: Unibox

A more coherent conversation experience

Replies are where campaigns turn into conversations. The redesign focused on keeping campaign and channel context attached to every conversation, so a reply never arrives without its backstory.

Before: sentiment filters, a system activity log and a contact panel shared three columns. After: a two-pane layout, with conversations on the left and the full thread with its context on the right.

1. Campaign context in the list. Each conversation shows which campaign it came from and the channel it arrived on.

2. Context in the thread header. Contact, campaign and More Details sit above the thread instead of in a separate column.

3. Reply on the right channel. The composer switches between email and LinkedIn, picks the sending profile and inserts templates with “/”.

09 — Guidance

Putting guidance where it’s needed

Instead of a separate help page, guidance moved into the product: a setup checklist on the home screen, coach marks on first visit, purposeful empty states and tips beside complex forms.

Home first-run checklist: new accounts see what to do next (connect accounts, upload leads, create a campaign). Guided onboarding: step-by-step coach marks introduce each area of the app on first visit.

Empty states for campaigns and email accounts explain the next step and offer one action. A conversational onboarding flow was also explored for first-time campaign setup.

10 — Consistency

One page anatomy across modules

This wasn’t a formal design system. It was a set of shared decisions applied module by module, so that learning one screen teaches you the next.

Leads › Lists, Campaigns, Accounts › Domains and Team share the same page anatomy.

1. Shared frame. The same icon rail and top bar, with credits and notifications in one place.

2. Summary first. Key counts sit at the top of list pages before the detail.

3. Search + one primary action. Search and the main action share a predictable position.

4. Consistent tables. Status pills, dates and row actions follow the same column logic.

11 — Collaboration

Designing alongside the development team

The redesign happened while the product was being actively built. Rather than a single handoff at the end, design and development moved in short loops: I explored, the founder weighed in, developers flagged what was feasible, and the design was refined before and during implementation.

Product evaluation → Design exploration → Founder feedback → Developer collaboration → Refinement → Implemented experience. Steps two to five repeated module by module throughout the nine months. This was a loop, not a straight line.

With the founder. Discussed requirements and product direction, reviewed design directions and fed back on iterations. That feedback shaped how several screens evolved.

With developers. Clarified existing functionality and constraints, resolved design questions as they came up, and adjusted designs where implementation needed it. I owned the design; engineering and release were the development team’s.

12 — Outcomes

What changed, and what we can honestly claim

It’s worth separating three things that are easy to blur: what changed in the design, what shipped, and what was measured.

Design changes

• Information architecture: workflow-oriented modules (Leads → Campaigns → Unibox), with Accounts and Team as setup.

• Workflow clarity: campaign creation reorganised into five named stages with persistent progress.

• Visual consistency: a shared page anatomy across leads, campaigns, accounts and team.

• Guidance: checklist, coach marks, empty states and in-context tips.

Implementation

• Implemented and released: the redesigned web application was built by the development team and released.

• Built incrementally: modules were redesigned and implemented over roughly nine months while the product kept evolving.

Measurement

• No formal post-launch study: the impact of the redesign wasn’t formally measured, so this case study makes no claims about conversion, activation or retention.

• What I’d measure next: time to first launched campaign, steps abandoned in the builder, and reply-handling time in Unibox.

Founder feedback shaped the iterations, but it isn’t quantitative evidence of user impact and isn’t presented as such.

13 — Reflections

What I learned redesigning a complex SaaS product

1. Information architecture shapes everything downstream. Moving Leads out of Tasks changed how campaigns, imports and the inbox could work. Structural decisions ripple through every screen.

2. Structure before polish. The campaign builder only came together once the stages were agreed. A refined screen can’t rescue a confusing sequence of steps.

3. Iteration is part of the work. Several areas went through more than one version. The first direction was a starting point, not the answer.

4. Design within real constraints. Working with developers throughout kept the design buildable and meant fewer surprises during implementation.

5. Consistency is functional. Shared patterns are what make separate modules feel like one product, and what make a new screen easier to learn.

6. Shipping isn’t validating. The redesign was released, but without post-launch measurement its impact is still an open question. Next time I’d set up that measurement from the start.

Complexity is easier to manage when the experience is clear.

Sales platform redesign · Data-heavy web app · Multi-module B2B SaaS · End-to-end product design · Founder and developer collaboration · Implemented and released