Wisr
Overview
A marketplace for hiring the skills you need, delivered over video and chat.
Details
At a glance
- Project type
- Consumer marketplace, mobile and web
- My role
- Led the product: defined the concept and the requirements, designed the brand and the interface, and directed an external development team through to completion.
- Category
- Products
- Status
- 2024–2025
- Collaboration
- Spring Up Labs (Product collaboration)
What I did
- Defined the product concept, its functionality and the design architecture behind it
- Translated business needs into clear, buildable requirements for the development team
- Acted as the link between the company and the developers throughout the build
- Planned and followed up the work, prioritised functionality and reviewed each implementation
- Created the visual identity, the brand and the design language
- Designed the interface, the structure, the navigation and the key user journeys
- Held the technical solution to the product vision and to what users actually needed
- Took part in testing and evaluation, and carried the product through to completion
Next project
Leica Look
The need
Hiring an expert for an hour is harder than hiring one for a month. You need to find someone with the right skill, judge whether they are any good, agree what it costs, meet them, and have a record of it afterwards. Every one of those steps normally happens in a different place.
Wisr set out to hold all of it in one product: find the right person, see whether they are available now, book them, pay a known price, talk to them over video or chat, share the files that matter, and keep the history.
My contribution
I led the product. I defined what it was, what it had to do, and how it should feel, then turned that into requirements a development team could build from.
The build ran with Spring Up Labs and an external development team in India, so most of my job was making intent unambiguous across a distance and a time zone. I wrote the requirements, prioritised what got built in what order, reviewed each implementation against the design, and stayed the single point of contact between the company and the developers until it was finished.
I also made the thing itself: the brand, the design language, the interface, the structure and the journeys through it.
Decision
Settle the price and the clock before anyone commits
- Context
- Paying a stranger by the minute is unfamiliar. If the cost or the duration is uncertain at the moment of booking, people stop.
- What I decided
- Time and cost are one piece of logic, surfaced identically on the profile, the booking control and the confirmation. The same number, in the same words, three times.
- Trade-off
- It gives up the flexibility of quoting after the fact, and it makes the rate one of the first things a visitor judges. For a product that has to be trusted quickly, that is the right trade.
What the product had to hold
- Structured search, so a vague need resolves to people with a specific, checkable skill rather than a page of results.
- A booking system with availability, and an online indicator so it is clear who can talk right now.
- Time and cost logic shared by the booking, the payment and the receipt, so all three always agree.
- Video and chat sessions, with the option to record.
- File sharing, because most consultations need something looked at.
- A tracked history of sessions and data, so the work is not lost when the call ends.
Built for where it launches
Sign-up offers Vipps alongside email, because in Norway that is the identity and payment method people already have on their phone. It removes the slowest step in the whole journey.
Outcome and reflection
Carried through to completion with a distributed team. The lesson I keep is that a requirement is only as good as the thing that gets built from it: writing the intent down clearly, then reviewing every implementation against it, did more for the result than any single design decision.