Every tool in this space starts from the same assumption: people use their phones too much, so the answer is to take the phone away. Blocks, locks, timers, forests that die if you leave the app. Our research said that assumption is wrong - or at least that it aims at the wrong moment.

The problem isn’t that people start scrolling. It’s that nothing tells them to stop. A session that began as a deliberate two-minute check has no natural endpoint, no completion signal, no edge. It ends when something external interrupts it, and the person surfaces with no idea how long they were gone.

Drift is a system that detects that slide and reintroduces stopping cues progressively - four escalating levels, from a one-second Dynamic Island glance up to a user-defined containment window. It never blocks. Level 4, the only level with real teeth, is off by default and can only be switched on by the user for hours they choose themselves.

The problem we defined isn’t excessive screen time. It’s the combination of emotionally triggered initiation, cue-driven reinforcement and weak internal stopping mechanisms that leads to unintended continuation - mainly among young adults.

That reframing is the whole project. It moves the target from how long someone uses their phone to why the session never closes, and it changes what a solution has to do.

Who it’s for

• 18-28 year olds - university students and young professionals.
• Heavy users of Instagram, TikTok and YouTube Shorts.
• Motivated but failing - they want to cut down, and restriction tools have already let them down.
• Emotionally triggered - the phone is the default response to boredom, stress and loneliness.
• Time-unaware - losing track of session duration is consistent, not occasional.

Secondary - behavioural evidence

• Habits form through cue-response repetition in stable environments. Disrupting them needs environmental restructuring, not willpower. Wood & Neal (2007)
• Salient stimuli capture attention automatically, even when irrelevant to the current goal. Notifications exploit this directly. Theeuwes (2010)
• Habitual checking becomes more pervasive over time - session length and frequency rise as the behaviour automates. Oulasvirta et al. (2012)
• Behaviour precedes intention. The habit loop fires before awareness does. Neal, Wood & Quinn (2006)
• Dashboards alone don’t change behaviour. Showing usage statistics doesn’t produce sustained change; that needs friction, environmental restructuring and motivation alignment. Nielsen Norman Group

Primary

• Four in-depth interviews, analysed through thematic affinity mapping.
• A 20-person survey. 65% reported an hour or more on their phone after 9pm. None of the twenty found existing tools very helpful.
• All four interview participants had deleted third-party restriction apps - the single finding that shaped the entire design direction.

Six stages, mapped from the interview data - how an emotionally triggered start becomes an unintended two-hour session.

The insight the whole system rests on: the problem is not the initiation of phone use. It is the structural absence of stopping cues during continuation. Every existing tool intervenes at initiation, which is the one stage users defend most and the stage least responsible for the outcome.

We weren’t designing a restriction tool. We were designing a session-boundary reinforcement system that surfaces patterns users cannot currently see.

Why it looks like a system app, not a wellness app

All four interview participants had deleted third-party restriction apps. A tool that reads as native avoids the add-on stigma - it feels like part of iOS rather than something bolted on and therefore deletable. The visual language borrows deliberately:

• Apple Health - layered dark surfaces, SF Pro, system type scale.
• Apple Settings - grouped lists and toggle patterns.
• Dynamic Island - within-session, ambient, non-interrupting.

The Dynamic Island choice matters more than it sounds. It’s the only surface on the phone that can speak during a session without leaving the app the person is in - which is exactly where a stopping cue has to land.

Existing tools jump straight to Level 4. Drift operates at Levels 1-3; Level 4 is optional and user-enabled only. That’s a direct consequence of the research - all four participants abandoned tools that felt punitive.

• L1 - Notice. The Dynamic Island expands for one to two seconds: “18 minutes continuous.” Soft haptic, 300ms, auto-shrinks, no interaction required. Restores time consciousness without interrupting flow.
• L2 - Pause. A boundary prompt: “You’ve been scrolling continuously. Continue intentionally?” Take a 10-second break, or ignore it and it collapses. Re-engages conscious decision-making.
• L3 - Structure. Progressive friction. A three-minute wrap-up mode that creates a natural endpoint. The session is never blocked - completion is what ends it.
• L4 - Contain. User-defined containment for the most vulnerable hours. Cannot be dismissed by tapping outside; a choice is required. Off unless the user turns it on for a window they set.

Each escalation level got its own flow diagram, because the branch logic differs at every step - what happens on ignore, on tap, on timer completion, and what conditions have to be true before the next level can fire at all.

The Dynamic Island work started on paper, because the constraint is spatial before it’s visual - there are only so many words that fit in an expanded island, and the whole intervention has to survive being read in under two seconds.

A dark system-native palette with defined state colours, four dark steps and four light steps - built so that every surface in the app is a token rather than a one-off value.

Onboarding does one job: set the expectation that this is not a hard block. P2's scenario turns on that single sentence landing before anything else.

