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 for people doing complex technical work. Along the way I kept finding processes worth fixing, which is how I started designing and building tools.
This desktop is my portfolio.This page is my portfolio.
Prefer a normal page?
Currently: open to product design roles · London
work/
Selected work
An internal tool, two hackathon wins and a personal project.
WinnerEngine by Starling challengeHuddleHive Hack 2026
MoonMates
Turning “we should catch up” into a booked night out
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
Platform
Mobile app
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 invented 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
Taking the effort out of meeting up
Let the moon set the rhythm
Agreeing on a date is often where plans stall. A lunar cycle of 30 days 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 virtual card that works once 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 Pizza Card that works once, 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.
Letting patients on waiting lists log symptoms by talking
A spoken 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
Platform
Mobile app
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
Voice first, in the GP's own form
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 prefilled 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 prefilled 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. No patient has used it.
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.
Personal projectConceptRural Croatia
Cow Compass
Helping small farms find an escaped cow, even without signal
It started when my family's two bulls went missing for nearly two weeks. I interviewed four farming households in rural Croatia and designed a clickable prototype for the moment a cow gets out.
Research
4 interviews
Where
Gornji Skrad and Lasinjski Sjeničak
My role
Everything, from research to prototype
Built with
Paper, FigJam, Claude Code
Platform
Mobile app
All 16 cows are safeNorth field · updated just now
The idea
When a cow gets out, the farmer needs to know where she is, how old that position is, and how to reach her.
Cow Compass answers all three on one screen, and keeps working when the phone loses signal.
Small farms lose animals and look for them the old way
In spring 2024 two bulls got out of my family's farm and were missing for nearly two weeks. My parents and the neighbours lost time and money searching, and the bulls came back thin and stressed. My family wished they'd had a way to track them.
About 90% of the world's 570 million farms are run by families, and 69.5% of Croatian farms are smaller than 5 hectares. Trackers on the market are built for large commercial herds, priced per collar with a monthly fee.
The farmers in Gornji Skrad and Lasinjski Sjeničak keep 5 to 20 animals. They find them by looking, listening for the bell, using food as bait and asking neighbours.
What they told me
Nobody knows where an animal is until someone finds it.
A search brings panic, and the fear of an accident or a neighbour's damaged crops.
Searching means long walks over rough ground, sometimes every day.
From the interviews I made one persona: a smallholder of 50 with 5 to 25 cows, poor signal and little technology.
What's on the market
eShepherd, Nofence, mOOvement and Monil are built for commercial herds, and cost is where smallholders stop. A small farmer in Australia wrote that a $60 tag already hurts. My SWOT became three rules.
Start with safety and escape alerts rather than heavy analytics.
Design for weak signal from day one, because it's normal in these villages.
Treat the collar as something I don't control, and say on screen what it can and can't see.
03 · Journey map and user flow
Following Daisy from the alert to the log
I mapped one escape, Daisy, cow number 7, from a normal morning to looking back on it, with what the farmer thinks and what the app could do at each stage.
Redrawn from my FigJam board. The thoughts are the farmer's as I imagined them after the interviews, not quotes.Redrawn from my FigJam board. The “no” branch of the sync question became the offline state in the prototype: the last known position, labelled with its time.04 · From paper to prototype
Sketches first, then wireframes
I sketched on paper first, including what the app shows when the connection drops, then drew wireframes in FigJam for the escape.
Offline mode on paper. Last sync, last known status, and a note that live updates are paused.Animal status. Without signal the farmer can still log a check, and it waits for upload.Wireframes in FigJam. The alert, the map centred on the lost cow, and the route to her.
In 2026 I built the clickable prototype with Claude Code, on an illustrated farm with sixteen cows that wander.
The research, sketches, wireframes, journey map and user flow are done by hand. Claude summarised my interview notes and pointed at patterns and things I might have missed, and I took those on board.
05 · Key decisions
Designed for a phone with no signal
Answer the first question first
My sketches started from what a farmer asks in the morning: are my animals safe, does anything need me now, what happened overnight. So the Today screen opens with one answer, all 16 safe or who is out, before any map or list.
Show how old every position is
A position from 40 minutes ago looks live unless the app says so. So every position carries a time, a cow that isn't live turns grey, and “updated” becomes “seen”, as in my wireframes.
Keep the walk going without signal
GPS works without mobile signal, so when the signal drops the compass keeps pointing at Daisy's last known spot. It turns grey and draws a circle that grows every minute, so the farmer sees how sure the app is without reading anything.
Log it in ten seconds
Tap a reason, record a voice note or skip. It saves on the phone and sends when there is signal. The reasons are placeholders until farmers name the real ones.
Only alert for real problems
Cows graze right along the fence and GPS wobbles by a few metres, so near the fence the app waits two minutes before calling it an escape. A cow that is clearly out alerts straight away, and two cows out together get one alert, because if you find one, the other is there too.
One set of state colours
Green is safe, amber needs a look, red is an escape and grey isn't live. The colours mean the same on every screen and stay separate from the playful farm drawing.
06 · Built for the field
Made to be used outside
A farmer on a hill and a site manager in PPE have a lot in common: bright light, cold or gloved hands, one hand busy and a signal that comes and goes.
Main buttons 58 px tall and full width, smaller ones 48 px.
The main action sits low, within reach of a thumb.
Dark outlines and solid colours for sunlight, with 5.3:1 contrast on the main buttons.
A 64 px distance on the compass, readable at arm's length.
Nothing to type.
I haven't tested any of this outside yet. Sun and gloves are the first things I'd check with farmers.
07 · The prototype
Four flows on one farm
Four flows: a morning check, Daisy getting out, no signal, and the herd with its history. Try it here, and use the Demo menu at the top to switch the phone signal off.
A normal morning. One answer first: all 16 are safe.The alert names the cow, the place and the time.How far, which way, and how fresh the position is.A big arrow and a distance for walking, readable at arm's length.Back inside. Tap a reason or say it, or skip.The log points at the north gate.
No signal. The last picture, with its time, and grey cows.“Seen” instead of “updated”. Marking her as found still works.Signal drops during the walk. The compass keeps going, and the circle grows with every minute.Saved on the phone, and sent when the signal is back.
Cows that need something come first.Patterns per cow turn escapes into a fix: the gate latch.
08 · States & edge cases
Not every alert is an escape
Handled in the prototype
Farmers know where their animals head when they get out, so they mark those places once: the road, a river, a neighbour's crops. A cow near one is the most urgent alert, with a button to call a closer neighbour.
At night collars report every 30 minutes but check the boundary themselves, so a 2 am escape still alerts straight away.
A cow alone and still for longer than usual gets a calm amber nudge, because she could be calving or hurt. Stillness alone would ring every night, because cows lie down for hours.
A quiet collar shows as last seen.On the fence line. Two minutes before it counts as an escape.Two out together, one alert.Near a hazard the farmer marked. The most urgent alert.Night saving, and alerts that still come straight away.A low battery waits for the evening feed.A cow on her own, away from the herd, gets a calm nudge.
What I'd design next
With no signal, the escape alert can't reach the farmer's phone, and seeing it once the signal is back can be too late. So I'd let the farmer add a family member or a neighbour who also gets escape alerts, sees only the animal that is out, and can flag that they've seen her. It's a concept and isn't in the prototype.
09 · Outcome & next steps
A concept, not tested with farmers yet
The research is real and the prototype is built from it, but no farmer has used it yet.
What I'd test first
Show it to the four households, starting with the alert. Two minutes on the fence line might be too long near a road.
Ask what they'd pay, because price stops smallholders before any screen does, and a design can't fix that alone.
Find out who should get the alert. It might be a son or a daughter rather than the owner.
about.txt
From delivering projects to designing products
Hi, I'm Alex, a Product Designer based in London.
Background
Before moving into design, I spent five years in measured building surveys, laser scanning sites, processing point cloud data, and managing complex spatial data projects from site to client handover. I've been the end user on the ground, so I know these technical workflows from the inside. I also trained colleagues in AutoCAD, AutoLISP and our drawing QA process.
How I moved into design
I moved into design by fixing my own team's workflow. At DPR I designed Benchmark, a drawing QA tool my team piloted on about 10 projects. In 2026 my hackathon teams won two challenges: Accurx with CareLoop and Engine by Starling with MoonMates.
What I'm looking for
I'm looking for a product design role in construction tech or geospatial, on tools for the kind of work I used to do on site and in the office.
A standardised way for a survey team to check drawings
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, and my team piloted it on about 10 projects.
Where
DPR, London
When
Nov 2025 – Sep 2026
My role
Sole designer & builder
Built with
Figma, Lovable, Claude
Platform
Desktop web app
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. I wasn't the QA teams' manager, but I introduced the new process to them.
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
Handed each version to my team with a demo, and changed the design after every iteration
Trained colleagues on the QA process
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
What I did by hand, and where AI helped
I did the research, the rough wireframes and the information architecture by hand in Figma. Claude summarised the interview notes, pulled out key takeaways and pointed at things I might have missed. When it noticed a pattern in my work, I took it on board.
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 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 stayed: a pass, needs improvement or fail on every check, a screenshot on its check, and a report of what passed and what needs work.
First idea. The checklist, with a note and a screenshot on a check.First idea. Screenshots, each linked to its check.First idea. The report: what passed and what needs improvement.
The screens are rebuilt in Lovable with invented projects and people. Click one to enlarge it.
The report counts issues, improvements and checks not done.Approve stays locked until every check is done. Return for fixes sends the work back.
A failed check opens where it sits, in the teams' own words, so the feedback stays next to its check.The review queue. Every column sorts and filters.A review with job details, progress and the checklist as a tree.Typing @ suggests people with their role and team.
05 · Edge cases
Work goes back for fixes, but round two isn't designed
Handled in the prototype
An unfinished review can't be signed off, 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", listed apart 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 loops back to the checklist, but 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 after that. An author might disagree with a fail, and there is no disputed state or anyone named to decide. In a small team a reviewer will sometimes 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. 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.
While I was at DPR, my team used one standard QA process where there hadn't been one before.
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.
“I could actually use this for something else as well. If I had it today, I could send the report straight away and use it further on, for planning applications to the council.” Head of the analyst team, after a demo. 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.
BonusStarted over a hackathon weekend
Bagcheck
What's your bag status?
A joke app for any time of day. Take one selfie and Claude scores how tired you look: puffiness under the eyes, dark circles, dull skin and red eyes. The result comes as an airport bag tag. Tiredness turns into kilos, and anything over 23 kg gets a HEAVY tag. Then you get five quick fixes to look awake.
Bagcheck doesn't save your selfie. Closing the page clears it.
Open it signed in to Claude for Claude's read. Without that, you get a rough read in your browser.
