Tim Johansson — Design Engineer

1. Core before gamification

Stakeholders pushed hard for an advanced player card and level system as the home screen. I argued for shipping the core loop first: exercises, activity log and coach communication. Gamification stayed light until the foundation proved right. Three months after launch the core loop is what the app runs on, and the advanced card is still unbuilt.

2. Value for non-members

The original plan had no journey for users without a golf club or a Balance Golf coach. I designed a clear free path: activity log, exercises and recorded trainings. Premium features were tucked away, so anyone could find value in the app. I also found it was a business opportunity: a free path that proves its value is a way to attract new members.

3. When the metric didn't exist

The home screen was meant to be built on official handicap data. Half way into the build I found the sources couldn't deliver it reliably, and the number the whole screen depended on wasn't going to exist. Rather than drop the screen, I turned it around: players pick the areas they want to improve, set a goal per KPI, and track them at a glance. Progress they define, instead of a single number handed to them. Stakeholders got hands-on with the prototype and it went to production. The structure held, the details moved in build. The version we shipped suits a club player better than a handicap would have. A handicap tells you where you stand, these tell you what you are working on.

[ Video — the KPI section on a phone, picking the areas to improve, setting a goal per KPI, and the home screen tracking them at a glance ]

4. A flexible data structure

Together with the backend engineer I chose a generic data model for KPIs, exercises, and activities early on. It constrained design and code upfront, but let us add any KPI, exercise, or activity without app updates, and respond fast to coach and player feedback during development.

[ Video — Player Hub — the achievements XP ring filling, with a particle burst scattering off it as the level lands ]

Particles stand for XP throughout the app. Here they move slowly, for improvement that accumulates rather than arrives.

[ Video — Player Hub — the round-complete screen counting up +120 XP, the level bar filling behind it ]

The particles break through a barrier as the player moves up the XP scale.

[ Video — Player Hub — the new-activity card pulsing as a fresh round lands in the feed ]

New activity and important messages get a subtle pulse, left to right across the home page card. Enough to catch the eye on arrival, not enough to keep asking.

1. One screen, after onboarding

I set the constraint before I set anything else: everything happens on one screen. No tab bar, no settings maze, nothing buried a level deeper than the list it belongs to. It made every later feature request a real argument, because if it could not live on that screen it had to justify replacing something already there. Recipe import, camera capture, voice input, bulk add with undo, smart suggestions, sharing and collaborators all arrived after the rule was set, and every one of them opens over the list rather than somewhere you navigate to. The list screen is 23 view files now, and it is still one screen.

2. The model is the fallback, not the feature

Categorisation is the one piece of real intelligence in the app, and I built it so the model goes last. An item is normalised first, stripping quantities and packaging. Then a deterministic rule engine matches phrases before single words, in Swedish and English, so krossade tomater lands in canned goods and sauces rather than produce. Only when the rules have nothing does it reach the on-device model. If you move an item yourself, that override is stored and beats both from then on. A model that is right nine times in ten is still wrong about the aisle you walk every week, and being wrong twice about the same thing is what makes someone stop trusting an app. Rules keep the common case instant and identical every time, the model takes the long tail, and your correction is permanent.

3. Offline first, because the shop is a dead zone

Two people share a list and one of them is in a basement supermarket with no signal. Writes go to the local store immediately and queue as outbox mutations. A coordinator watches the connection, flushes when it returns, and merges on pull with last write wins. A mutation already in flight refuses to absorb a newer payload, so a second tap during a slow request cannot quietly overwrite what you meant last. Checking an item off never waits for the network, which is the only way the app is usable in the place it is actually used.

4. The sync engine has no interface

All of that is invisible, and staying invisible took its own decision. Every remote operation in flight increments one counter, and the only thing that counter drives is the wave in the background grid. No spinner, no toast, no syncing label anywhere in the app. The paper moves while the app is thinking and settles when it is done. It is one decision made twice, once as an engineer choosing what state to expose and once as a designer choosing what it should look like, and it survives only because nobody had to hand it over.

[ Video — Gott — dictating a shopping list, each item appearing in the field the moment it is recognised ]

Words land in the field as they are heard rather than all at once when you stop. Holding them back hides whether it caught you, so you end up repeating yourself into silence. Streaming them means a mishearing is obvious while you are still talking, and you can just say it again.

[ Video — Gott — a shared Family list on its paper grid, carrying from the light theme into the dark one ]

The paper grid is drawn rather than a texture image, so it re-tints with the theme instead of being swapped for a dark copy. One rule renders both, which keeps the light and dark lists the same object rather than two designs that merely resemble each other.

[ Video — Gott — the profile screen's generated avatar, a liquid shape that keeps moving while the screen is open ]

An account with no photo usually leaves a dead grey circle with an initial in it. Generating the mark instead, and letting it keep moving, turns the emptiest state on the screen into the liveliest thing on it, and it costs the person nothing to get one.

[ Video — Gott — the paper grid shifting with the accelerometer as the phone is tilted in the hand ]

The grid reacts to how the phone is actually being held, so the sheet behaves like a surface catching light rather than a picture of one. It is the kind of detail nobody names, and the reason a list app can feel like paper instead of a table of rows.

[ Video — Gott — the welcome screen, its paper grid rippling behind the mark before any content exists ]

The first screen is where a material gets established, so the grid is already moving before there is anything on it. By the time the first list appears the paper reads as the surface the app is printed on, rather than a background picked out to sit behind it.