A system that interrupts people during their most vulnerable hours has a higher duty here than most products. A WCAG 2.2 review of the delivered designs, written as acceptance criteria for build.

Built in by design

• The first cue is non-visual. Level 1 pairs the Dynamic Island expansion with a 300ms haptic, so the signal reaches someone who is not looking at the top of the screen or cannot read it at a glance.
• Nothing is ever blocked. Every level preserves the choice to continue, which removes the dead ends and forced errors that make restriction tools hostile to users with cognitive or attention differences.
• Ignoring is a valid response. Level 2 collapses on its own if untouched. No modal traps focus, and no prompt requires interaction to dismiss.
• Duration is stated, never implied. "18 minutes continuous", a visible 10-second countdown, a three-minute wrap-up: elapsed and remaining time are always numeric rather than inferred from an animation.
• Level 4 cannot surprise anyone. The only level with real friction is off by default and enabled by the user for hours they choose themselves.
• Escalation is gradual. Each level adds a decision rather than a restriction, which keeps cognitive load proportionate to how far a session has drifted.

To resolve before build

• Dynamic Island copy sits close to the minimum legible size. It needs testing at the largest Dynamic Type settings, with a defined truncation rule when text reflows.
• Promotion and session status pair a coloured dot with a word in some places and rely on colour alone in others. Every status needs its text equivalent.
• The weekly scroll chart encodes duration by bar position and length only. Each bar needs an accessible value, and the view needs a table equivalent for screen-reader users.
• The Level 2 screen blur is a significant visual change with no announced equivalent. It needs a live-region announcement and a stated behaviour under Reduce Motion and Reduce Transparency.
• Stage labels in the weekly and daily views fall below 4.5:1 against the tinted panels at their current weight and need darkening or enlarging.
• Timed interactions need a documented extension path for users who cannot respond within ten seconds, in line with WCAG 2.2 Enough Time.

Not tested with assistive technology or with disabled participants. The points above are a design review, not validation.

The thing being tested wasn’t whether people could find a button. It was whether the escalation model is understandable, behaviourally coherent, and read as supportive rather than punitive - because the research says punitive tools get deleted.

Methods: think-aloud protocol for verbalised reasoning, plus behavioural observation of navigation patterns, hesitation points and error rates.

What held up

• L1 - P1 immediately read “18 minutes continuous” as time awareness, and said it would probably make him come off it. Non-intrusive; doesn’t break flow.
• L2 - “Take a pause?” was clear, and the two-option structure was understood correctly. The 10-second timer concept was validated.
• L3 - P1 framed the scroll freeze as supportive: it forces attention onto the prompt rather than the content. Three minutes felt appropriate; two extensions felt fair.
• L4 (round 2) - “A lot better.” Close App plus a three-second hold-to-continue validated as a distinct escalation.
• Controls structure - both participants validated the two-section split of Scrolling Support and Notification Batching.
• Visual direction - P2 described it as an extension of iOS Settings; clean, not heavy. That was the design concept’s central bet, confirmed.
• Session summary - P1 expected a summary after closing the app, which validated the View Summary approach.

What changed between rounds

Level 4 did not hold up first time. It was rebuilt as Close App plus a three-second hold-to-continue, and the second round validated it as a distinct escalation rather than a repeat of Level 3. The rest of the model carried through both rounds unchanged.

The first main-app version was closer to a conventional wellness dashboard - a light summary screen, a balance-style score, mode switches. It was legible, but it was the thing the research warned about: a dashboard, presenting statistics, which the evidence says does not change behaviour on its own.

Then

• Language moved from metrics to behaviour. “Average session 18 min” became “2 long scroll sessions, 2 ended shortly after, 1 needed stronger support” - a description of what happened rather than a number to be judged by.
• Controls split into two named groups - Scrolling Support and Notification Batching - which testing then validated.
• The clock-face high-risk window was replaced by a plain sensitive-hours timeline, readable at a glance.
• Pattern views gained a time dimension - Today and This Week, with a weekly chart showing when long sessions actually cluster, and a prompt offering to update sensitive hours to match the real pattern.

What shipped

• A complete iOS concept across three surfaces: seven onboarding screens, a two-tab main app with daily and weekly pattern views, and a full Dynamic Island escalation sequence from first notice to session summary.
• A four-level escalation model with a per-level user flow, tested with participants and revised between rounds.
• A tokenised dark design system with state, dark and light ramps.
• Nine hypotheses verified before a single screen was sketched - every design decision traceable to a survey finding, an interview quote or a cited source.

What I’d take from it

• Reframing the problem was worth more than any screen. The industry frames this as excessive screen time; the research showed it’s session-boundary erosion. Changing the problem changed the entire solution space.
• Behaviour beats demographics. The persona isn’t defined by being 22 and a student - he’s defined by emotionally triggered initiation and absent stopping cues. That’s what made the design decisions fall out cleanly.
• Preserving choice is a design constraint, not a nicety. The evidence was unambiguous that restriction triggers resistance and abandonment, so every level had to leave the decision with the user.

