DaylineSelf-Initiated UI/UX ConceptFictional business and sample data. Not a real company or client work.Read The Case Study ↓
Case Study

Dayline

Self-Initiated Product ConceptFictional Service-Operations Product12 Screen States

Not client work. All people, businesses and data are fictional samples.

The Project

Dayline is a service desk and scheduling tool for a fictional small repair business, Northline Home Services. It is built for the office coordinator, who takes in requests, assigns technicians, books visits and keeps customers informed. The owner and technicians are secondary users.

A self-initiated product concept. There is no real business, no real users and no deployment behind it.

The Problem

In a small service business, requests can arrive by phone, message or web form. That makes it hard for one coordinator to see at a glance what needs attention, who is assigned, when a visit is booked and what the customer has been told.

How might one workspace make triage, scheduling and customer updates clear for a coordinator handling them all day?

This is a design framing I set for the exercise. It is not a finding from research.

The Goals

  • Make urgent and unassigned work visible.
  • Keep request information together.
  • Make technician availability understandable.
  • Prevent scheduling conflicts.
  • Make customer communication clear.
  • Support the coordinator's next action.

The Thinking

Every screen answers the same five questions, in the same order:

  1. What needs attention
  2. What is happening
  3. Who owns it
  4. When it happens
  5. What the customer knows

The core workflow follows the same logic:

  1. Request
  2. Triage
  3. Assign
  4. Schedule
  5. Resolve conflict if needed
  6. Update customer
  7. Confirm

The Process

  • Define: the coordinator, the problem and the design question.
  • Map: the request-to-confirmation workflow and a 12-state screen set.
  • Prototype: a clickable, responsive app with sample data.
  • Test the flow: I clicked through the main path and the conflict recovery myself to check they worked.
  • Refine: fixed layout problems found along the way, such as cramped rows in the customer profile.

These were functional checks. No user research, interviews or usability testing were done.

The Interface

Eight of the 12 states, rendered from the real prototype.

TodayWhat needs attention first, then today's visits.
Request InboxEvery request with status filters, search, loading and empty states.
Request DetailStatus, owner, visit and what the customer was told, together.
ScheduleTechnician lanes by day, with booked, open and off time visible.
Book a VisitPick a technician, day and time. Busy slots are marked.
Scheduling ConflictExplains what clashed and offers ways forward.
Customer UpdateAn editable message with a preview before sending.
ConfirmationShows what was booked and whether the customer knows.

The Interaction

The main workflow:

  1. Today
  2. Request
  3. Booking
  4. Customer Update
  5. Confirmation

Conflict recovery:

  1. Book a Visit
  2. Scheduling Conflict
  3. Alternative
  4. Customer Update
  5. Confirmation

Try The Conflict opens Book a Visit with Gwy Squish at 10:00 AM selected. Press Book Visit to see it.

Design Decisions

Desktop-First

The coordinator works across many records, so the wide layout comes first.

Mobile Adaptation

The same product reflows to a bottom tab bar and stacked lists at phone width.

Status Hierarchy

Status labels use an icon and text, never color alone.

Dense But Readable

Compact rows with clear spacing keep many requests scannable.

Inline Validation

Errors appear beside the field and say how to fix them.

Visible Conflicts

Busy slots are hatched and labeled before booking.

Actionable Recovery

The conflict screen offers the next open slot or another technician.

Persistent Labels

Every form field keeps a visible label.

Update Before Done

Booking leads to a customer message, and Confirmation says whether the customer was told.

Reflection

Dayline explores how an internal tool can reduce ambiguity around requests, ownership, scheduling and communication. It is a self-initiated concept without real-world research or usability testing, so it shows design reasoning and execution, not proven outcomes. A next step would be testing the booking flow with real coordinators.

Concept only. Fictional business, fictional sample data. Not client work.