My Framer Site

PRODUCT DESIGN CASE STUDY

Car-O

Designing a trust-first car care ecosystem across a customer mobile app and an operations dashboard.

Customer mobile app

Dashboard web app

Research-led flow

AI-assisted iteration

My role covered research synthesis, user and customer interviews, problem framing, information architecture, mobile UX, dashboard UX, AI-assisted research and prototype iteration, design-system variables, component states, and handoff thinking.

PRODUCT TYPE

Car care service ecosystem

Customer app for booking, subscriptions, services, accessories, cart, and delivery. Web dashboard for operational control.

PRIMARY USERS

Customers and ops teams

Customers need simple choice and confidence. Admin teams need order, payment, customer, service, and item visibility.

PROJECT CHALLENGE

Make service feel reliable

The product had to reduce uncertainty around daily car cleaning, proof, payments, and service status.

PROCESS ADVANTAGE

AI accelerated the making

AI helped research faster, explore flows, generate variants, build variables, and produce prototype directions quickly.

01 / OVERVIEW

From car-cleaning idea to service operating system.

A senior portfolio case study should show judgment, not only screens. This version frames the work around the real product problem, the research inputs, the decisions you made, and how the final app and dashboard solve different parts of the same service journey.

The core problem

Customers want their car cleaned without chasing service people, guessing which plan fits, or worrying whether the work actually happened. Operations teams need a reliable way to see orders, staged jobs, ongoing work, completed service, customer records, payments, and service/item management without scattered follow-up.

The design response

I treated Car-O as a connected system: a mobile app that guides choice and purchase, plus a dashboard that gives the business operational visibility. The product logic centers on three questions: what does the customer need, what does the admin need to control, and what evidence keeps the service trustworthy?

The core problem

The design response

02 / DISCOVERY AND RESEARCH

The research goal was to understand trust, choice, and operational friction.

You described using extensive research, user interviews, customer interviews, and AI-assisted research. I framed those inputs into a clear discovery story that a product-design reviewer can follow.

CUSTOMER INTERVIEW THEME

Choice is confusing without context.

Users do not only compare prices. They need help deciding by car type, parking situation, exterior/interior frequency, timing, and service reliability.

USER INTERVIEW THEME

Proof matters after booking.

The design problem is not just conversion. Customers need a way to know what was booked, when it is scheduled, and what happens if service quality drops.

OPERATIONS INTERVIEW THEME

Status drives decisions.

Admins need quick views for staged, ongoing, and completed work, plus payment and customer information, so they can act before small issues become support load.

How I moved from inputs to product direction

Interview and observe

Collected user and customer needs around plan choice, trust, service timing, payment, and issue resolution.

Synthesize patterns

Grouped insights into recurring problems: decision overload, lack of service proof, status ambiguity, and admin follow-up load.

Use AI to speed research

Used AI to scan categories, compare flows, generate interview synthesis angles, and explore multiple IA directions quickly.

Prototype fast

Converted rough flows into mobile and dashboard prototypes, iterating layout and states faster with AI-assisted design-system work.

03 / PRODUCT STRATEGY

The product insight: make every service visible, configurable, and recoverable.

The product insight: make every service visible,configurable, and recoverable.

The final design is strongest when read as one ecosystem. The customer app handles selection and confidence. The dashboard handles throughput, exceptions, and operational memory.

Make plan choice guided.

The subscription flow uses vehicle, interior cleaning frequency, exterior cleaning frequency, package details, and price to help customers choose without needing sales help.

Make service status visible.

Home, services, tracker, calendar, delivery slots, and cart states keep customers oriented before and after purchase.

Make admin work scannable.

Dashboard tables, status tabs, payment records, customer details, service management, and item lists create a single operating surface.

Use AI where speed matters.

AI helped compress research, generate options, create variables, build design-system primitives, and rapidly produce prototypes for review.

04 / CUSTOMER MOBILE APP

The mobile app turns car care into a guided purchase and management flow.

The final app screens show a complete customer journey: home, subscription setup, service booking, tracker, accessories, delivery slots, address, and cart. The UX problem was not screen quantity. It was sequencing the right decision at the right moment.