Hardest parts

• Avoiding time-based design logic - the obvious solution is a timer, and the research says a timer is the thing people delete.
• Making each escalation level meaningfully distinct in testing rather than four versions of the same prompt.
• Preserving autonomy while friction increases.
• Keeping research-to-design traceability across every iteration decision.

MakeAssure is a B2B marketplace website. Buyers come to find a local seller they can trust.

My main challenge was deciding where both audiences could share a system - the header, product cards, ratings - and where they needed to split, which turned out to be everything after sign-up.

I designed the full journey: sign-up and OTP verification, marketplace browsing, product pages with ratings and seller details, customer and seller dashboards, listing creation, paid promotion and referral credit, all as responsive web and native mobile screens.

Four pressures shaped the interface, each visible in how the screens allocate space:

• Trust. Buyers need to know a seller is real before they call. The product detail page gives roughly a third of its space to seller details, ratings breakdown and a report/block control.
• Proximity. Location sits in the header on every screen, and the home page search pairs a location filter with the product query.
• Effort of listing. A seller has to be able to post a product with photos, price and description in a single uninterrupted form.
• Proof it worked. Sellers who pay to promote need reach, spend and remaining budget visible without asking anyone.

The product splits its users at the first screen: sign-up asks you to choose seller or customer before anything else, and the two paths never fully rejoin. Everything downstream - dashboard, permissions, primary action - follows from that choice.

Two scenarios account for almost all traffic on a marketplace, and the design resolves both end to end.

Buyer sourcing a product

• Lands on home, sets location in the header, searches by product or service name.
• Scans category tiles or the popular / recommended / suggested post rails.
• Opens a product: images, specifications, size options, price against a struck-through original, availability.
• Checks the ratings snapshot and the per-attribute customer ratings before committing.
• Reveals the seller’s number, requests a best price, or chats - and can report or block the seller from the same block.

Seller listing and promoting

• Signs up as a seller, pins a location, confirms by OTP.
• Posts an ad: category, seller details, title, description, price, up to five photos.
• Returns to the dashboard to see posts, page rating, followers and promo points.
• Promotes a post - picks an objective, targeting and budget against a date range.
• Opens insights to see status, budget, remaining spend and impressions; checks transaction history.

A persistent header carries the four things that never stop being relevant - brand, location, business page, account - plus the primary action, Post your ad, which is the only button given a filled pill on the whole header. On mobile that same hierarchy becomes a five-item tab bar.

Sign-up carries the whole product’s split, so it had to be the shortest possible route to the right dashboard. Phone-first with an auto-read OTP keeps typing to a minimum on mobile, and an explicit Continue without account link means browsing is never gated.

The system is deliberately plain, because the content it carries - product photography from thousands of unrelated sellers - is not. A single royal blue does the work of brand, primary action and link; everything structural is white cards on a light grey field with thin blue-tinted borders.

• One accent, three jobs. Filled blue for primary actions, outlined blue for secondary, blue text for links and contact details. Rating stars are the only other colour, in amber, so they read as data rather than as another button.
• Cards as the unit. Every listing is the same card - image, title, seller, location, price, two actions - so the home rails, the seller’s post grid and the “more products” rail are all one component.
• Forms with visible edges. Inputs are outlined rather than filled, with the label sitting above and outside, and counters on anything length-limited.
• Dialogs for anything with a cost. Promotion, post creation, insights and transaction history all open as modals over the dashboard, so a seller never loses the context of the page they’re changing.

Product detail is the page that has to close the loop between browsing and contacting, so it stacks specification, price, social proof and seller identity in that order and repeats the contact action at the point where confidence peaks.

A WCAG 2.2 review of the delivered designs, written as acceptance criteria for the build team rather than as commentary.

Holding up

• Every form field has a visible label positioned outside the input, so it survives being filled - no placeholder-only labelling.
• Character counters and the mandatory-field note give the user the constraint before they hit it, not after submission.
• The OTP screen shows a countdown and a resend route, so a delayed message isn’t a dead end.
• Status is never colour alone - the Paid chip carries the word, and promotion status pairs a dot with the label.
• Touch targets on the mobile tab bar and the primary buttons are generously sized.

To fix before build

• The light-blue page states put mid-blue text on a tinted blue field; those pairs need re-checking against 4.5:1 for body text and 3:1 for UI components.
• Grey caption text on the product detail page (disclaimer, small print) is the lowest-contrast type in the system and should be darkened rather than shrunk further.
• Amber rating bars need a non-colour equivalent - the numeric value beside each bar covers this, so it must not be dropped on mobile.
• Dialogs need a defined focus trap, an initial focus target, Escape to dismiss and focus returned to the trigger; the visual design already gives each one a clear close control.
• The map blocks need a text address and a keyboard-reachable directions link - which the later dashboard version adds.

