Jodel

Role and Scope

Product Design / Design system architecture · Duration: 2022 - 2024

The product

Jodel is an anonymous social media app that lets you chat with people around you. The experience varies greatly depending on your physical location.

Context

When I joined Jodel, the brand and product were already mature. They had a strong visual identity, a clear voice, 8 years of active development behind them, and a significant number of daily active users.

I joined as a senior product designer with the expectation of turning briefs from product managers into production-ready design specs. Even though I had no influence in creation of the brand and the style of Jodel itself, staying true to the existing aesthetic came naturally as it closely aligned with my own taste for bold colors and playful animation.

Team structure

Product development ran as two squads: one focused on acquisition, the other on new features and iteration. I was part of the latter. Each squad had its own PM, designer and four engineers (2 for Android and iOS respectively). There was little interaction between the team members outside their own squad. That isolation between squads manifested in the product as unclear UI patterns and an overhead of components that could have been merged into far fewer variants.

Templates to systems

Designers had created two files labeled "design system", one for iOS, one for Android. In practice they were collections of screens copy-pasted into new feature specs when a similar pattern was needed. While some patterns differed between the two clients, a majority of the design assets could have been shared globally between the two.

The handover process was the clearest symptom of the underlying problem. For every feature, a designer prepared four separate specs. On paper it made sense: two clients + two themes = four outputs. In practice it meant redrawing or copy-pasting the same button, list-item, card four times over, for every feature, with no centralized place for global changes that would cascade across every spec at once.

Those files only ever served designers. A Figma file with no strict correlation to the actual codebase is just a loose plan that never materialized. Overseeing that a design plan actually gets built is part of a product designer's job, and that isn't possible without close collaboration with engineers.

Creating structure

While the structural painpoints were clear early on, you can't turn into a consultant on processes from a product designer seat without first providing working proof.

The product's aesthetic had originally been driven by marketing design, which was a good starting point, but the product needed its own layer of rules, dictated by product's needs rather than what was meaningful for marketing. I began referencing the live apps for functionality and took the visual cues from the "design system" and marketing files. Even though the design files didn't function as a design system, they did hold the right visual language. On the side I began to create a catalog of reusable components to serve my own needs. Each feature spec I delivered grew the collection of stable components. Every new design spec was faster to ship than the previous one.

On top of that foundation, I built an override-based version of the same components, one spec, with theme and platform variations handled as overrides rather than separate drawings. Buttons, cards and most UI elements already looked identical across iOS and Android and there was no reason to store them twice. The real platform differences lived only in a couple of components; the header and the tab bar, handled with a simple property toggle instead of a separate isolated component.

I knew the four-spec process was redundant from the beginning, but I kept producing all four for a while regardless. It served as a testing ground for myself to see that the overrides were really working. The other reason was that the team wasn't ready to trust a shortcut they had not seen proven yet. I waited for the right moment when the system was mature enough for me to share with the organisation.

Two audiences, two different proofs

This was more than a technical fix. I was about to change the working culture between product, design and engineering. Getting the organization to accept the new approach took more than one conversation, aimed at two audiences who needed convincing in completely different ways.

Formalizing what was working

By early 2023, well under a year after I'd started, the informal trust with engineers had turned into something concrete: a dedicated design system slack channel, where I could reach engineers directly on components that were specced and ready, and followed up until they were actually implemented. It became the operational backbone of the whole effort and the place where components moved from specified to shipped.

Underneath that, I introduced a maturity model to track component stability:

This gave designers and engineers a shared vocabulary for where any component stood, and made refinement sessions dramatically shorter. Most common components no longer needed their behaviour re-explained every time they came up. Eventually this evolved into a proper multidisciplinary design-system effort, with direct engineering collaboration earned by demonstrating results first and asking for structure second.

Where it landed

By the time I left, standardization was simply how features got built. Every new feature shipped with stable components and if the feature required anything new it was either provided on the spot or delivered iteratively. Whenever there was downtime between feature work, older views of the application were iteratively refactored component by component. For example when the main CTA button had reached its fully standardized status, the next step was to scope a batch of screens where it appeared and replace it with the stable, tried and tested variant. The system had found its way into the team's rhythm, rather than stagnating once the initial push was over.