1. The brief, and how I read it
The ask was to redesign two pages: the Contacts list and a single contact's page. I treated that as a product question before a visual one. What do these two screens need to do for the people who run a career school, and what on them would move the three outcomes Lumion sells on its own homepage: fill more seats, collect more tuition, graduate more students?
Read that way, the pages are not a directory. They are where an admissions advisor decides who to contact next, where a bursar sees who owes what, and where a director spots the applicant who has been quietly stuck for a month. The redesign follows from that reading.
2. What I found in the current pages
Both pages are stock Filament admin scaffolding. They are tidy, and they are honest about the data model. The problem is that neither tells anyone where a person is in the lifecycle or what to do about it.
Contacts list
- No lifecycle context. The columns are Name, Phone, Email, Labels, Contact Score, and Added. There is no stage, program, owner, last activity, or next step.
- Low density. About 13 rows fit on a screen because of 40px avatars and tall rows, and four of the six columns are almost entirely dashes.
- Duplicates are invisible. Aisha Johnson, Anna Kowalski, and David Kim each appear twice with nothing to flag it. In a school CRM that is a real, recurring problem, not demo noise.
- Filtering is hidden and misleading. Filters sit behind an icon with a badge. The one active chip, "Score: Enrollment Likelihood", filters nothing, because every value underneath it is set to Any.
- No hierarchy in the header. Import, Export, and New Contact are three identical dark buttons. Labels and Custom Fields, which are settings, sit as centered tabs beside the primary list.
- Small frictions. Names read "Last, First" while initials are first-last. Two search boxes are visible at once. Bulk actions only appear after you select something.
Contact page
- The header says nothing. A name and five buttons. No stage, program, owner, balance, or next step.
- The one meaningful fact is the smallest text on the page. David has been in School Approval for a month. That lives in the right rail in 11px type.
- A wall of empty states. Six stacked cards with nothing in them, two of which offer a search box over zero items.
- The wrong things are prominent. An internal UUID sits in the main card. First Name and Last Name repeat the title.
- Nine tabs that mirror backend modules, with no counts, so you cannot tell which ones have anything in them.
- No unified timeline. Communications, Journey Activity, Form Submissions, and Payments are four separate tabs. That is the opposite of "one record".
- No way to reach the person. For a product built on texts, email, voice, and Mia, there is no call, text, or email affordance on the contact.
- AI is scattered across Contact Scores, AI-visible details, and AI learnings, in three unrelated cards.
- "Delete Contact" sits next to "Permanently delete contact" in the same menu.
3. Who the pages serve
Three people use these two screens for three different jobs. The design has to work for each without becoming three products.
Admissions advisor
Works a follow-up queue of 50 to 150 open leads. Lives in texts.
Needs who do I touch next, and why. Wants to see stage, how long someone has sat there, when they last replied, and the next step, and then act without leaving the row.
Financial aid / bursar
Collects deposits and tuition, builds payment plans, chases past-due balances.
Needs balance, plan, and past-due at a glance, side by side with enrollment status, because a payment plan and an approval usually block each other.
Director / owner
Runs the school. Watches seats per cohort and where the pipeline leaks.
Needs stalls and duplicates to surface on their own, wants Mia's work visible and reviewable, and cares about seats filled per start date more than any single contact.
4. Design principles
Five rules, applied to both pages. Every change below traces back to one of them.
- Lifecycle firstStage, time in stage, and the next step appear on every row and at the top of every record.
- Density with hierarchyMore rows per screen, but the thing that needs attention is the thing that stands out: a stalled stage, an overdue task, a past-due balance.
- Action over informationEvery screen has an obvious next action, and the primary button changes with the stage. In School Approval, it says Approve application.
- Progressive disclosureEmpty sections collapse to a single "Add" line. Internal IDs live behind a copy button. Nothing gets a search box until it has something to search.
- Mia as a colleague, not a widgetOne place for her read, with scores explained, learnings visible, sensitive fields excluded, and a "not helpful" button so the feedback loop exists.
5. What changed and why
Each change is paired with the problem it solves, the hypothesis behind it, and how I would know whether it worked.
| Change | Problem it solves | Hypothesis | How I'd measure |
|---|---|---|---|
| Contacts list | |||
| Saved views with live counts (All, Needs follow-up, New leads, Applicants, Enrolled, Past due, At risk) | The list has one flat view; the useful filters exist but nobody finds them. | Advisors start their day from Needs follow-up instead of scrolling All. | Time to first action on the page; share of sessions that open a saved view. |
| Lifecycle columns: stage, program, owner, likelihood, last activity, next step | Columns show contact details, not where someone is or what to do. | Rows become decisions, not lookups; fewer clicks into records just to check status. | Percentage of leads with a next step set; record opens per action taken. |
| Preferred channel under the name; phone and email as optional columns | Two mostly-empty columns spent on data that rarely changes a decision. | Showing the channel a person actually answers on gets used more than a raw phone column. | Column-picker usage; quick-action clicks by channel. |
| Visible filter chips and a filter panel | Active filters are hidden behind an icon, and the visible chip filters nothing. | People trust the list when they can see what it is filtered by. | Filter-panel opens per session; chip removals; support tickets about "missing" contacts. |
| Duplicate banner and row badge, with a merge review | Form re-submissions create silent duplicates that split a person's history. | Surfacing likely duplicates gets them merged instead of both being worked. | Duplicates merged per week; double-contact incidents reported by schools. |
| Hover quick actions (call, text, email) and a persistent bulk bar | Bulk actions are hidden until something is selected; no way to reach a person from the list. | Follow-ups happen from the list, so more happen. | Follow-up latency from inquiry to first human touch; quick-action clicks per row viewed. |
| One primary button; Import, Export, and settings demoted to a menu | Three identical dark buttons and settings tabs compete with the list itself. | A single New Contact button is found faster and misclicks on Export drop. | Export clicks that are cancelled within 5 seconds; time to New Contact. |
| Recency sort by default and a stall indicator ("31d in stage · typical 3") | Alphabetical sort buries what is happening now; stalls are invisible. | Stalled applicants get touched sooner when the stall is on the row. | Stalled applications, defined as more than three times the typical time in stage. |
| Contact record | |||
| Summary strip: stage, likelihood, responsiveness, balance, next step | The header is a name and five buttons; the key facts are scattered or missing. | Anyone can read the situation in five seconds without scrolling. | Time to first action on the record; scroll depth before the first click. |
| Contextual primary action (Approve application, as a split button) with a Call / Text / Email group | Five equal buttons, none of which is the thing this stage needs, and no way to reach the person. | The right next action is taken more often when it is the biggest button. | Approval turnaround from application to decision; outreach started from the record. |
| Mia's read: a recommendation, the evidence for it, Draft the text, and Not helpful | AI output is split across three cards and never says what to do. | A recommendation with visible evidence gets acted on; one without gets ignored. | Reply rate of Mia drafts sent versus not; Not helpful rate by recommendation type. |
| Composer for Note, Text, Email, Log call, and Task | Communicating means leaving the record. | Logging and outreach go up when they take one click. | Notes and messages logged per record view. |
| Unified timeline, grouped by day, with filters | Communications, forms, payments, and stage changes live in four tabs. | One stream is what "one record" means in practice; fewer tab hops per question. | Tab switches per session; time to answer "what happened last". |
| Journey stepper with time in stage and what the stage blocks | The journey card is small, and nothing says the stall is holding up the agreement. | Naming the blocker gets the blocker cleared. | Stalled applications; days from approval to agreement sent. |
| Rail cards for Tasks, Details, Money, and What Mia has learned | Money is on a different page; AI learnings are an empty box at the bottom. | Bursars and advisors get their view without switching tabs. | Past-due contacts touched within 7 days; payment plans sent from the record. |
| Fewer tabs with counts; Attendance explains when it starts; empty sections collapse to an "Add" line | Nine tabs with no counts and six empty cards. | Less empty UI means people read what is there. | Bounce from the record within 10 seconds; tab usage by count. |
| Safer delete: archive with a 30-day undo, permanent erasure as an explicit checkbox | Two delete options sit next to each other in one menu. | Accidental permanent deletes go to zero without slowing real erasure requests. | Restores from archive; erasure requests completed. |
The metrics, in one place
- Time to first action on each page
- Follow-up latency: inquiry to first human touch
- Leads with a next step set, as a share of open leads
- Stalled applications: more than 3× the typical time in stage
- Duplicates merged per week
- Past-due contacts touched within 7 days
- Reply rate of Mia drafts sent versus not sent
- Approval turnaround: application submitted to decision
6. What I deliberately kept
The navy sidebar, the top bar with Ask Mia and Quick Actions, Inter, the indigo primary, and the Filament-style cards and pills are all Lumion's. I kept them on purpose so the prototypes read as the next version of the product, not as a foreign design dropped on top of it.
The existing filters, bulk actions, column toggles, and the Labels and Custom Fields settings all still exist. They moved to where people will find them, and the ones that were hidden became visible. Nothing a school relies on today was removed.
7. How I would ship it
Not as one release. Three slices, each useful on its own, each behind a per-school flag.
v1
- List: stage, last activity, and next step columns
- Saved views with counts
- Visible filter chips
- Duplicate banner
- Record: summary strip, timeline, Mia's read
v2
- Composer on the record
- Contextual primary action by stage
- Money card and payment-plan entry point
- Archive-and-undo delete flow
Later
- Shared saved views per team
- Column memory per user
- Merge tooling with field-level choice
- Stage-specific recommendations from Mia
How I would validate it
Five sessions with admissions advisors at two or three schools, each doing two tasks on the prototype: "start your morning" and "handle this stalled applicant". Then instrument the metrics above, ship v1 to a handful of schools behind the flag, and compare four weeks before and after.
Risks and mitigations
- "Typical days in stage" needs historyA new school has no baseline, so the stall indicator would be silent or wrong.Fall back to Lumion-wide medians per journey stage until a school has enough of its own data, and say which one is in use.
- Mia's read can lose trust fastOne confident, wrong recommendation and advisors stop reading the card.Always show the evidence line, always offer Not helpful, and use that signal to suppress recommendation types that get rejected.
- List performance at scaleSaved-view counts and recency sort across 50,000 contacts will not work client-side.Server-side views with cached counts and virtualized rows; the prototype's behavior is the spec, not the implementation.
- Duplicate detection false positivesTwo real people can share a name; a bad merge is worse than no merge.Match on email or phone plus name, suggest only, never auto-merge, and keep the archived record restorable.
8. Open questions for the Lumion team
Things I would want answered before building any of this. Several would change the design.
- Is "stage" always a Customer Journey stage, or can a contact sit in several journeys at once? If several, which one does the list show?
- Where does financial-aid packaging live today? The Money card assumes FAFSA results and a payment plan are visible from the contact.
- Does Mia have a task and owner concept, so that "Mia: first-touch text" can be a real next step with a due time and an escalation path?
- What does Contact Score mean to schools today, and is 0 to 5 the right scale? Two scores on a five-point scale may be too coarse to sort on.
- Which of the nine detail tabs get real traffic? I collapsed them to six on judgment, not data.
- How do schools handle a contact who is both an active student and a lead for a second program? One record with two journeys, or two records?