Both dashboards were rebuilt after review. Each comparison below sets the two versions against each other and states what moved.

Customer dashboard

• The split banner-and-text card became a full-bleed hero with the business name over a photograph - the page now opens with the business rather than with a layout.
• Contact details moved out of a paragraph into labelled phone and email cards with icons.
• The floating testimonial carousel, which competed with the ratings block for the same job, was replaced by two static quote cards next to a section heading.
• The map gained a full written address and a “get in touch” link instead of relying on the map control alone.

Seller dashboard

• The early version stacked a banner card, then the business name, then the stats, then the actions - four separate blocks before anything actionable. The later version merges them into one hero.
• Notifications were introduced as a stacked, dismissible group inside the hero, with each message carrying its own recovery action.
• Sharing moved from an implied action to an explicit popover with channels and a copyable link.
• An “edit page” control was added at the top right, so the seller’s most common maintenance job stopped being buried.

The finished system gives a seller one page that answers four questions in order: who am I to a visitor, what needs my attention, what am I selling, and is promotion working. Growth features - referral credit, banner promotion, sharing - sit inside that page rather than in a separate marketing area, because they’re only useful in the context of a shop that already exists.

What shipped

• A complete two-sided design: sign-up and OTP verification for both account types, marketplace browse, product detail, customer dashboard, seller dashboard with insights, listing creation, paid promotion, referral credit and transaction history.
• Designed twice over for responsive web and for native Android and iOS, including a five-item mobile tab bar and a re-laid-out mobile home, dashboard and insights view - not a scaled-down desktop.
• One component set carrying the whole marketplace: a single product card used across the home rails, the seller’s post grid and the related-products rail, and one dialog pattern for every action that costs money.
• Both dashboards restructured after review - the case study above shows version one and version two side by side, and states what moved and why.
• An accessibility review of the delivered screens against WCAG 2.2, handed over as build criteria rather than as comments.

The numbers to add

The delivered work is a complete two-sided system rather than a set of screens: a shared component layer, two divergent dashboards, and a promotion flow that carries the platform's revenue model.

What I learned

A shared interface for two audiences is usually two interfaces wearing one coat. The header, the product card and the rating pattern genuinely belong to both a buyer and a seller. Almost nothing past sign-up does. Trying to hold the two together longer than the sign-up screen would have cost both of them clarity.

Correct is not the same as usable. The first seller dashboard had every element it needed and still asked a seller to read four separate blocks before reaching an action. The fix wasn’t new content, it was merging what was already there into one hero. That’s the change I’d make earlier next time.

Accessibility findings arrive too late as review notes. The contrast pairs and dialog focus behaviour in section 12 were all knowable while the screens were being laid out. Writing them as acceptance criteria at the start would have cost nothing and removed a rework pass.

Kiran Kaushik is a bridal and beauty makeup artist working from her studio and on location. Her clients are making an emotional, expensive, once-in-a-lifetime decision, so trust became the entire conversion problem I had to solve.

The site needed to be two things at once: a portfolio where the photography is vast and uninterrupted, and a booking system that settles the practical details before anyone picks up the phone. I gave the work the top of every page and the booking a page of its own, then designed around the pressures that make or break a booking.

To prevent disputes after the fact, clear terms sit directly beneath the form. And to prove the standard, named product brands, screen and NGO credits and client praise all appear well before anyone is asked to commit.

Four commercial pressures shaped the design, each answered somewhere in the five pages:

• Enquiries that aren’t bookings. The booking page states it plainly - a 50% non-refundable retainer secures the date, and an enquiry on its own doesn’t.
• Missing details. The form collects event type, date, start time, location, how many people need makeup and where they’ll be getting ready, so the first reply can be a quote rather than a question.
• Disputes after the fact. Terms and conditions sit directly under the form: what the price includes, what the client arranges, what happens on cancellation.
• Proving the standard. Named product brands, screen and NGO credits, and client praise all appear before anyone is asked to commit.

The service list splits the audience three ways, and the design keeps those splits visible from the first screen: brides and wedding parties, beauty clients booking a single occasion, and shoots - pre-wedding, maternity, fashion, commercial and editorial.

A flat structure with no sub-pages: everything is one click from the header, and the header stays in the same place on all five. Contact and Book Online are deliberately separate - one is a question, the other is a commitment.

Someone who is ready to book and someone who is still deciding need different amounts of friction, so they get different forms.

The palette gets out of the way of the photography, which is red, gold and heavily embroidered on every page. Nothing in the interface competes with it.