Key mobile decisions

I used the mobile flow to reduce uncertainty in three places: choosing the right plan, booking a one-time service, and buying related accessories. The app separates subscription, services, accessories, and garage so each mental model has its own route.

IA split

Home, Services, Accessories, and Garage map to how customers think about the product.

Subscription logic

Vehicle, cleaning frequency, plan cards, package duration, and price create an explainable purchase path.

Post-purchase confidence

Calendar, tracker, selected date, time slots, cart, and delivery address reduce uncertainty after selection.

05 / DASHBOARD WEB APP

The dashboard translates messy service operations into status, records, and control.

The web app is the operational side of Car-O. It gives the team staged, ongoing, and completed order views, customer data, payment records, item/service management, and admin flows that would otherwise live in chats or spreadsheets.

Operational surfaces designed for scanning

The dashboard prioritizes table density, status categories, filters, and clear records. It solves a different user problem than the mobile app: admins need to monitor throughput and recover from exceptions quickly.

06 / AI-ASSISTED DESIGN PROCESS

AI helped me move faster without skipping product judgment.

The strongest point to communicate is that AI did not replace design thinking. It compressed the slow parts: research scanning, synthesis prompts, flow variants, visual iterations, variables, tokens, and prototype production.

Where AI accelerated the work

I used AI as a production and thinking accelerator: to explore category research, generate interview synthesis directions, pressure-test user flows, create design-system variables, produce component states, and iterate prototypes faster. The final UX decisions still came from the product problem: trust, status, choice, and operational control.

Research acceleration

Prompted AI to scan common car-service patterns, compare flows, and produce questions for user and customer interviews.

Flow iteration

Rapidly explored alternate subscription, service booking, cart, and admin-table structures before choosing the clearest sequence.

Design-system production

Used AI to speed up variables, reusable styles, component states, naming, and consistency checks that normally take significant setup time.

Prototype output

Turned decisions into more polished prototypes faster, allowing more cycles of critique and refinement.

07 / DESIGN SYSTEM AND COMPONENTS

The design system made fast iteration possible.

A senior case study should show that the work can scale. I framed the design-system effort around variables, reusable components, states, and handoff clarity because those are the parts AI can accelerate but designers still need to govern.

System work that supported the prototype

The project used a reusable visual language across app and web: purple for primary actions, structured white cards, status colors, rounded input surfaces, table rows, navigation states, and component patterns for repeated screens. AI helped produce foundations quickly, but the system choices had to support real app behavior.

Primary action

Action hover

Trust/assist

Success

Warning

Failure

Ink

Surface line

Component coverage

Navigation

Bottom app bar, dashboard rail, top nav, and section tabs.

Cards

Plan cards, accessory cards, cart cards, customer records, and dashboard panels.

Forms

Search, OTP, date, slot, address, coupon, payment, and add-order inputs.

Tables

Staged, ongoing, completed, customer, payment, and item management tables.

States

Selected, active, pending, completed, payment, inventory, and delivery states.

Handoff logic

Reusable patterns make engineers less dependent on guessing hidden behavior.

08 / FINAL PRODUCT STORY

Two products solving one service problem.

The final case study should make the evaluator understand your product thinking: the customer app creates demand and confidence; the dashboard gives the business a way to fulfill, track, and recover that promise.

End-to-end outcome

Car-O now reads as a complete ecosystem instead of disconnected screens. The mobile product helps a customer select a model, choose a subscription, book a service, buy accessories, manage address and delivery, and complete checkout. The web product helps the operations team monitor order status, customer records, payments, service definitions, and item workflows.

Skills demonstrated

UX research

Customer interviews

User interviews

Research synthesis

Product strategy

Information architecture

Mobile UX

Dashboard UX

Design systems

AI workflow design

Rapid prototyping

Handoff thinking

What I would validate next

1. Time to choose a subscription plan

2. Drop-off between service selection and checkout

3. Comprehension of interior vs exterior cleaning frequency

4. Cart and delivery-slot completion rate

5. Admin speed to find staged, ongoing, and completed orders

6. Payment lookup and customer-record lookup time