The coordination problem

Rise runs one-on-one, application-writing programs for high school students. Every student's journey runs through four people who rarely see the same information at the same time: the student, an assigned mentor, a writing coach, and a parent.

By day two of the trial, running that coordination by hand was the actual brief. I wrote a Student Onboarding Playbook naming the Program Associate as the student's single point of contact, and specifying the flow end to end: six manual steps, no system holding them together, one person doing all six for every student.

Working solo, on a two-week trial, inside someone else's org, meant I had no engineering time and no mandate to build anything. The constraint shaped the deliverable: this had to be a sketch that argued its own case, not a build.

The lens

“Before UX, I was an architect. I spent years learning how the constraints you can't see, structure, systems, load-bearing walls, determine the experience of the people inside. People operations has the same hidden architecture. I find it, map it, and design around it.”

HER FRAMING FOR THIS KIND OF WORK

Craft decisions worth zooming into

Status tags over a fifth stakeholder view. Rather than adding a separate "issues" screen, on-track and follow-up states are surfaced as small colour-coded tags directly inside the dashboard cards, so the coordination gap is visible at the same glance as the roster, not one click away.

Threaded by stakeholder, not by inbox. The chat surface groups conversation by role (mentor vs. writing coach) instead of chronologically, matching how a Program Associate actually thinks about a student's case: "what does the mentor need to know" is a different question from "what's the latest message."

Leave requests live where they're tracked. Mentors and coaches submit time-off from inside the same system that already holds their schedule, instead of a separate form, so a request and its downstream scheduling conflict show up in one place.

The business question

A portal isn't free to build, so before sketching further I worked through the question a founder would actually ask: what would this need to prove, in credibility and in revenue, to justify building it, and what are the concrete next steps between this sketch and a real decision. That framing, not the wireframes, is what a first conversation about this concept should start from.

What this was, and wasn't

This started as a 72-hour exploration in the first week of a two-week trial, run alongside, not instead of, the actual brief of onboarding Rise's first cohort by hand. It was never formally pitched, scoped, or shipped as Rise software; the Stitch build above is a personal prototype, not a production system.

What it demonstrates is the instinct underneath it: given an undefined coordination problem across four groups with no existing product to copy, map the manual system first, find where it breaks, then design the structure that replaces it, and follow it far enough to see it actually click and scroll. It's the same move as reading a floor plan for the load-bearing walls before deciding what can move.

One event, four completely different people

Bengaluru Tech Week runs across the city for a week: dozens of sessions, dozens of venues, and four groups who each need a tool that does something the others don't: an attendee deciding what to go to, a host publishing and running sessions, a participant collecting proof they showed up, and a volunteer crew that needs to be scheduled and briefed. Left alone, that's four teams building four unrelated tools. I designed one system instead.

What this was, and wasn't

Four directions

Why one pitch, four tabs

Flow's core asset isn't dictation, it's real-time speech understanding. Framing four directions as tabs of one working prototype, instead of four separate decks, was the actual argument: the same engine, pointed at four different jobs, without a rebuild for each one.

Design approach: rapid, AI-assisted prototyping

This wasn't built as flat comps. Each of the four tabs is an interactive, clickable simulation, built and iterated directly inside Claude Design rather than handed off from static Figma frames afterward. That's a deliberate match to how a novel, no-category-reference interaction problem actually gets solved: prototype the behaviour first, since the behaviour is the part that can't be evaluated from a picture.

Problem identification

We were given the opportunity to ideate an application in the healthcare industry, and explored several directions within the sector before settling on one. During research, we decided to focus on a woman's pregnancy journey specifically, after noticing a real gap: a lack of facilities that appropriately address mental health during that time.

Market research

Anxiety during pregnancy doesn't only affect the mother. Research shows stress increases the risk of preterm birth, low birth weight, earlier gestational age, and smaller head circumference in the fetus, and perinatal mental health problems affect a significant share of women during pregnancy and the first year after birth.

Source: ncbi.nlm.nih.gov/pmc/articles/PMC5052760

User research

We gathered qualitative and quantitative data through one-to-one interviews (conducted over Teams with pregnant women who had a history of mental health concerns), an online survey distributed across social platforms and forums, and outreach through Facebook groups focused on pregnancy and mental health.

The results pointed at a consistent pattern:

• Heightened anxiety, decreased sleep, and increased OCD symptoms, with stress and OCD called out most often.
• Some women turned to mindfulness through meditation and physical exercise to cope.
• Many already used tracking apps, but the apps fell short on clarity: it took a long time to understand how to use them well.

That gap, clarity over comprehensiveness, became a direct input into the design decisions below.

From research to features

We card-sorted every pattern surfaced through research and persona work, then ran it through a SWOT analysis (strengths, weaknesses, opportunities, threats) to translate pain points into features and activities. From there we built individual user journeys for each scenario, grounded in age, profession, and personal context rather than a single generic flow.

High-fidelity and micro-interactions

Low-fidelity prototypes were tested and refined before moving to high-fidelity screens, so navigation and structure were already validated by the time we made confident calls on colour, type, and iconography. Micro-interactions were layered in specifically to make navigation feel less confusing at the moments users were already anxious, small motion cues rather than decoration.

Accessibility study

We worked from Apple's accessibility guidelines throughout: a minimum 4.5:1 contrast ratio between text and background, verified with a contrast-checker tool, and a rule against using colour as the only way to convey information, backed up with alternative text for images and other visual content.

Usability testing

We ran a cognitive walkthrough for quantitative testing alongside a System Usability Scale (SUS) test for qualitative feedback. After analysing the results, we catalogued what worked without friction against what needed another pass, and folded the second category into a set of future development priorities rather than shipping it as-is.