• Dusty rose header, blush page, plum footer. The page darkens as you scroll, so the footer reads as a base rather than an afterthought, and headings in the same plum tie the two ends together.
• One repeated device. Every photograph sits on an offset lavender-grey rectangle. It’s the only decorative element on the site, and using it everywhere - service cards, studio shots, the About portrait, the testimonial panel - is what makes five pages feel like one site.
• Gold reserved for the mark. The monogram is the only gold on the page, so it stays the brand signature instead of becoming a colour scheme.
• Type does one job. A single light grotesque throughout, with size and colour carrying the hierarchy rather than a second typeface.

The About page is the one place where the artist, not the work, is the subject. It runs her introduction in her own voice against a single portrait, then lists credits - Discovery Plus documentaries, NGO cultural programmes, a celebrity video shoot - as plain lines rather than logos, and closes with a testimonial carousel.

For a service booked once, at high cost, on a date that can’t be moved, trust is the whole conversion problem. The site answers it four separate ways rather than leaning on one.

• The work itself - full-bleed photography on every page, and a live Instagram grid in the footer that keeps the evidence current without anyone updating the site.
• The products - a wall of named brands on the Services page, so “we don’t compromise” is backed by something checkable.
• The credits - documentary, NGO and commercial work listed on About.
• The clients - a signed testimonial in the About carousel, and Kiran’s own line about brides repeated in the footer of every page.

A WCAG 2.2 review of the delivered designs: what holds up, and what I would correct before build.

Holding up

• Every form field has a visible label above the input, and required fields are marked.
• The commercial terms are stated in text on the page rather than hidden behind a link or a checkbox.
• Phone and email appear as text in the footer of every page, not only inside a form.
• Navigation stays in the same position and order on all five pages.

To fix before build

• Light grey body text on the blush background is the weakest contrast on the site. Darkening it to the plum used in headings fixes it without touching the palette.
• The home navigation sits white on photography with no scrim - legibility depends on which slide is showing. A gradient behind the header makes it reliable.
• Several body paragraphs are right-aligned. It suits the short studio blurb, but the longer service copy should be left-aligned so each line starts in the same place.
• The event-type field shows “Bridal” as grey placeholder text, so an untouched field looks answered. It should be a select with a real default, or an empty field with the example in the label.
• Two fields on the booking form carry the same label, “How did you heard about us?” - one needs renaming to match what it collects, and the wording corrected to “How did you hear about us?”
• The hero slider needs a pause control, keyboard-reachable dots and accessible names on them; auto-advancing carousels fail WCAG 2.2 without a way to stop them.
• Social and WhatsApp icons need text alternatives, and the floating WhatsApp button needs to sit clear of the form’s send button at smaller sizes.

The delivered designs are desktop at 1920. This audience arrives predominantly from an Instagram profile link on a phone, which makes the small-screen layouts the ones that carry the commercial load.

What shipped

• Five designed pages - Home, About, Services, Book Online and Contact - sharing one header, one footer and one repeated visual device, so the site reads as a single thing rather than five layouts.
• A two-tier enquiry path: a twelve-field booking form that collects everything needed to write a quote, and a four-field contact form plus a WhatsApp shortcut for people who aren’t ready yet.
• Commercial terms designed into the page - the 50% retainer stated at the booking call to action, and full terms and conditions sitting directly beneath the form.
• Four distinct trust signals built into the structure: the photography, the named product brands, the screen and NGO credits, and client testimonials.
• An accessibility review of the delivered pages against WCAG 2.2, including two content errors on the booking form that would otherwise have shipped.

What I learned

For a service business, the form is the product. The photography gets someone interested, but the twelve fields on the booking page are what turn interest into a date in a diary. Designing the form as carefully as the hero was the decision that mattered most here.

Money is easier to design than to avoid. Putting the retainer terms on the page, in plain language, before the form rather than after it, makes a client nervous and a customer relieved. It belongs in the layout, not in a follow-up message.

Design for where the traffic comes from. This audience mostly arrives from an Instagram profile link on a phone, and the delivered work is desktop at 1920. If I ran this again I’d design the mobile layouts first and treat desktop as the adaptation.

A parking sensor tells you that something is wrong. It does not tell you what to do, and by the time it sounds the car is usually already out of line. Learners and new drivers misjudge steering angle, notice the mistake late, and have no record of whether they are improving.

Park AR is an augmented reality parking assistant. It overlays the exact steering angle needed onto the live camera view, colour-codes continuous feedback rather than sounding a warning tone, shows distance to the bay line before alignment fails, and logs every session so corrections and accuracy can be tracked over time.

• Angle is the hard part. New drivers can see that they are misaligned; what they cannot judge is how many degrees of correction that requires.
• Warnings arrive after the error. Proximity sensors fire once the car is already too close, which makes them a report rather than a guide.
• Verbal instruction is imprecise. Instructors struggle to convey a steering angle in words, and the explanation varies with the instructor.
• No record of progress. Nothing tells a learner whether this week was better than last.

Three personas framed the work, each needing something different from the same guidance.

