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. |
| Name order as a per-school display preference (First Last or Last, First); sort always follows display | Names read "Last, First" while initials and messages use first-last; sorting a First Last column by surname looks broken. | Schools that live by rosters keep surname order; everyone else gets a list that sorts the way it reads. | Preference chosen per school; support tickets about "wrong" sort order. |
| Cohort strip above the list: seats filled, awaiting decision, in pipeline, per start date; click to filter | Nothing on the list connected to seats or tuition, the two things Lumion sells on; the bursar and director had no artifact here. | Advisors and directors work from the cohort that starts next, not from the alphabet. | Seat fill at start date; awaiting-decision aging per cohort. |
| Balance column, on by default in Past due and At risk views | Money lived only on the record. | Past-due follow-ups start from the list when the amount is visible. | Past-due contacts touched within 7 days; past-due aging. |
| Queue behavior: acting on a row (text, call, email, mark done) updates it; rows that no longer qualify fade out with undo; j/k/Enter/x/t/d keys as a starting set to validate, not a spec | Needs follow-up is a queue, not a table, and the original gave no way to work it in order. | Working a queue top to bottom beats scanning, and undo makes it safe to move fast. | Rows actioned per session; time to drain Needs follow-up each morning. |
| Caught-up and first-run states per view ("You're caught up. 11 applicants are waiting on a decision →") | Zero is the goal state of a queue and the day-one state of a new school; neither was designed. | A hand-off to the next useful view keeps people moving instead of leaving. | Click-through from empty states; day-one import completion. |
| 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. |
| Approve is a confirmation that names its consequences: seat held, agreement sent, deposit unlocked, stage moved, approver recorded | Approval was one of five equal buttons, yet it holds a seat and starts a contract. | Naming consequences prevents accidental approvals without slowing deliberate ones. | Approvals reversed within 24 hours; approval turnaround. |
| Merge review: side-by-side records, field-level choice, history stays linked, archived copy restorable | Duplicates were invisible, and "merge" is where a CRM usually loses data. | A visible, reversible merge gets used; an opaque one gets avoided. | Duplicates merged per week; merges restored. |
| Consent provenance on the phone number, audit lines on stage changes, and Mia's permission boundary stated on the record | Career schools answer to accreditors, Title IV, and consent rules for texting and calling. The specifics are a question for their compliance lead (see section 8), but a CRM that texts and calls should be able to show who consented, who approved, and what the AI may do unsupervised. | Compliance visible in the workflow costs nothing day to day and answers a reviewer's first questions without a records hunt. | Consent coverage of texted contacts; audit-log lookups; Mia escalations per week. |
| 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
None of these has a baseline in what I was given, and inventing targets would be worse than none. In week one I would ask the data team for four numbers as they stand today: follow-up latency, approval turnaround, stalled applications, and past-due aging. Targets come from those.
6. What I deliberately kept
Phones are covered, not redesigned. Both prototypes work at phone width. The record collapses to the summary strip, Call, Text and Email, and the timeline, which is what an advisor needs between tours. The list scrolls sideways as a table, which is fine for checking a name and wrong for working a queue on a phone. That pass is listed under Later, on purpose.
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 · mostly reads data that exists
- List: stage, last activity, next step columns (frontend; next step is a query on existing tasks)
- Saved views with counts (backend: server-side views with cached counts)
- Visible filter chips (frontend)
- Stall indicator (backend: median days per stage per school, Lumion-wide fallback)
- Duplicate banner (backend: nightly match on email or phone plus name)
- Record: summary strip and unified timeline (backend: one events feed across messages, forms, payments, stages)
- Mia's read (AI: prompt over the events feed with evidence citations and "not helpful" logging)
v2 · new writes and rules
- Composer on the record (backend: send and log through existing messaging)
- Contextual primary action and the approve confirmation (frontend plus a rule per stage)
- Cohort strip and balance column (backend: seat capacity per cohort is a new field; balances from Payments)
- Queue behavior with undo and keyboard (frontend)
- Money card and payment-plan entry (reads Payments)
- Archive-and-undo delete (backend: soft delete and restore)
- Merge review (backend: merge with field-level choice and history stitching)
Later
- Shared saved views per team; column memory per user
- Consent provenance and audit-log viewers (backend: consent records with source and timestamp; audit events)
- Mia's autonomy rules per stage, managed in AI Teams
- Stage-specific recommendations from Mia
- A phone-first pass on the list: a queue, not a table
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?
- Which consent and audit records do schools actually get asked for, by accreditors, in Title IV reviews, or after a texting complaint, and does Lumion hold them today? I showed consent provenance and audit lines on the record on the assumption that the answer is "yes, and it should be visible"; the compliance lead would know.