Tidepool
Lead designer
A field app for marine biologists that keeps logging samples, tides and positions when the boat is hours from the nearest signal.
Four projects from the last three years, from research vessels to municipal open data.
Lead designer
A field app for marine biologists that keeps logging samples, tides and positions when the boat is hours from the nearest signal.
Product designer
Replacing a 20-year-old member banking system for a community credit union without losing the workarounds staff had come to depend on.
Design and front-end
A live map of tram and bus delays that gives commuters a quick answer and gives dispatchers the full picture of the network.
Author and designer
A free, plain-language guide that walks municipal staff through choosing, cleaning and publishing their first open datasets.
Notes on design, data and running a one-person studio. A new post roughly every three weeks.
Showing all 6 posts
A grey box that said “No data available” taught a boat full of biologists to stop trusting our app, and rebuilding it changed how I design for missing data.
Wet neoprene and a rolling deck make a 44-pixel button hard to hit, so we tested every Tidepool screen with gloves on.
The old member form had 112 fields and two decades of workarounds, and keeping the workarounds mattered more than cutting the fields.
Clients kept misreading the slices, so I switched to sorted bar charts, and the follow-up emails asking “so which one is bigger?” stopped.
Thirty days of drawing fellow commuters on line 6 changed how I think about waiting, and about what the Delay map should show first.
Hourly rates penalise you for getting faster, so here is how I scope and price work around the problem a client needs solved.
No posts with this tag yet. Try another filter, or choose All to see everything.
Last spring I spent three weeks on a research vessel off the coast of Bohuslän, watching marine biologists use the first prototype of Tidepool. The app mostly worked. The screens I was proudest of mostly did not.
The one that failed worst was the tide table. On a good day it showed the next four tide turns for the station nearest the boat. On a bad day, with no signal, a stale cache, or a station that had stopped reporting, it showed a grey box that said No data available. Every researcher who saw that box did the same thing: they put the phone in their pocket and asked the skipper.
“No data available” is technically true and practically useless. It doesn’t say whether the data is missing, late, or never existed. It doesn’t say what to do next. And on a boat, where the next sync could be hours away, it quietly tells people to stop trusting the app.
So we stopped treating the empty state as an error and started treating it as content. We asked a simple question: what do we actually know when we don’t have fresh data? Quite a lot, it turned out. We knew when the last reading arrived. We knew the predicted tides from the harmonic model, which doesn’t need a connection. We knew which station was next nearest.
The new tide card shows all of it:
station Smögen (SMG)
last sync 04:12 · 6 h 40 min ago
next high 11:48 +0.31 m predicted
next low 17:55 −0.22 m predicted
fallback Kungsvik (KVK) · 14 km
Predicted values get a dashed underline and the word “predicted” written out, so the meaning never depends on colour alone. The time of the last sync is always visible, never hidden behind a tap.
An empty state is where your product admits what it doesn’t know. That honesty is part of the design, not a gap in it.
On the second trip, nobody put their phone away at the tide card. One researcher told me she preferred the stale-data screen to the live one, because it told her exactly how much to trust it. That is now the standard I hold every empty state to: it should say what’s missing, why, what we still know, and what you can do about it.
Most products have dozens of these screens, and most of them get written last, by whoever happens to pick up the ticket. They deserve better, because they are often what people see when the stakes are highest.
Maya LindqvistIndependent product designer, Gothenburg
I’m a product designer and writer based in Gothenburg. For the past seven years I’ve worked on software for people whose jobs depend on data: researchers, dispatchers, bank clerks and municipal analysts. I started out drawing maps at Kartverk Studio, spent three years building analytics tools at Norrsken Analytics, and went independent in 2024 to work more closely with the people who use what I design. I usually join a project early, while the problem is still fuzzy, and stay until the first version ships. I prototype in code, run workshops with the people doing the work, and write things down as I go. When I’m not working, I’m usually on a tram with a sketchbook or out on the water in the archipelago.
I’m booking projects that start in January 2027 or later. Tell me a little about the people who’ll use what we make, and I’ll reply within two working days.
maya@lindqvist.example