• Mayank, newly qualified. Drives regularly but finds reverse parking difficult, particularly judging angles and correcting them. Needs real-time instruction, visual alignment feedback and progress tracking. Notices his mistakes too late.
• Alena, driving instructor. Finds steering angles hard to explain verbally. Needs a current-versus-recommended angle comparison and session summaries so feedback stops depending on personal judgement.
• Dev, nervous learner. Becomes overwhelmed by several instructions at once and is startled by sudden alerts. Needs one instruction at a time, short language, and calm audio and visual guidance.

Dev is the persona that shaped the most design decisions. Designing for someone who finds the interface itself stressful forces restraint on every screen.

The scenario is deliberately small: a single reverse into a busy loading bay, broken into the four moments where the system has to say something useful.

• Reversing in. The app reads vehicle movement and displays "Turn steering wheel 30° left."
• Under-correction. He turns only 15°. The response is immediate and specific: "Steering angle too shallow, turn an additional 15° left."
• Perfect alignment. Guidance turns green: "Perfect alignment. Continue reversing slowly."
• Session summary. One correction this time against three last week, shown straight after parking.

That last moment is the one that separates this from a parking sensor. The feedback does not end when the manoeuvre does.

Hands stay on the wheel, so the session opens on a voice command. The flow branches on alignment and on hazard detection, with both branches returning to guidance rather than ending the session.

Six layers, from raw sensing to the instructor dashboard. I owned this model and the instructor-facing end of it.

• Input. Rear camera feed, IMU, and GPS for coarse positioning.
• Perception. On-device computer vision detects bay lines, kerbs and obstacles; sensor fusion estimates heading and steering angle.
• Guidance engine. Compares current heading against the ideal trajectory and generates step instructions and alignment status.
• AR rendering. ARKit or ARCore overlay: steering arrows, angle readouts, distance markers, colour-coded feedback.
• Feedback output. Visual overlay, on-screen prompts, audio cues, haptic pulses.
• Data and analytics. Session data synced for progress tracking and instructor reports.

The glasses carry a stereo depth camera, IMU, ambient light sensor, microphone and eye tracking. The vehicle already measures steering angle, wheel speed and RPM over OBD-II, and its existing ultrasonic sensors can be reused for proximity rather than adding hardware.

The reasoning matters more than the list. The glasses can see where the bay is, but the car measures its own motion more precisely than any camera or IMU can estimate. The guidance engine fuses both streams instead of relying on optical estimation alone.

Rather than a single interface for everyone, the perception and guidance logic stay identical and only the rendering layer adapts. The standard profile uses compact tiles, standard type and colour-led feedback, assuming confident, quick visual scanning. The accessible profile uses large high-contrast text and icons, leads with audio so colour is secondary rather than the sole signal, and paces guidance more calmly with fewer simultaneous elements on screen.

This is WCAG-aligned practice applied to an AR interface: never rely on colour alone to convey meaning. It also answers a stated user need without duplicating engineering effort, since the logic underneath is unchanged.

I built both fidelities. The low-fidelity pass settled where information could sit without covering the road; the high-fidelity pass tested whether it survived real light, real glass and a real dashboard.

• Audio. A rising tone as the angle approaches correct, with a distinct alert for exceeding the line.
• Haptic. A short pulse confirms alignment; a double pulse warns of an obstacle.
• Colour. Amber for correction needed, green for aligned, red for boundary breach.

Mapped against the 3D interaction taxonomy, the interface uses selection (tapping the highlighted bay), rotation (the guidance engine comparing initial and target orientation as a degree readout) and system control (one tap or voice command moving between detection, guidance and summary). The paradigm is mobile video see-through AR, with an optional wearable extension for the instructor.

Reviewed against three categories of perceptual challenge in XR, ahead of the prototype rather than after it.

• Technological. Latency during fast corrections would be dangerous, so tracking runs on-device rather than round-tripping to the cloud. Limited camera field of view means the engine estimates bay markers outside the frame.
• Perceptual. Depth judgement is hardest in 2D, so a simple distance-to-line marker replaces true depth. Overlays always render on top, never behind real-world elements. Colour-coded feedback was chosen for outdoor brightness variability.
• Human factors. The phone mount is fixed to minimise eye travel from the road, guidance is disabled above a safe manoeuvring speed, and calm audio and haptic cues are favoured over an intrusive visual HUD.

I designed the evaluation and ran the analysis. A single method would have given either numbers without reasons or reasons without numbers, so the study pairs self-report with observed behaviour.

• Technique one, complete. Self-report questionnaire, n=8, recruited to match the personas. Seven Likert-style usability statements plus two open-text questions, giving mean agreement per statement alongside manoeuvre-difficulty selection and free-text comment.
• Technique two, in progress. Moderated, task-based sessions with three to four participants, capturing corrections per park, completion time and alignment success, with think-aloud and two structured follow-ups.

Results

