Leonteq AG · 2020
Moneypenny Design System
Ich definierte die gestalterischen Grundlagen, entwickelte Vue-Komponenten mit und baute die Dokumentationswebsite. So konnten acht Teams mit einem gemeinsamen Designsystem arbeiten.

Meine Rolle
Design System Lead
Team
4 Designer, 4 Entwickler
Zeitraum
18 Monate bis Version 1.0, laufende Weiterentwicklung
Plattform
Vue.js · npm
Wofür ich verantwortlich war
- Ich begann bei null und leitete die Entwicklung bis zur Version 1.0 und den folgenden Releases.
- Ich gestaltete die semantischen Tokens und ihre Zuordnung zwischen Figma und Code.
- Gemeinsam mit dem Entwicklungsteam steuerte ich Vue-Komponenten direkt zur Bibliothek bei.
- Ich gestaltete und entwickelte die Dokumentationswebsite mit interaktiver Komponentenvorschau, API-Referenz und Links zu Figma. Die Komponenteneigenschaften (Props) liessen sich direkt in der Vorschau verändern.
Was ich verbessern wollte
In den Produkten von Leonteq wurden ähnliche Aufgaben zunehmend unterschiedlich gelöst. Teams pflegten unterschiedliche Versionen derselben Bedienelemente, und Designer mussten diese Unterschiede bei jedem Produktwechsel neu kennenlernen.
Ich startete Moneypenny, um eine gemeinsame Grundlage zu schaffen. Ich verantwortete die Designsprache und das Token-Modell und arbeitete direkt an der Vue-Komponentenbibliothek mit. Weil ich sowohl in Figma als auch im Code arbeitete, konnte ich Entwürfe und technische Umsetzung eng aufeinander abstimmen.
◢Kernidee“Die Teams sollten Moneypenny nutzen wollen, weil es ihnen die Arbeit erleichtert.”
◢ Vorgehen
- 01
Die bestehenden Produkte analysieren
Die Bestandsaufnahme umfasste acht Produkte und über 1’200 Screenshots. Sie zeigte mir wiederkehrende Muster und Inkonsistenzen ganz konkret.
- 02
Die gestalterischen Grundlagen definieren
Ich definierte semantische Tokens für Farben, Abstände und Typografie mit einer gemeinsamen Zuordnung zwischen Figma und Code.
- 03
Die Komponentenbibliothek aufbauen
Gemeinsam mit den Entwicklern baute ich Vue-Komponenten. Auf der Dokumentationswebsite konnten die Teams die Komponenten ausprobieren, ihre Props verändern und die zugehörigen Figma-Entwürfe öffnen.
- 04
Die Einführung begleiten
Wir unterstützten jedes Produktteam bei der Migration und prüften Vorschläge und Beiträge in teamübergreifenden Sitzungen.
- 05
Die Weiterentwicklung organisieren
Ich setzte mich für einen schlanken RFC-Prozess ein, mit versionierten Releases, visuellen Regressionstests und klaren Migrationshinweisen.

<template>
<button
:class="[
'mp-btn',
`mp-btn--${variant}`,
`mp-btn--${size}`,
{ 'mp-btn--loading': loading }
]"
:disabled="disabled || loading"
v-bind="$attrs"
>
<MpSpinner v-if="loading" size="xs" aria-hidden />
<slot v-else />
</button>
</template>
<script setup lang="ts">
defineProps<{
variant?: 'primary' | 'secondary' | 'ghost' | 'danger'
size?: 'sm' | 'md' | 'lg'
disabled?: boolean
loading?: boolean
}>()
</script>
Über 60 Komponenten für den produktiven Einsatz. Jede Variante, jeder Zustand und jede Interaktion ist dokumentiert.

Die mit Vue.js entwickelte Dokumentationswebsite bietet eine interaktive Vorschau, eine vollständige API-Referenz und einen direkten Figma-Link auf jeder Komponentenseite.

Im Komponenten-Playground lassen sich Props direkt verändern. Die Vorschau zeigt sofort, wie sich die Komponente verhält und aussieht. So lassen sich viele Fragen zwischen Design und Entwicklung direkt klären.

Volltextsuche nach Komponenten, Varianten, Tokens und Anwendungshinweisen. Jeder Teil des Systems ist direkt zugänglich.
Was sich verändert hat
Die folgenden Ergebnisse wurden für das gemeinsame Projekt berichtet.
- 60+
- Komponenten für den produktiven Einsatz in Version 1.0 veröffentlicht
- 8
- Produktteams haben innerhalb von 18 Monaten auf das Designsystem umgestellt
- 50%
- schnellere UI-Entwicklung nach der Einführung
- 100%
- Übereinstimmung der Design-Tokens zwischen Figma und Vue
Was über die Komponenten hinausging
Ich stellte fest, dass die Einführung genauso viel Aufmerksamkeit brauchte wie die Komponenten selbst. Ein nützliches System musste den Teams ermöglichen, Änderungen vorzuschlagen, Entscheidungen zu verstehen und zu migrieren, ohne ihre Produktarbeit zu unterbrechen.
Ich setzte mich für einen einfachen Prozess für Änderungsvorschläge, fest eingeplante Zeit für die Pflege des Systems und gemeinsame Verantwortung ein. Wir begleiteten die Produktteams bei der Migration und besprachen Beiträge in regelmässigen Sitzungen.
Ausserdem gestaltete und entwickelte ich die Dokumentationswebsite. Dort konnten Nutzer Komponenteneigenschaften prüfen, die API nachschlagen und den zugehörigen Figma-Entwurf öffnen. Die nötigen Informationen sollten direkt bei der Komponente stehen, statt in einem separaten Dokument, das man erst suchen muss.