Click an icon to open it. Bonus: run bagcheck.app on yourself.
hello.txt
Hi, I'm Alex.
Short for Aleksandra.
After five years working with spatial data and delivering projects, I now design products. Along the way I kept finding processes worth fixing, which is how I started designing and building tools.
This desktop is my portfolio. Start with the QA tool I designed and piloted at DPR, or MoonMates, a hackathon win. Everything else is in work/.
Currently: open to product design roles · London
work/
Selected work
Internal tools, hackathon products and a personal project. Full case studies are added one at a time.
WinnerEngine by Starling challengeHuddleHive Hack 2026
MoonMates
An app for the friends you keep meaning to see. Your circle saves a little every day into a shared pot, a moon fills up as the balance grows, and when it's full the app suggests a time and place that already fit everyone's week.
Team
5 people
Time
24 hours
My role
Product & design
APIs
Engine core + TfL
The brief
“Connect a mock Engine core to an unexpected, non-banking API and create a brand new financial service.”
We paired Engine by Starling with Transport for London. Engine Spaces hold the shared pot, and TfL data finds where your routes already cross, so nobody has to trek across the city.
01 · Context & problem
Friends don't drift apart on purpose
Plans stall in the group chat. Picking a date, agreeing where to meet and splitting the bill all take effort, and saving on your own rarely sticks. We spent the first hours narrowing this down, because choosing the problem was the hardest part of the brief.
02 · My role
Product and design, from the first sketch to the pitch
My teammates appear here as avatars with made-up names.
I facilitated our ideation with a Crazy Eights session, then we cut the ideas down until the strongest were left.
I researched the problem from the start, since narrowing it down was our main bottleneck.
I explored which APIs to combine and went to Starling engineers and the judges early for feedback.
I built and pitched several prototypes in Claude Code, then pitched the chosen concept to the team as a clickable prototype: problem, process, technical background and solution.
My prototype's visual language became the product UI, which the team refined for the final pitch.
I designed the logo and reworked our submission document, effectively a PRD, within the 24 hours.
03 · Key decisions
Decisions that shaped the product
Let the moon set the rhythm
Agreeing on a date is often where plans stall. A 30-day lunar cycle gives everyone the same deadline without anyone negotiating it, and watching the moon fill up makes slow saving visible.
Meet where your weeks already cross
Crossed Paths suggests a spot where everyone's week already overlaps, so nobody crosses the city. In the demo the TfL patterns were mocked. Reflections below explain why, and how we'd build it for real.
Make saying yes effortless
When the moon is full, the app drafts the invite and four out of five yeses books the table. A single-use virtual card is ready on the night, and anything left over stays in the Space so the next moon starts ahead.
04 · How the idea evolved
From a coffee pot to a moon
I prototyped two earlier ideas before MoonMates. Coffee Pot put 10p aside every time you bought a coffee alone, towards a coffee with a friend. The judges told us the problem wasn't clear and asked if we knew anyone who would use it. After that we stopped tying the idea to coffee, because the pot could pay for any night out, from pizza to bowling. Full Moon Pizza turned saving into a monthly ritual inside a bank's Spaces. MoonMates kept the ritual, added the friends and a place to meet, and lets the circle pick what they save for.
Coffee PotEvery coffee alone saves 10p towards a coffee together.
Full Moon PizzaA ritual pot inside your bank's Spaces that unlocks on the full moon.
MoonMatesYour circle saves together and TfL finds where your weeks cross.
05 · The prototype
One moon, start to finish
Day 6. Lena and Nina's weeks cross at Liverpool Street.Day 12. Maya, Alex and Sofia meet at London Bridge.Full moon. The app drafts the invite, and 4 of 5 yeses books it.A single-use Pizza Card for the four who said yes.Pizza night. Nina's £15 stays in the Space for the next moon.
06 · Outcome
We won the Engine by Starling challenge
Team IRL
I'm the one with glasses.
07 · Reflections
What I'd do differently: bring privacy in on day one
Midway through the weekend I looked into what data TfL shares. Its Unified API only has open network data: lines, stations, arrivals and journey planning. It has no journey history, because that is personal data under UK GDPR, and weekly patterns show where people live and work.
In our demo
Mocked TfL patterns
The app learns where your weeks cross
The whole circle opts in to share patterns
Fine for a demo, not for real people
How we'd build it
Stations you share
Everyone adds their usual stations and office days
TfL's open journey planner finds the spot that suits the group
No journey history, no tracking
Remove your stations any time
The feature would work the same way without tracking anyone. We spotted this too late to rebuild it within the 24 hours, so the demo kept the mocked data and the fix went on its own slide.
Next time I'll check what data each API gives us, and what that means for the people in it, before designing a feature around it.
A voice-first symptom diary for patients waiting for specialist care. Patients say how they feel instead of typing it, CareLoop fills in the GP form for them, and the practice can see when someone is getting worse.
Team
5 people
Time
24 hours
My role
Product & project lead
Built with
Claude Code
The idea
Saying how you feel is easier than filling in a form when you're unwell.
Patients waiting for a specialist are often asked to keep a symptom diary. CareLoop lets them talk instead of type, then turns what they said into the eConsult form their GP practice already uses.
01 · Context & problem
Patients are told to track symptoms, with nowhere to do it
We chose the problem after talking to the hackathon coordinators. One of them works at Accurx and told us what the company struggles with, and about her own experience of the NHS. Together with NHS waiting list data, that pointed to three problems.
Patients waiting for an appointment are told to track their symptoms, but there is no system to do it in.
Patients repeat their symptoms to every NHS service they see.
Clinicians get scattered information and see one snapshot, even when the patient has seen several professionals since the last visit.
Writing a symptom down means stopping, opening a form and typing, often when you feel worst. In our prototype the patient is waiting 84 days for a cardiology appointment, so the diary is also how the GP practice would notice if they got worse.
02 · My role
Product and project lead, and I built the prototype
I led a team of five from the problem to a working AI prototype in 24 hours.
I ran the ideation. After the conversations with the coordinators we picked a few problems and narrowed them down to one.
Once we had the problem, I built a quick prototype in Claude Code. The team followed its UI to the end.
03 · Key decisions
Decisions that shaped the product
Let patients talk
Typing is the barrier, so voice is the main input. Patients can speak while lying down or holding the phone in one hand, and anyone who prefers typing can switch.
Fill in the form the GP already uses
Scribe maps what the patient says onto NHS eConsult fields, so the practice gets a format it already reads. The patient checks and edits every field before anything is sent.
Build on Scribe instead of competing with it
Halfway through the build we found out Accurx already had Scribe, an AI transcription tool used in consultations. We reframed CareLoop as an extension of it: the same transcription, pointed at the patient and used across weeks rather than one appointment.
04 · The prototype
From a voice note to an escalation flag
Start by talking. Typing is one tap away.Scribe transcribes as the patient talks.Scribe picks out the clinical details and maps them to eConsult fields.The patient checks every pre-filled field before sending.The form goes to the GP practice with a reference number.While waiting for cardiology, the patient keeps logging symptoms.The practice sees an escalation flag when severity rises.The severity trend and every entry in one view.The timeline shows when the GP escalation was raised.
05 · Edge cases
The practice gets a flag, but nothing tells the patient to call 999
Handled in the prototype
Some patients can't or won't talk to an app, so typing is one tap away on the first screen.
Scribe can get a field wrong, so the patient checks and edits every pre-filled field before anything is sent.
When severity rises between entries, the practice sees an escalation flag with the reason.
What I'd design next
Designed after the hackathon. Not built, and not tested with patients or clinicians.
In our demo the patient's last entry is "sharp chest pain radiating to left arm" at severity 9, with breathlessness at rest. The practice gets a flag that recommends an urgent review. On the patient's side, nothing says this could be an emergency. We didn't look at this case during the hackathon.
In the prototype. The practice sees the flag.Concept, not built. The patient is told to call 999 as soon as Scribe hears the symptoms.
A flag waits until someone at the practice reads it, and that is too slow for these symptoms. So the first screen I'd add is for the patient. When Scribe hears red-flag symptoms, CareLoop pauses the entry and tells the patient to call 999.
The entry is still saved and flagged, and the screen says so. It also says not to wait for the practice to reply, because a patient could assume that logging a symptom means someone is already looking at it.
Transcription can be wrong, so the patient can say that isn't what they said and carry on. The practice would see that they did.
Which symptoms count as red flags, and the wording, would have to come from clinicians rather than from me.
Two more cases I'd look at after that. If the diary goes quiet for weeks, the patient could be fine or much worse, and the practice can't tell which. If a carer logs for the patient, the entry should say who recorded it.
06 · Outcome
We won the Accurx challenge
We pitched a working prototype after 24 hours. It was judged in the room and no patient has used it, so it shows how I scope and decide under time pressure, not that the product works.
07 · Reflections
What I'd do differently
Test the voice assumption. Many patients on long waiting lists are older, and we never checked whether they would want to talk to an app.
Ask a GP about the flags. A timeline means more information for clinicians who are already busy, and I'd want to know if it helps them or adds to the pile.
Look at the challenge partner's products before ideation, not halfway through the build.
about.txt
Aleksandra (Alex) Vugdragovic
I'm based in London. I spent five years in measured survey, BIM and project delivery, and I now design tools and products for that kind of work.
2025–2026
Project Manager, DPR
Ran a 10-storey survey project in central London from fee proposal to client handover, coordinating three external teams. Main client contact; fee proposals up to £50k. Built the drawing QA tool.
2024–2025
Volunteer UX Designer, Nkomor Healthcare
Sole designer for a year, redesigning a medication platform into a two-sided marketplace.
2021–2025
Measured Building Surveyor / BIM Coordinator, DPR & SUMO Services
Laser scanning, point cloud registration and processing, 2D and 3D deliverables, BIM coordination to ISO 19650. Wrote AutoLISP scripts that standardised 47+ CAD layers, my first go at fixing a process instead of working around it.
2021
Master of Landscape Architecture, University of Zagreb
Product & designUser research, journey mapping, prototyping, Figma, Claude Code
DeliveryStakeholders and clients, scoping, external teams, progress reporting
Survey & digitalMeasured survey, laser scanning, point clouds, BIM, ISO 19650, AutoCAD, AutoLISP
LanguagesEnglish (fluent), Croatian (native)
alex@moon:~$ cat hackathons.log
Oct 26
HuddleHive HackWINNEREngine by Starling challenge · MoonMates · team of 5 · 24h
HuddleHive NHS HackathonWINNERAccurx challenge · CareLoop · led a team of 5 · 24h
alex@moon:~$_
PilotedInternal toolDPR · measured survey
Drawing QA tool
Drawing QA at DPR ran through Outlook threads, with no shared standard and no record of who checked what. I designed one checklist that keeps the feedback and the record with the project, built the prototype with Lovable and Claude alongside my PM job, and piloted it on about 10 projects in my team.
Where
DPR, London
When
Nov 2025 – Sep 2026
My role
Sole designer & builder
Built with
Lovable, Claude
Before
RE: RE: FW: level 03 comments
screenshot (4).png
did anyone check grid D?
updated markups attached
2 to 3 h rewriting per projectAfter
Point cloud aligned to OS grid
Attaches in AutoCAD without errors
No double lines or duplicate points
Scan covers the surveyed area
report.pdf · who checked what
The problem
Feedback lived in email, and there was no record of who had checked what.
Drawings and 3D models came from our team and from external contractors. Before the tool, I timed the admin: rewriting feedback lost in email took 2 to 3 hours per project.
01 · Before and after
One checklist instead of an email loop
02 · Who it's for, and my part
Three groups moved work through QA
SSurvey team
My team. Checks drawings and models before they go out.
CExternal contractors
Planned for phase 2: feedback tied to the check that failed.
RRights of Light team
Asked for a QA report they could export.
I was the only person designing it, while running projects as a PM.
Interviewed 5 people across the two QA teams
Mapped how work moved through QA for each group
Turned the teams' existing guidelines into one checklist
Built the prototype with Lovable and Claude, and piloted it on about 10 projects
Checked feasibility with a business analyst, then tested it with both team leads
Designed a phase 2 concept and tested it with someone from outside the industry
03 · Key decisions
Keeping it small enough to ship
Build for QA, leave project management out
Sorting the pain points by who raised them split them into two problems. QA happened on every project and rework started there, so I built for that.
Start from the rules people already use
The checks come from the teams' own guidelines, in their words, like "Point cloud aligned to OS coordinate system". Each one is a pass, needs improvement or a fail.
Keep feedback next to its check
The team leads didn't want another tool to switch between, so reviewing, screenshots and the report sit on one screen.
From my FigJam research board. The checklist kept this structure, so checks like Point Cloud Data sit in their own section under each review type.04 · The prototype
One review, start to finish
From my research board. Internal work comes from the survey and Rights of Light teams, external work from contractors. The decision either exports the report or sends the work back to the checklist.
The first idea had three tabs: checklist, screenshots and report. I presented it to the analysts and the senior leaders of the team and tested it with them. The tool changed after that, but the basics were already there: every check gets a pass, needs improvement or a fail, a screenshot sits on its check, and the report lists what passed and what needs work.
First idea. The checklist. Each check is a pass, needs improvement or a fail, with a note and a screenshot.First idea. Screenshots in one tab, each linked to its check.First idea. The report lists what passed and what needs improvement.
Screens from the phase 2 concept, rebuilt in Lovable with made-up projects and people. The two report screens are from the version my team piloted. The queue, the tree, @mentions and the failed check came after the usability test. Click a screen to enlarge it.
After the test. The review queue. Every column sorts and filters.After the test. A review: job details, progress and the checklist as a tree.After the test. A failed check opens in place, with a note, a screenshot slot and the conversation.After the test. Typing @ suggests people with their role and team.In the pilot. The report counts issues, improvements and checks not done.In the pilot. Approve stays locked until every check is done.
05 · Edge cases
Work goes back for fixes, but round two isn't designed
Handled in the prototype
A half-finished review can't be signed off. Approve stays locked until every check is done, and the report counts the checks not done.
A check that doesn't apply to a job can be marked N/A rather than forced into a pass or a fail.
A problem that isn't serious enough to fail goes under "needs improvement", and the report lists those separately from the fails.
A review with a fail can be returned for fixes, with a note on each issue saying what the team must do.
What I'd design next
Designed after the pilot. Not built or tested.
The flow has a loop back to the checklist, and the report has a Return for fixes button. I never designed what the reviewer sees when the fixed drawing comes back. The tool was meant to keep a record of who checked what, so a check that failed and then passed has to show both results.
Concept, not built. Round 2 of the same review. Only the checks that failed or needed improvement are open.
Round 2 opens in the same review rather than a new one, so the first round's notes and screenshots stay on their checks.
Only the checks that failed or needed improvement are open. The ones that passed carry over, and the reviewer can reopen any of them, because a fix can break something else.
The round 1 note is read only and the author's reply sits next to it, so the reviewer compares the fix with the original comment.
The report would show both rounds for each check, with who checked it each time.
Two more cases I'd look at after that. An author might disagree with a fail. The conversation is there for that, but there is no disputed state and nobody is named to decide. In a small team a reviewer will sometimes be asked to check their own drawing, and the report should at least show that.
06 · Outcome
Piloted on about 10 projects
My team, the measured survey team, used it on about 10 projects. Each piece of feedback was written once, next to its check, so nobody had to rewrite it. Before the tool, that rewriting took 2 to 3 hours per project. I didn't time it again during the pilot, so the saving is an estimate.
Senior stakeholders wanted to know what I was proposing. In the end the tool wasn't a priority for DPR, and the one engineer who would have maintained it already covered everything else. I think it wasn't worth the cost for a tool that two or three teams would use. Phase 2, with the second QA team and the contractors, didn't go ahead.
From a demo: the head of the analyst team saw that the export could produce the reports they send to surveyors, so I kept the export flexible.
07 · Testing the phase 2 concept
Six changes from a usability test
I tested the phase 2 concept with one person from outside the industry. They had never done drawing QA, so they got stuck on things my team had stopped noticing.
Feedback
The To review and In progress tabs didn't look clickable
Change
Pointer and hover on everything you can click, and a whole row opens its review
Feedback
They wanted to sort and filter by clicking a column
Change
Every column header sorts and filters, and active filters show as chips
Feedback
Back didn't return them to where they had been
Change
Back keeps the tab, filters and sort, and so does the browser button
Feedback
They wanted to tag people and ask someone else to review
Change
Reviewers, assignee and contributors, Request review, and @mentions
Feedback
The checklist should branch like a tree
Change
Sections nest under the review type, with progress for each section
Feedback
It felt like a dull tool
Change
Loading states, a progress bar and short transitions between pages
08 · Reflections
What I'd do differently
Narrow earlier. I designed for six problems before asking which one mattered most.
Share rough work sooner. I thought my mind map wasn't good enough to show, and it was the most useful thing I shared.
Measure during the pilot, not only before. I timed the admin before the tool but not after, so the saving is still an estimate. I'd also track the time from feedback to fix.
From my research board. After the interviews I started with a dashboard, project tracking and a resource library. The pilot kept only the QA review branch.
BonusBuilt over the hackathon weekend
Bagcheck
What did the hackathon do to your face?
A tongue-in-cheek app for the morning after. Scan a selfie on the first morning and again on the second, and Claude scores how tired you look: under-eye puffiness, dark circles, dull skin and red eyes. Then it gives you a 20-minute fix to be pitch-ready, and a slider puts Day 1 next to Day 2.
The practice scan works any time. Real scans open between 05:00 and 12:00.
Claude reads the photo you give it. Just for fun, not a medical reading.