• AR instructions were clear and easy to follow: 5.00 / 5
• Visual feedback made corrections easy to identify: 5.00 / 5
• Participants felt replay would support future practice: 5.00 / 5
• The interface was easy to understand: 4.88 / 5
• The post-parking summary helped users review performance: 4.88 / 5
• Steering guidance helped with vehicle positioning: 4.75 / 5
• Parking bay and distance indicators were helpful: 4.75 / 5
• Reported distraction while using the prototype: 1.25 / 5
• Baseline confidence in own parking ability: 2.9 / 5

• Every core usability item scored between 4.75 and 5.0, with unanimous agreement that visual feedback and replay aided understanding. That supports the perceptual decisions: colour-coded, always-on-top overlays.
• Distraction stayed at 1.25 / 5 despite dense on-screen information, suggesting the human-factors constraints of speed-gated guidance and calm feedback worked as intended.
• A baseline confidence of 2.9 / 5 confirms the sample genuinely matched the low-confidence personas rather than being generally capable drivers.
• Reverse parking was confirmed as hardest by five of eight participants, validating the scenario choice.

The finding I would lead with in a review: near-ceiling scores and thin free-text responses, answered by five of eight and one of eight respectively, most likely reflect an unmoderated, convenience-leaning sample rather than genuinely flawless usability. Treating 4.9 out of 5 as a result would be the wrong read.

What that changes

• Add objective task metrics through moderated sessions instead of relying on self-report.
• Standardise every survey item to one 5-point Likert scale and remove mixed agree/strongly-agree wording.
• Clarify the wording and anchor direction of the mental-demand question, then re-test.
• Actively prompt open-text feedback with a follow-up "why" during moderated sessions.
• Recruit instructor-persona participants, who are not represented in this sample.

Current limitations

• Steering angle is estimated from phone IMU and optical flow, which is less precise than a direct vehicle connection.
• Computer vision accuracy drops in poor lighting and heavy rain.
• The n=8 sample skews to novice and learner drivers; the instructor persona is untested.
• The self-report survey lacked a validated instrument and moderated observation.

Where it goes

• Direct OBD-II and CAN bus integration as standard, replacing IMU estimation.
• Consumer AR glasses as the primary device, with the phone as fallback.
• Fleet and driving-school analytics across thousands of learners.
• Adaptive coaching that personalises guidance to each driver's habits.

"Accessible room" is a label, not an answer. It does not say whether the shower is roll-in, whether a wheelchair can turn beside the bed, whether the alarm is visual, or whether staff are trained. So disabled travellers phone the hotel to ask, which is precisely the barrier research on accessible tourism keeps identifying.

AccessibleStay is a responsive web application for hotel search, comparison and booking, built for people with physical, visual, hearing and cognitive access needs. It addresses all four WCAG principles, and every feature exists to remove a specific barrier rather than to sit on top of the product as an accessibility add-on.

The build includes accessibility-need filtering, a structured accessibility checklist per hotel, a captioned and pausable virtual tour with transcript, a persistent accessibility menu, full keyboard operability, a four-step booking flow with progress indication, live text chat, and hotel comparison.

Each persona carries the WCAG 2.2 criteria their journey depends on, so a design decision can be traced back to a person and forward to a success criterion.

• Sarah, 35, full-time wheelchair user. Keyboard navigation, voice-to-text when fatigued. Frustrated by listings that say only "accessible room" and by having to phone to confirm basic facts. 2.1.1 Keyboard, 2.4.7 Focus Visible, 2.5.8 Target Size, 1.3.1 Info and Relationships.
• Hortence, 42, severe visual impairment, screen reader and refreshable braille. Frustrated by carousels without alt text and unlabelled fields. 1.1.1 Non-text Content, 1.4.3 Contrast, 1.4.4 Resize Text, 4.1.2 Name, Role, Value.
• Harish, 28, profound hearing loss, avoids phone calls. Needs captions and a text channel. 1.2.2 Captions, 3.3.1 Error Identification, 3.3.2 Labels or Instructions.
• Arijit, 24, dyslexia. Overwhelmed by dense pages and long forms without a sense of progress. 3.1.5 Reading Level, 3.2.3 Consistent Navigation, 2.4.8 Location, 3.3.7 Redundant Entry.
• Kevin, ADHD. Added after the first evaluation, once it was clear the original four under-represented attention and executive-function barriers.

A note I kept in the report and will keep here: personas are design instruments, not claims that everyone with a diagnosis behaves identically. The assumptions are research-informed and still require validation with target users.

Sarah's frustration is not that hotels lack accessible rooms. It is that the listing will not tell her which facts are true, so she has to ring. The hotel page carries a structured accessibility checklist instead: doorway widths, roll-in shower, turning space, alarm type, staff training.

Every interactive element works with Tab, Shift+Tab and Enter alone, with no focus traps. Focus order follows visual and DOM order, and no sticky header or dialog obscures the focus indicator. Controls meet the 24×24 CSS-pixel minimum, and the accessibility controls are built to a 48px target, deliberately more tolerant than the standard requires for tremor or limited dexterity.

