Hi, I am
Industrial & UX/UI Designer
I'm an industrial and UX/UI designer based in Savannah. I take ideas from research and flows to working front ends, and use the same prototype-first approach for physical products.
User interviews, surveys, affinity mapping, usability testing, and insight translation
Information architecture, user flows, interaction design, and visual systems
Figma, Blender, physical models, iterative testing, and developer handoff
React, Vue, Next.js, JavaScript, HTML, and CSS
UX/UI Designer & Front-End Developer · Sep 2024 to Present
Designed and built Sanathan Sethu, the responsive Seeker.social experience and partner portal, and the Vaijayanthy Quality Exaal marketing site.
UX/UI Designer · Sep 2022 to Jul 2024
Redesigned OpenGrid 360, led a multi-school platform from research through handoff, and used two rounds of usability testing to reduce task completion time by 30%.
Industrial Design Intern · Bangalore, India · Feb 2022 to Jun 2022
Designed a bakery and café interior from material research and spatial planning through client-ready 3D models, then created modular furniture that staff could quickly reset without sacrificing floor space.
Industrial Design Intern · Bangalore, India · Jul 2021 to Nov 2021
Translated client conversations into approved mood boards, then developed custom furniture from test models through 1:4 and full-scale prototypes for CNC fabrication.
Savannah College of Art and Design
Ramaiah University of Applied Sciences
Lextant
I'm curious about almost everything. I can take something apart and put it back together simply because I need to understand what is happening inside.
I can sit quietly and observe an ordinary place for a long time, noticing the smallest details others might pass by. I like going somewhere unfamiliar simply to understand it, and my mind often wanders into ancient worlds, imagining their stories, beliefs, and ways of life.
Recently, I've found myself asking “why?” more often. Not to question everything for the sake of it, but because understanding the reason behind something helps me see it from another person's perspective, even when I do not agree.
I think that is who I am: someone who looks closely, keeps asking questions, and wants to understand things from more than one point of view.
I follow Barcelona and the World Cup, and I care just as much about whether the ground looks good to play on.
This portfolio is designed as a working surface for industrial objects, digital systems, and the evidence behind both.
Three product concepts explored through sketches, physical models, CAD, and material studies. From hearing support to the kitchen counter and the front door.
 1.jpg)
Lifestyle hearing support worn as a signal, not hidden as a flaw.
View the product
A sculptural coffee machine developed from ritual and form through CAD, CMF, and manufacturing.
View the product
A smart door system combining access, monitoring, communication, and a physical key.
View the productHearing support with a visible identity.
An ear-worn concept explored through sketches, foam forms, prototype finishing, and on-body studies.
Explore the physical models
The research brief was provided in class. My contribution is the interpretation and development shown here: sketches, physical models, interactions, CAD, and the final concept.
Young adults who struggle in noisy, outdoor, moving, or social environments and want support that fits their identity.
Young adults experience difficult listening situations but often reject hearing aids that feel clinical, hidden, or stigmatizing.
A lifestyle hearing-support wearable with direct controls, focus feedback, six colorways, and a charging case.
The ring form treats visibility as part of the product’s identity. Physical models explore its relationship with the ear.
The reference material frames everyday listening and the range of existing audio products.
Ring, loop, clip, and behind-ear forms explore how the device attaches, where its weight sits, and how much of it is seen. These four sheets retain the full breadth of the exploration.
Comfort, expression, control, and social visibility frame the design direction.
The early studies explore different attachment shapes. The next round develops the larger ring and its position around the ear. The models make the progression visible, while long-duration comfort still needs further validation.
Foam alternatives and on-body studies explore the relationship between the device and the ear.
Separate components and later wear studies show the ring direction at a larger scale.
ContactThe earpiece becomes rounder in the later direction.
IdentityThe larger loop makes the silhouette more recognizable.
PlacementLater studies examine the ring’s position around the ear.
Hand finishing, painting, and surface studies document the physical making process. The control studies are shown as development artifacts; they are not evidence of working hearing-support electronics.
The first two studies show the recessed control features and their surrounding form.
The remaining workshop views keep the intermediate stages visible alongside the finished surface study.
The concept brings together a ring frame, body shell, and direct control. Light, haptic feedback, and hearing support are proposed functions; the physical studies establish appearance and placement.
Ring frameThe loop gives the wearable its visible outline.
BodyThe side profile shows the shell in relation to the ring.
ControlThe orange accent identifies the proposed direct input.
The studio view brings the separate forms together before the final on-body photographs.
 1.jpg)
