Selected work
FS.dk
Self-directed · Product Design · Copenhagen
People could find furniture. The hard part was agreeing on when to pick it up.
- Role
- UX Research · Product Design · Prototyping
- Timeline
- 8 weeks
- Tools
- Figma · FigJam
View interactive prototype (FS.dk interactive prototype, opens in new tab)
01 / Overview
A neighbour-to-neighbour furniture exchange for Copenhagen.
FS.dk is a self-directed concept for giving away and picking up furniture in Copenhagen, between neighbours and without money. During the project, the core design focus became pickup coordination.
02 / The problem
Users don't struggle to find furniture. They struggle to coordinate pickups.
Existing platforms leave timing and availability to chat. People repeat the same questions, availability is unclear, plans change and pickups can fail.
- Coordination
- Too much back-and-forth to agree on a pickup.
- Reliability
- Informal plans make cancellations and no-shows easier.
- Trust
- People want more context before meeting a stranger.
03 / Research
I interviewed five people in Copenhagen who had recently given away or picked up furniture through Facebook Marketplace, DBA and local exchange groups.
5 interviews · 30–45 minutes · semi-structured
- 01Coordination took more effort than discovery.
- 02People wanted more context before meeting a stranger.
- 03A failed pickup quickly reduced trust in the platform.
04 / The design decision
Browsing and listings could stay familiar. The part worth redesigning was what happened after someone wanted an item.
Move pickup coordination into the product instead of leaving it to open-ended chat.
- Discover
- Schedule
- Confirm
- Complete
- Feedback
The concept deliberately trades some flexibility for a clearer, more structured pickup flow.
05 / Final experience
From discovery to a completed exchange.
01 — Discover
Browse nearby furniture and understand what is available.

02 — Schedule + confirm
Choose a pickup time, send the request and follow its status.

03 — Complete + feedback
Confirm the exchange and build trust through reviews.

Designed to improve
- Less effort
- Less time spent coordinating.
- More clarity
- Both people know what was agreed and what happens next.
- More trust
- Profiles, completed exchanges and reviews provide more context.
This is a concept, so these are intended outcomes rather than measured production results.
06 / Reflection
The real problem was coordination, not discovery.
The visible problem was finding furniture, but the friction started after two people matched and had to agree on when to meet.
The main thing I would validate next is whether choosing a pickup time inside the product is enough to reduce no-shows, or whether reminders and additional trust signals are needed.
I now spend more time understanding which part of a flow actually determines whether the product works before moving into screens.
Interview methodology
I conducted five semi-structured interviews with people in Copenhagen who had recently given away or picked up furniture through Facebook Marketplace, DBA and local exchange groups.
5 interviews · 30–45 min · Copenhagen
Frustrations
- Coordination
- Repeated messages to find a time that worked for both people.
- Uncertainty
- Availability and commitments often stayed vague until the last moment.
- Reliability
- Changes, cancellations or no-shows made exchanges feel fragile.
- Trust
- People wanted more context before arranging a meeting with a stranger.
Constraints
- Community marketplace
- This is a neighbor to neighbor context, so heavy verification or payment flows did not fit.
- Pickups happen in person
- Time and location had to be part of the main flow instead of something people sort out later.
- Trust between strangers
- A new product has no long rating history, so trust had to come from small and simple signals.
- Self-directed project
- There was no client brief, so I set the scope myself and went deep on a few flows instead of covering everything.
Limitation
Formal usability testing was not conducted, so the proposed interaction and intended outcomes would need further validation.
Trade-offs
The concept deliberately trades some flexibility for a clearer, more structured pickup flow.
Trade-off 01
- Decision
- Focus on pickup coordination instead of chat.
- What was sacrificed
- The flexibility people are used to when messaging freely.
- Why it was the right decision
- Choosing a time inside the product creates a clearer commitment and reduces the coordination needed in open chat.
Trade-off 02
- Decision
- Keep pickup coordination simple and structured.
- What was sacrificed
- More flexible scheduling options and open-ended messaging.
- Why it was the right decision
- The concept prioritizes a clear path from choosing a time to confirming the exchange.
Trade-off 03
- Decision
- Design for one city first.
- What was sacrificed
- Multiple regions, languages and wider reach.
- Why it was the right decision
- Staying local kept pickups realistic and let the concept solve trust and logistics properly.
Publishing flow
Create a listing, define pickup availability and publish it.

Publishing was explored as a secondary concept outside the core prototype.
What I would test next
If this concept moved into validation, these would be the next hypotheses to test.
- Commitment
Does a clearer commitment step reduce no-shows?
- Reminders
Does the timing of a reminder change whether people show up?
- Trust signals
Which signals actually make people feel comfortable meeting a stranger?
- Calendar
Does connecting a calendar make picking a time easier or heavier?