Semantic landmarks and logical headings let a screen reader move from the search form to hotel detail. Controls announce name, role and state through ARIA, and changes such as the filtered hotel count are announced through a live region without moving focus.

The accessibility menu offers a high-contrast theme, separate text-size and text-spacing controls, and three colour-vision modes: deuteranomaly, protanopia and tritanopia. These replace the primary, success and error colours rather than applying a filter, because the failure mode being designed around is meaning carried by colour alone.

The virtual room tour is captioned by default with a visibility toggle, pausable, and accompanied by a full text transcript carrying the same information. Support runs through live text chat with labelled prompts rather than a phone helpline, and no booking step requires a call. Errors are identified on screen and by email.

Harish's requirement was simple to state and easy to get wrong: he must be able to complete search, booking and confirmation without speaking to anyone.

Dyslexia and ADHD are treated separately rather than as one "cognitive" bucket, because the barriers differ: reading effort and error recovery for Arijit, attention regulation and working memory for Kevin.

For Arijit: a four-step booking flow with a visible "Step X of 4" indicator, plain-language field-level errors with a page-level summary, no redundant re-entry of information, increased line height and spacing, and an optional OpenDyslexic typeface. The typeface is opt-in deliberately, since the evidence shows no single typographic change works for all dyslexic readers.

For Kevin: an Easy Read mode that shortens sentences and strips secondary information, a "use my location" control that removes typing and recall from search, and hotel comparison that holds several options in one view instead of demanding tab-switching.

Where WCAG 2.2 places useful cognitive provisions at AAA, such as 3.1.5 Reading Level and 2.4.8 Location, I treated them as requirements anyway and traced each to the barrier it removes.

Desktop, tablet and mobile share information architecture, components and accessibility settings. Each build changes layout density, navigation placement and touch-target size rather than simply resizing the desktop layout.

• Desktop adds side-by-side comparison of two hotels, keeping price, rating and access features together instead of split across pages.
• Tablet replaces the bottom tab bar with a persistent side navigation rail and adds the Plan Together panel to the booking review step.
• Mobile collapses multi-column grids to one column, widens the bottom bar, and presents the accessibility menu and chat full-screen rather than floating.

One honest limitation I recorded: the comparison view uses a visual grid rather than a native HTML table, so its reading order and semantics need explicit screen-reader handling.

A task-based study with ten participants, run on their own devices rather than one controlled machine: four mobile, three laptop, two desktop, one tablet. Two tasks: find a hotel meeting a stated access requirement, then complete a booking to confirmation. Then a five-point Likert survey and five categorical questions.

What came back

• Task completion reached 90% for both search and booking, but independent completion was lower: seven of ten for search, six to seven of ten for booking.
• Modern and professional design rated highest at 4.1/5; comparison ease 4.0/5; filter ease, booking clarity and ease of use 3.9/5 each.
• 80% found the accessibility checklist sufficient; the rest said partly.
• 80% reported settings persisted correctly across screens.
• 70% found the interface fully usable after increasing text size and spacing, indicating the layout held but needed work at maximum settings.
• Most-used controls were Contrast+ and Bigger Text.
• 90% said "maybe" or "no" to making a real booking.

That last number is the one worth sitting with. A usable interface that people would not yet trust with a real booking is a finding about credibility, not usability, and no amount of WCAG conformance fixes it.

• Colour-vision modes replaced a single contrast theme. One "Contrast +" option did not cover the spectrum of colour-vision deficiency, so three palettes were introduced, replacing primary, success and error colours.
• Mobile and tablet were rebuilt for text scaling. A dedicated layout layer was needed so cards, navigation and dialogs do not clip or overlap when text size, spacing or line height change. Dialogs became full-screen, touch targets grew, and the bottom bar was widened and re-centred.
• A fifth persona was added. Reviewing the recommendations against cognitive-accessibility guidance showed the original four under-represented attention and executive-function barriers, which produced Kevin, Easy Read mode, the location shortcut and comparison.

The second change is the one I would defend hardest: it was a rebuild rather than a patch, because the original layout could not survive its own accessibility settings at maximum.

• Ten participants with no qualitative depth. The results are indicative, not conclusive.
• The ADHD features were designed against guidance and checked for WCAG 2.2 conformance, but have not been tested with ADHD participants.
• Participants were not recruited as assistive-technology users, so screen-reader performance is argued from semantics rather than demonstrated.
• The mobile build remains inadequate for a braille and screen-reader user like Hortence, since enlarged text does not avoid horizontal scanning.
• The comparison grid needs explicit screen-reader semantics before it could ship.

The point of listing these is that an accessibility project which claims to be accessible without disabled participants has proved conformance, not usability. Those are different things, and the distinction is the most useful thing I took from this project.