The final wear photographs return the design to human scale. They show the ring, the body behind the ear, and how the object reads from conversational distance.
Material and component choices describe the proposed construction of the concept.
Aurio reframes assistive hearing technology as confident lifestyle hardware. The next step is testing the acoustic package and long-duration comfort with more wearers.
A coffee ritual, shaped around a triangle.
A countertop coffee-machine concept developed through form exploration, two cardboard models, interaction studies, and internal CAD.
Explore the physical models
The research brief was provided in class. My contribution is the interpretation and development shown here: sketches, physical models, interactions, CAD, and the final concept.
Design-conscious home users who value expressive countertop objects and a slower, more deliberate coffee ritual.
Many coffee machines make a quiet daily ritual feel visually busy, mechanically complicated, and emotionally impersonal.
A sculptural rounded-triangle coffee machine organized around a clear morning preparation and brewing sequence.
The rounded triangle carries through the drawings, cardboard models, and final CAD.
Lifestyle imagery frames the intended setting. Image credits identify the reference sources.
The sketchbook moves through stacked cylinders, enclosed bodies, open frames, and triangular silhouettes. The drawings below are grouped by form so the alternatives can be compared.
I explored the triangular direction through form development, then carried it into cardboard to understand its volume as a physical object.
The first model helped me understand the form. Building it made me realize that the next step was to work out the internal arrangement and test the individual parts. The second model moves that exploration into component placement and access.
I used the first cardboard model to understand the overall form. The mug provides a scale reference for the central opening.
The next build explores how the parts fit into the form and how each one can be reached, moved, or removed.
OpeningCompare the frame and cup space across the two builds.
Brewing headThe second model brings the head into the cup opening.
ReservoirA removable side component makes the refill action testable.
The physical study covers component removal, control reach, cup access, and refilling. The photos document these tasks; they do not establish brewing performance or a measured usability improvement.
From unpacking to refilling, the interaction drawings explain how the parts are approached and moved.
The CAD studies place the brewing assembly, pump, water tank, and controls inside the triangular envelope. They show a proposed package, with heat, sealing, and brew performance still requiring a working prototype.
The exploded component map and material studies connect the exterior to a proposed manufacturing approach.
Peach and muted green share the same triangular body and darker touchpoints. Studio views describe the surfaces; the kitchen views return the object to its intended setting.
The positioning study compares ARC with familiar coffee-machine brands. The price is a concept target, not a validated retail price or production quote.
Material and component choices describe the proposed construction of the concept.
ARC carries one visual idea from moodboard and hand model through CAD, CMF, assembly, and market positioning. A working prototype would test heat, noise, cleaning, and brew performance.
A front door with fewer separate devices.
A connected handle concept bringing access, sensing, communication, and a physical key into one front-and-rear system.
Explore the physical modelsThe research brief was provided in class. My contribution is the interpretation and development shown here: sketches, physical models, interactions, CAD, and the final concept.
Residents and shared households that want convenient smart access without losing a familiar handle or dependable physical key.
The front door has become a cluttered stack of separate security devices, batteries, keys, and disconnected applications.
An integrated smart-door handle combining a camera, doorbell, motion sensing, smart lock, physical key, and companion app.
The design brings the camera, access controls, and grip into coordinated front and rear housings.
The framing board brings the separate devices into view before the integrated design proposal.
The sketch exploration combines the sensing area, access controls, and grip into one recognizable object. The annotated sheet identifies directions within the broader exploration.
The prototype family explores the housing and grip. Mounted and hand-held studies then bring clearance, reach, and the turning action into the design process.
Full-scale parts make the proportions and relationship between body and handle tangible.
These photographs show grip and mounted-use studies. They document exploration rather than a quantified ergonomic result.
Grip profileCompare the handle shapes in the prototype family.
ClearanceThe hand studies show the space between the grip and mounting surface.
Mounted useThe door-mounted model brings reach and the turning action together.
The handle and camera serve different physical needs. The installation study places the grip near 39 inches and the camera near 48 inches, making the relationship visible on a full door.
The companion concept brings lock control, event history, a digital key, and visitor response together. A physical key remains part of the hardware proposal.
The front and rear housings organize sensing, access, grip, and power. The exploded study makes the proposed mechanical and electronic arrangement inspectable.
The annotated front and rear views locate the camera, sensing, access controls, key, and battery within the housings.
The exploded view separates the covers, handles, electronics, power components, and fasteners to explain the proposed assembly.
Body and handle combinations explore how the system could sit alongside different door materials. The final studies show the range and the assembled object.
The same family of parts is shown across the proposed color and material options.
Material and component choices describe the proposed construction of the concept.
Bastion turns separate smart-home accessories into one understandable threshold. Further work would validate installation across more door standards and test shared household access.
Platforms and flows, several shipped as working front-end products. Each opens with what I did and what changed, then shows the whole thing, screen by screen.
A restaurant allergy platform that carries one clear safety verdict from the diner's phone to the kitchen.
View the case study
A medication support system built around flexible routines, recoverable dose states, and caregiver visibility.
View the case study
A verified, Telugu-first bridge between devotees and priests.
Coming soon
Nightlife mapped across 10,000+ venues. A live product.
Visit live website
Logistics, made legible. Live site.
Visit live website
Time, spelled out. An illuminated letter-grid clock, prototyped and shipped as a live site.
Visit live websiteHow can one allergy decision survive the trip from diner to kitchen?
A two-sided restaurant system that keeps evidence, questions, and safety decisions connected across four service roles.
Diners can’t trust a menu claim without asking, waiters and kitchens lose that question in the handoff, and every dish gets forced into an unsafe yes-or-no, even when the kitchen truly can’t verify it.
Forkast replaces that guesswork with one shared safety record, connecting the customer-facing decision to the restaurant workflow required to verify and execute it.
All 11 participants succeeded in under 2 minutes.
The same group took twice as long on a traditional menu.
10 of 11: found full dish details unprompted.1 of 11 needed guidance to find the rest of the dish info.
Three research conclusions shaped the service system and its interface states.
Show the evidence behind each safety state instead of asking diners to trust a label.
Carry one question and answer record from the diner to the waiter, chef, and line cook.
Use Safe, Caution, and Avoid states, including an honest stop when the kitchen cannot verify a dish.
One shared safety record, surfaced differently for the diner, the waiter, and the chef.
The work combined service research, system definition, interaction design, and interface resolution.
Three lessons changed how the final system was framed and designed.
Framed restaurant allergy safety as a connected service problem and translated the evidence into design criteria.
A diner-facing filter cannot create confidence if the restaurant workflow cannot verify and execute the same decision.
Defined the customer, waiter, chef, and line-cook relationships, including escalation and stop states.
Showing Caution, Avoid, and no-safe-option states is more responsible than forcing every dish into a confident yes or no.
Designed the role-specific interfaces, reusable states, wireframes, and interactive product direction.
Customers, waiters, chefs, and line cooks need different levels of detail, but they should never work from different versions of the truth.
Continue to another UX/UI case study or return to the complete project index.
A two-sided allergy verification system.
The original 30-page case study, rebuilt for the web in the same order, using project evidence, diagrams, interfaces, and shorter explanations.
Restaurant allergy decisions affect millions, yet confidence and communication remain low.
Research sources documented in the case study: FARE, JAMA Network Open, and FAACT.
Today, allergic diners choose between time-consuming verification and the risk of skipping it.
Pre-visit research
Allergy conversation
Staff lack adequate allergy knowledge
Diners leave after an unsafe meal
Customers cannot verify safety fast enough to explore a menu.
Waiters become human translators during service.
Paper tickets go stale as ingredients and prep change.
Six methods built on one another; observation, not another interview, produced the biggest shift.
Find the scale and known failure points
Understand the cost of checking
Compare reported and actual behavior
Map customer and restaurant gaps
Pressure-test the service model
Turn five clusters into criteria
Interview confidence collapsed in an unplanned, hungry walk-in. That behavioral gap became the central design problem.
“Sometimes it is just not worth the hassle.”Customer interview · planned visits
“Sometimes I still feel anxious even after taking my medication.”Customer interview · daily allergy
The design problem is the hungry case, when verification feels harder than the risk feels immediate.
Customer tools do not reach kitchens; restaurant tools do not reach diners. None preserve a shared live record.
| Tool | Customer | Restaurant | Real-time sync |
|---|---|---|---|
| Spokin | ✓ | × | × |
| AllergyEats | ✓ | × | × |
| EveryBite SmartMenu | ✓ | Partial | × |
| Picknic | ✓ | × | × |
| Toast / Square POS | × | ✓ | × |
| Forkast | ✓ | ✓ | ✓ |
The customer journey shows the verification burden, the hunger-driven shortcut, and the uncertainty that survives the meal.
Break 01 Information gap before the visit
Break 02 Hunger overrides verification
Break 03 Silent uncertainty after ordering
The waiter owns the conversation while the kitchen works through paper tickets, memory, and limited peak-service capacity.
The evidence converged around verification cost, trust, time, stale information, and restaurant capacity.
30–60 minutes of research before eating
Confidence changes with the person answering
Checking is slow enough to change behavior
Paper tickets and memory cannot stay current
Small kitchens cannot absorb every escalation
Two customer patterns and two restaurant roles expose both sides of the same safety decision.
Fast, trustworthy answers without pre-visit research
Clear Safe / Caution / Avoid evidence
Resolve questions without leaving the floor
Scannable allergen flags and honest capacity limits
Five criteria became the test for every later interface and service decision.
Route through staff, not around them
Make checking faster than skipping
Use scannable signals during service
Show when a safe answer is not possible
Never imply universal capacity
The waiter’s confidence and the chef’s capacity rise and fall at different moments during the same order.
Pain point Modification approval is slow.
Pain point Mid-service prep conflicts are hard to eliminate.
System limit Small kitchens cannot promise every substitution.
Those criteria and that journey point at one gap: what the customer already knows never reaches what the restaurant can verify and safely execute.
What the diner knows is safe before walking in.
What the waiter, manager, line cook and chef know and can do.
Closing that gap could be built three different ways. Two of them still left the gap standing.
Helpful discovery, but no restaurant integration or shared truth.
Tracks allergens but leaves the customer outside the system.
Connects customer verification to live restaurant operations.
Choosing the two-sided system was the easy part. What it actually needed only became clear once real restaurant behavior pushed back on the first version.
Direct diner-to-chef route
→AfterWaiter and manager first; chef only when needed
Every question escalated
→AfterApproved answers become reusable service knowledge
One restaurant mode
→AfterFull-service, limited-substitution, or rejection-mode
Three of those shifts came with a real cost, each chosen deliberately over an easier alternative.
Route to waiter first; escalate only when needed
Direct diner-to-chef chat
Keep severity as restaurant-owned evidence
Customer-entered severity colors
Allow kitchens to say a dish cannot be made safe
Force every request into a substitution
Four role-specific products read and update one allergy-and-dish record in real time.
Scans QR, saves allergens, sees evidence
Sees guest context and routes questions
Resolves only the cases staff cannot answer
Receives an allergy flag on every prep ticket
Four views. One shared safety record.
Safe, Caution, and Avoid remain consistent while each role receives the level of detail needed to act.
Low-fidelity flows established allergen setup, menu evidence, staff questions, and kitchen escalation before visual styling.
Semantic safety colors, one component library, and role-aware density let the same decision travel across mobile, tablet, and kitchen displays.
Evidence checked against the diner’s allergy profile.
Cross-contact or substitution details need attention.
The kitchen cannot verify a safe version of the dish.
One question record moves through the service team.
One semantic palette across customer, waiter, chef, and line views.
The customer path, chef decision path, and customer → waiter → chef escalation preserve context from question to answer.
Caution routes to substitution or a question. Avoid keeps ordering locked.
The decision also updates the kitchen ticket and reusable answer bank.
Scan, set allergens, browse a filtered menu, inspect evidence, and order, or ask the kitchen.
The floor, chef, and line views reveal different operational detail while reading from the same shared record.
Usability testing changed hierarchy, routing, state distinction, and the chef’s decision controls.
Allergen labels felt detached from the dish
Move the allergen indicator onto the dish card
Faster confirmation“Ask the kitchen” felt like an end state
Turn it into a persistent pending action
Clear next stepQuestion ownership was unclear
Show a visible waiter → chef route
Shared accountabilityCaution and Avoid looked too similar
Separate amber substitution from red rejection
Safer scanningChef actions were hard to find
Prioritize approve, substitute, reject
Faster resolutionNone of those three decisions survived contact with a real kitchen cleanly. Here’s what actually forced them.
Every trade-off above trades speed for trust. Waiter-first routing, restaurant-owned severity, and an honest “no safe answer” all cost something up front: a slower handoff, more onboarding friction, a request the app sometimes can’t fulfill. None of them look efficient on their own. Together, they’re what makes the system something a kitchen can actually run on, instead of something that just looks good in a deck.
A real chef asked why he needed to be involved at all, and I didn’t have a clean answer. Presenting the first version to a real waiter and chef was uncomfortable before a single word of feedback came back. The look on their faces said the design had blown up a kitchen flow that already worked. That discomfort is what forced the redesign: staff communication stays inside the kitchen’s existing flow, with the chef pulled in only when the waiter genuinely can’t answer.
Routing customers straight to the chef looked faster on paper. It broke down in a mock service test. Cutting the waiter out of the loop seemed efficient, but tested with real waiters and kitchen staff, the kitchen got too busy, questions ended up going back through the waiter anyway, and the flow added time instead of saving it. That failure shaped the current design: staff communication stays inside the kitchen’s existing flow instead of replacing it.
I’d start with the kitchen, not the diner. The process began with the customer-facing menu and worked backward into restaurant operations, which is part of why the first kitchen-facing direction landed as a disruption. Starting with the system the kitchen already runs on, paper tickets and staff memory, would make the eventual customer experience something the kitchen absorbs instead of reacts to.
Customer and restaurant surfaces remain separate at the interface level and connected at the safety-data level.
These are transparent projections from the case-study model, not shipped metrics or measured outcomes.
Estimated waiter time recovered per shift
Hungry walk-in workaround reduced
Estimated menu verification time
Estimated reduction in reaction incidents
Directional estimates from the case-study model, not measured product outcomes.
The project’s strongest lesson is about behavior and restaurant systems, not interface polish.
The most valuable finding came from watching one person do something she had not mentioned in an interview. Behavior changed the system more than another polished screen would have.
Attach an allergen profile before arrival so the kitchen can prepare.
Let a guest summon the floor team without bypassing service roles.
Validate adoption, saved-answer governance, and peak-service capacity.
Forkast succeeds only when one evidence-backed decision survives the journey from the diner’s phone to the kitchen and returns without losing context.
Usability test report.
Two connected studies tested whether diners could make a safer menu decision and whether that decision could survive the handoff into a working kitchen.
A customer-facing filter could look clear and still fail if the restaurant could not receive, verify, and act on the same allergy decision. I tested the two sides separately, then used the point of failure between them to reshape the service flow.
About this reportThis is a concise reconstruction from the confirmed project record. The participant totals and customer results below are real. Formal session notes, recordings, SUS scores, exact scripts, and per-participant timing logs were not retained, so they are not recreated here.
Eleven people used Forkast and a traditional menu to find a suitable dish and inspect the information behind that decision.
All 11 participants found a suitable dish with Forkast.
The same participants took about twice as long with a traditional menu.
Found the full dish details without guidance.
The customer comparison measured clarity at the menu. The restaurant-side walkthrough tested whether the same decision fit the people and pressure behind the menu.
11 customer participants worked through the decision in Forkast and in a traditional menu condition. The surviving results show what the study evaluated, not the wording of the original task script.
A waiter, chef, and junior chef tested the kitchen workflow in a simulated service flow. The retained account documents the behavior that was evaluated, not an exact facilitator script.
The uncomfortable conversation at the end of the first test exposed a system problem: sending every diner question directly to the chef interrupted the kitchen and eventually pushed the question back through the waiter anyway.
Direct access looked faster on screen, but it bypassed the person already responsible for the table and added pressure to the kitchen.
The waiter handles known answers first. Only unresolved safety questions reach the chef, and the answer returns through a visible shared record.
Each observed problem was translated into a specific interface or workflow response. These findings are retained in the original project record.
Allergen labels felt detached from the dish
Move the allergen indicator onto the dish card
Faster confirmation“Ask the kitchen” felt like an end state
Turn it into a persistent pending action
Clear next stepQuestion ownership was unclear
Show a visible waiter → chef route
Shared accountabilityCaution and Avoid looked too similar
Separate amber substitution from red rejection
Safer scanningChef actions were hard to find
Prioritize approve, substitute, reject
Faster resolutionA useful case study is precise about both its findings and its limits.
A future round would turn the surviving evidence into a repeatable study and test the redesigned handoff in a real restaurant environment.
The strongest result was the point where the first concept failed. Listening to the people inside the restaurant changed who owns the question, when the chef gets involved, and how one safety decision travels from table to kitchen.
How do you remind someone without making them feel judged?
A medication support system that replaces rigid, exact-time alarms with flexible time windows, recoverable dose states, and caregiver visibility that only appears when it actually matters.
Exact-time alarms assume medication fits a fixed schedule. In practice, doses get taken around meals, sleep, and work, and a single missed alarm can feel like a moral failure instead of a recoverable moment.
Cura replaces that fixed schedule with one shared dose-state model (upcoming, due, late, taken, or missed) so timing bends to the routine instead of the other way around.
After the hidden swipe gesture was replaced with a visible tap toggle, every participant in the next testing round completed it correctly.
13 of 18 survey respondents managed medication without any dedicated reminder tool before this project.
2 rounds: moderated usability testing.Four participants each, covering setup, the daily schedule, and dose recovery.
Three research conclusions shaped the state model and interface.
Replace fixed alarm times with flexible time windows tied to when doses actually happen: around meals, sleep, and work.
Split the state model into upcoming, due, late, taken, and missed, so a recoverable moment does not trigger the same alarm as a missed one.
Show caregivers only meaningful exceptions instead of constant monitoring, with consent built into setup.
One shared dose state, surfaced differently for the person taking medication and the caregiver supporting them.
The work combined behavioral research, state-model definition, interaction design, and usability testing.
Three lessons changed how the final system was framed and designed.
Ran a survey and interviews, then synthesized adherence behavior into the flexible time-window concept.
Swipe-to-complete felt natural to design, but no participant discovered it without being told. Every meaningful action needs a visible, discoverable control.
Defined the upcoming, due, late, taken, and missed dose states shared across every screen.
Exact-time alarms fight how people actually take medication, which happens around meals, sleep, and work, not at a fixed minute.
Designed the wireframes and visual interface, then ran two rounds of moderated usability testing.
Separating late from missed removes guilt from a moment that is still fixable, and only escalates to a caregiver when it truly matters.
Continue to another UX/UI case study or return to the complete project index.
A flexible medication-support system.
The original case study, rebuilt for the web in the same order: research, synthesis, structure, testing, and the final design.
Four research lenses moved from broad context into direct conversation, synthesis, and two rounds of prototype testing.
The work moved from broad context into direct conversations, synthesis, structure, and two rounds of prototype testing.
Medication habits, reminder use, and routine changes
Failure moments, coping behavior, and caregiver friction
Four participants in each moderated round
Literature, survey, interviews, and market review
One line captures why reminders fail: routines break, not memory.
Medication adherence breaks when routines change, not simply because people forget.
Eighteen survey responses and five interviews were grouped into seven behavioral themes before any design decision.
Survey patterns and interview fragments were kept separate before they were grouped into seven themes.
A new medication breaks an established habit
Routine disruptionTravel changes the expected schedule
Routine disruptionDoctor-led timing changes are easy to forget
Routine disruptionSeveral medications are difficult to juggle
Mental loadOlder adults can lose track of what is current
Mental loadRepeated decisions add effort
Mental loadToo many alerts become background noise
Reminder fatigueExact-time alarms do not match daily life
Reminder fatigueDismissed reminders offer no recovery path
Reminder fatigueSmall delays can create unnecessary worry
Caregiver frictionConstant visibility can feel intrusive
Caregiver frictionSupport needs clear boundaries
Caregiver frictionPeople need to know whether a dose was logged
Trust and visibilityHistory should explain what happened
Trust and visibilityState changes must be visible
Trust and visibilityLate-dose uncertainty causes anxiety
Recovery after delayA missed action needs a clear next step
Recovery after delayThe interface should avoid guilt
Recovery after delayToo many fields appear at once
Setup frictionMedical language increases effort
Setup frictionAdding a changed prescription should be quick
Setup friction16 of 18 participants reported taking regular medication.
13 of 18 did not use a reminder application.
3 of 18 used only a pill organizer.
Research ruled out constant caregiver monitoring in favor of a shared dose state with consent-based visibility.
Research narrowed the system to one person maintaining a routine and one supporter who is involved only when the situation meaningfully changes.
Flexible time windows and clear recovery keep control with the person taking medication.
Explicit consent and delayed escalation reduce monitoring pressure and notification fatigue.
Every wireframe and interface choice traces back to this single question.
How might we help people maintain medication routines through everyday change, recover confidently after a delay, and involve caregivers only when support is genuinely needed?
Ananya is a composite drawn from recurring patterns across participants, not one individual.
Ananya is a composite archetype drawn from recurring research patterns, not a representation of one named participant.
Independent routine manager · 34
Ananya manages recurring medication around a busy, changing day. Her established routine usually works, but a new prescription or unexpected schedule change makes it easy to lose track.
“Adding a new tablet throws my whole morning off.”
Uses phone alarms and relies on an established daily sequence.
Instructions from a doctor and occasional check-ins from family.
Did I already take this, and is it too late now?
Several medicines, changing instructions, and alerts competing for attention.
The journey traces confidence from a calm morning dose through a missed alarm and back to recovery.
The representative scenario maps where confidence falls after a dismissed alarm and rises only when the system offers a clear recovery path.
Wake up
Morning dose
Routine break
Missed alarm
Late dose?
Recovery
Caregiver alert
Evening dose
One action blue, generous white space, and plain language keep medication status the focus, not the styling.
Cura uses one strong blue for action, pale blue for orientation, generous white space, and plain language so medication status remains the focus.
Action blue#0759c7
Soft blue#dce9f8
Canvas#f3f7fd
Ink#25292e
Clear hierarchy, open forms, and readable interface labels.
Routine first
One clear action
Visible status
Support without pressure
Setting up a medication and completing a dose are the only two journeys that matter every day.
One sets up a medication without exposing the entire task at once. The other moves a dose from reminder to a shared, resolved status.
Choose input method
Enter medication details
Set routine and reminders
Review and save
See what is due
Open reminder
Taken, snooze, or skip
Confirm shared status
Daily action, medication management, family support, and settings stay separated instead of collapsing into one screen.
Daily action stays in Home, medication management has its own space, family support remains bounded, and notification behavior stays in Settings.
Navigation, scheduling, dose actions, and family visibility were tested before visual polish began.
Low-fidelity screens established navigation, scheduling, dose actions, and family visibility before visual polish.
Upcoming, due, late, taken, and missed read the same way in the daily view, reminders, history, and caregiver view.
Click a state to see the real screen behind it. The daily schedule, reminders, history, and caregiver view all read from the same dose status.
Reminder timing was modeled two ways during early research.
Precise, but it assumes medication fits a fixed schedule. Testing and interviews showed real routines move around meals, sleep, and work, not the clock.
A dose belongs to a practical period of the day, so the reminder bends to the routine instead of demanding the routine bend to it.
Two rounds of moderated testing changed the calendar signal, the primary gesture, the tab treatment, and the entry point.
Progress bars were removed, the hidden swipe interaction became a visible tap control, and the time-window tabs gained stronger presence.
The task was divided so users no longer had to process all medication and scheduling fields at the same time.
Complete the first focused part of setup.
Continue to the remaining schedule information.
| Observed | Changed | Result |
|---|---|---|
| Calendar progress bars were not understood without explanation. | Removed the bars and moved completion feedback beside each medication. | The final screen no longer asks people to decode an unexplained calendar signal. |
| Nobody discovered swipe-to-complete without instruction. | Replaced the hidden swipe gesture with a visible tap control. | All four participants in the next round completed the interaction correctly. |
| Morning, afternoon, and evening tabs were mistaken for filters. | Increased their size and contrast while preserving time windows. | The final control gives each time window stronger navigational emphasis. |
| Separate Add and Scan actions created hesitation. | Kept one Add entry point and placed Scan inside the flow. | The entry point now asks for one decision before showing input methods. |
The trade-offs made, the conversation that questioned the whole premise, the direction that failed in testing, and what a restart would change.
Choosing flexible time windows over exact clock-time alarms meant giving up precision: a window is a looser promise than a single minute, and that ambiguity had to be designed around rather than hidden. Limiting caregiver visibility to meaningful exceptions instead of full monitoring meant giving up constant caregiver oversight, in exchange for not turning every dose into a surveillance moment for the person taking it.
The hardest question wasn’t from a testing session: it was being asked directly why this needed to be its own app at all, instead of two features added to Apple Health or an existing medication tool. There wasn’t a defensive answer, because there wasn’t supposed to be a new app: building it standalone was the fastest way to find out whether flexible time windows and a shared dose state were actually worth having, or whether it was a feature I’d talked myself into caring about more than real users would.
An early version of the daily screen used small colored progress bars under each calendar date and a swipe gesture to mark a dose as taken. Both failed in testing: the progress bars looked fine but nobody checked them without being told what they meant, and no participant swiped without being told to. The swipe was replaced with a one-tap toggle, which every participant then completed correctly.
I’d pair the app with a physical product instead of shipping software alone: medication storage is its own real problem, separate from the reminder stress this project addressed, and a physical object would let the two solve different halves of the same routine instead of asking software to carry both. I’d also go back and solve an edge case testing never covered: the notification model works cleanly for one medication, proven in testing, but stacking two or more doses due at once is a case the current design doesn’t yet handle.
The project's strongest lesson is about behavior and trust, not visual polish.
Swipe-to-complete felt natural to design, but no participant discovered it without being told. Every meaningful action needs a visible, discoverable control.
Exact-time alarms fight how people actually take medication, which happens around meals, sleep, and work, not at a fixed minute.
Separating late from missed removes guilt from a moment that is still fixable, and only escalates to a caregiver when it truly matters.
Cura succeeds only when a dose's status (upcoming, due, late, taken, or missed) stays trustworthy across the phone and the caregiver view alike.
Usability test report.
Two moderated rounds with eight different participants tested whether medication setup, daily dose actions, and late-dose recovery were clear without instruction.
The daily schedule depended on people interpreting progress bars, discovering a swipe gesture, and recognizing time-window tabs without explanation. I changed those interactions, then tested the revised prototype with four different people.
About this reportThis page uses the findings currently recorded in the Cura project. It does not add participant demographics, verbatim quotations, SUS scores, exact scripts, or per-task timing because those details are not present in the portfolio record.
Each moderated remote session covered the same core experience: medication setup, the daily schedule, marking a due dose as taken, and recovering from a late dose.
Four participants used the original interactive prototype. The interface relied on several signals that made sense only after they were explained.
Four different participants used the revised prototype. The goal was to see whether visible controls and a clearer hierarchy removed the earlier dependence on explanation.
The hidden swipe failed discovery in round one. After it became a visible tap control, every participant in the different second-round group completed it correctly.
Discovered swipe-to-complete without instruction in round one.
Completed the visible tap interaction correctly in round two.
Participated across two rounds, with a different group in each round.
Every retained observation is paired with the design response it caused and the result the current project record can support.
| Observed | Changed | Result |
|---|---|---|
| Calendar progress bars were not understood without explanation. | Removed the bars and moved completion feedback beside each medication. | The final screen no longer asks people to decode an unexplained calendar signal. |
| Nobody discovered swipe-to-complete without instruction. | Replaced the hidden swipe gesture with a visible tap control. | All four participants in the next round completed the interaction correctly. |
| Morning, afternoon, and evening tabs were mistaken for filters. | Increased their size and contrast while preserving time windows. | The final control gives each time window stronger navigational emphasis. |
| Separate Add and Scan actions created hesitation. | Kept one Add entry point and placed Scan inside the flow. | The entry point now asks for one decision before showing input methods. |
The report is specific about what was observed and equally clear about what the current record does not contain.
A future round would preserve the same core scenarios while recording the behavior consistently and testing Cura in the routines where medication decisions actually happen.
The strongest result was not a preference score. It was a behavior change: nobody found the hidden gesture in the first round, and every participant in the different second-round group completed the visible replacement correctly.