What this was, and wasn't

This was an MSc group project, run over roughly three months, ideated, researched, designed, and usability-tested as a healthcare-sector brief. It was not a funded startup or a shipped product; the deliverable was a high-fidelity Figma prototype with tested micro-interactions, not a live app.

What it demonstrates: taking a broad brief (healthcare) down to a specific, underserved problem through research rather than assumption, then keeping every visual and interaction decision, colour, contrast, button size, type ratio, traceable back to either a user finding or an accessibility standard. It was also the first project where I worked this way as part of a team rather than solo, splitting research and design labour while still owning the visual system end to end.

The premise

Most gardening apps are built around people who already have a garden. Urban Eden starts from the opposite constraint: a bare concrete balcony, and a person with no idea where to begin. The entry point isn't a plant catalogue, it's a promise: "Start Your Balcony Transformation," backed by a spatial-scan feature that turns the blank space itself into the input.

The design system, read off one screen

Even a single explored screen carries a system, and the pieces here are legible: a four-item bottom nav that splits the product into discovery, ownership, planning, and reference (Inspire, My Garden, Design, Library), a two-tier CTA pattern (solid for the primary action, outline for the secondary), a status-pill component for time-bound content ("Limited Time Workshop"), and a recurring feature-row pattern, icon, title, description, chevron, reused for the spatial-scan entry point.

That taxonomy is doing real product work: Inspire is the top-of-funnel content and template layer, My Garden is the ongoing ownership surface once a plan exists, Design is the planning tool itself, and Library is reference material, workshops and case studies decoupled from any single project. Four different jobs, one shell.

Where the AR/spatial idea lives

"Scan My Balcony" is the concept's actual hook: point a phone camera at an empty balcony and get AI-powered spatial mapping and plant recommendations back, standing in for the AR-style camera-to-plan interaction the rest of the product is organized around. On this single screen that's a promise, a feature row with a camera affordance, not a working scan flow, but it's placed exactly where a real product would put it: above the fold, before any plant catalogue, as the thing that turns a visitor into a project.

What makes it distinct

Most plant-ID or gardening apps are single-purpose: identify a plant, or browse a catalogue. Urban Eden's premise stitches three things that usually live in separate apps into one shell: a spatial-scan planning tool (the AR-adjacent hook), a template-and-workshop content layer (the "Explore Templates" / "Watch Case Studies" pairing, aimed at people who need to be taught, not just sold to), and a shopping entry point sitting in the header, so a recommendation has somewhere to go. The uniqueness isn't any one screen, it's that combination targeted specifically at people with no garden yet, the underserved end of the category.

What this was, and wasn't

This is one home screen, explored in Google Stitch as a personal concept, not a multi-screen click-through and not a researched, tested product like MUM.me or Bengaluru Tech Week. There's no plant database, no working scan flow, and no user research behind the persona this targets.

What it's here to show is a different instinct: reading a full product, information architecture, interaction model, and positioning, off a single well-considered screen, and being honest about exactly where the line between "designed" and "built" sits on each project in this portfolio.

The brief

Diamond Centre Wales is a bespoke jewellery manufacturer and registered diamond merchant in Wales. Its Ceric app lets customers design jewellery and view it in AR or on a 3D model. The business wanted to go further on omnichannel, joining its online and in-person experience, without losing the tactile, heritage side of buying jewellery.

That became my MSc dissertation at Birmingham City University, run as an industry project with the company. The research question: how can jewellers use augmented reality and digital twin technologies to personalise customer experiences across online platforms like mobile apps and offline touchpoints?

Research design

An exploratory sequential mixed-methods design: qualitative work first, to find out what customers and retailers actually care about, then a survey and a prototype test to check how far those ideas held up.

What customers told us

Interviews ran 30 to 45 minutes, nine online and eleven in person, with a mix of British participants and immigrants from Nigeria and India (ten each). Open coding of the transcripts surfaced four areas. Pick one.

What the survey added

Fifty respondents (53% female, ages 18 to 65, mostly women between 25 and 40) rated statements on a 7-point scale covering AR shopping intention, ease of use, and privacy risk. Most felt AR would help them visualise how a piece looks when worn and personalise the experience, and many felt it could help them judge quality and workmanship online. Privacy risk was the brake: respondents said concerns about their data made them hesitant to use AR for jewellery. The age and gender profile also fed directly into the personas.

Testing an AR try-on prototype

To see what AR try-on feels like in practice, ten participants used a template-based AR try-on prototype built from the Trillion virtual try-on template, trying and customising digital jewellery, then answering the System Usability Scale and open feedback questions.

• Participants liked the immersive visualisation and customisation, and being able to try more pieces from home.
• Friction: 3D models were slow to load, and buttons were too small to tap precisely on a phone.
• Some worried they could not judge real diamond shine or metal finish on screen.
• Understanding of AR varied: some thought the jewellery was video projected onto them, which points to a need for clearer onboarding.

This was a third-party template, not Diamond Centre Wales's own build, so the findings are about the interaction model rather than about Ceric itself.

Where AR belongs in the journey

The recommendations matched different AR uses to different moments rather than treating it as one feature.

What this was, and wasn't

This was an academic research project run with an industry partner. The output was a framework, personas, recommendations, and a proposed app flow, not a shipped feature in Ceric.

The limits are real and I listed them in the dissertation: recruitment was non-random and the samples were small, the survey was self-reported, usability testing happened in a lab rather than in a shop, the prototype was a template with fewer features than a commercial system, and a full technical evaluation of the AR build was not possible in the time available.

What it shows is the research habit I bring to design work: talk to customers and staff, observe the real setting, test with a prototype, and turn what is learned into principles a team can act on.