All case studiesAlle Case Studies Enterprise · Mobile · B2B · Research

A tasks app whose real competitor was a sticky note

Eine Aufgaben-App, deren echte Konkurrenz die Haftnotiz war

A mobile tasks module for an enterprise productivity suite used by large enterprises — built from scratch over 2.5 years, natively on Material 3 and spec-first, on a simple bet: beat paper, not Jira.

Ein mobiles Aufgaben-Modul für eine Enterprise-Productivity-Suite in großen Unternehmen — über 2,5 Jahre von Grund auf gebaut, nativ auf Material 3 und Spec-first, mit einer einfachen Wette: Papier schlagen, nicht Jira.

RoleRolle
Senior Product Designer · UX ResearcherSenior Product Designerin · UX Researcherin
CompanyUnternehmen
MyOffice · enterprise productivity suiteMyOffice · Enterprise-Productivity-Suite
Timeline
Aug 2022 – Jan 2025
Team
Agile team · PO · Engineers · QAAgiles Team · PO · Engineers · QA
Enterprise mobile tasks app — task lists and quick capture
Aggregating lists with badge navigation — the variant that won the split-test
Aggregierende Listen mit Badge-Navigation — die Variante, die den Split-Test gewann

01The problemDas Problem

Employees manage work tasks in scattered tools — trackers, notes apps, paper, memory. The suite already had a task module, but it was invisible: only 7% of internal users (9 of 134) had ever used it — mostly because they never knew it existed.

Beschäftigte verwalten Arbeitsaufgaben in verstreuten Tools — Trackern, Notiz-Apps, auf Papier, im Kopf. Die Suite hatte bereits ein Aufgaben-Modul, aber es war unsichtbar: Nur 7% der internen Nutzer (9 von 134) hatten es je verwendet — meist, weil sie gar nicht wussten, dass es existiert.

The job wasn't to add features. It was to figure out what a task tool has to be before people even consider adopting it.

Die Aufgabe war nicht, Features hinzuzufügen — sondern herauszufinden, was ein Aufgaben-Tool sein muss, bevor Menschen es überhaupt in Betracht ziehen.

02Research: jobs, not featuresResearch: Jobs statt Features

13
JTBD deep interviews plus usability tests of a lo-fi concept, 1 hour eachJTBD-Tiefeninterviews plus Usability-Tests eines Lo-Fi-Konzepts, je 1 Stunde
7
competitor apps torn down — Outlook, Google Tasks, Todoist, TickTick, Apple Reminders and othersWettbewerber-Apps analysiert — Outlook, Google Tasks, Todoist, TickTick, Apple Reminders und weitere
7%
of internal users had ever touched the old module — the baseline to beatder internen Nutzer hatten das alte Modul je angefasst — die Messlatte

13 JTBD deep interviews — combined with usability tests of a lo-fi concept, one hour each — with non-developers who live in Google Tasks, Todoist, Notion, TickTick and the like. The jobs that mattered: capture a task in seconds; handle urgent requests without tracker overhead; get an explicit completion confirmation as a psychological reward; keep deadline-free notes so overdue alerts don't demotivate; and plan only 1–2 weeks ahead.

13 JTBD-Tiefeninterviews — kombiniert mit Usability-Tests eines Lo-Fi-Konzepts, jeweils eine Stunde — mit Nicht-Entwicklern, die in Google Tasks, Todoist, Notion, TickTick und Co. zu Hause sind. Die entscheidenden Jobs: eine Aufgabe in Sekunden erfassen; dringende Anfragen ohne Tracker-Overhead erledigen; eine explizite Erledigt-Bestätigung als psychologische Belohnung; Notizen ohne Deadline, damit Überfälligkeits-Alarme nicht demotivieren; und nur 1–2 Wochen im Voraus planen.

The competitor teardown of 7 apps — Outlook, Google Tasks, Todoist, TickTick, Apple Reminders and others — delivered the strategic insight of the project:

Der Wettbewerbs-Teardown von 7 Apps — Outlook, Google Tasks, Todoist, TickTick, Apple Reminders und weitere — lieferte die strategische Erkenntnis des Projekts:

Key insightZentrale Erkenntnis The main competitors are paper, sticky notes and simple notes apps — not Jira. "Simple & lightweight" became the fixed UI principle, agreed with the product owner before a single screen was drawn. Die Hauptkonkurrenz sind Papier, Haftnotizen und simple Notiz-Apps — nicht Jira. „Simple & lightweight" wurde zum festen UI-Prinzip, vereinbart mit dem Product Owner, bevor ein einziger Screen entstand.

03Research & competitors: the paper trailResearch & Wettbewerb: die Belegkette

Research here wasn't a phase — it was a documented pipeline. The ToDo 2024 development cycle ran on a written research plan, 5 documented user interviews with full protocols in a shared spreadsheet, a 16-page study on a new task-module representation that consolidated the results, and an agreements log where every decision with stakeholders was recorded instead of relitigated. A parallel 2024 CustDev cycle — 8 documents — fed the module roadmap.

Research war hier keine Phase — sondern eine dokumentierte Pipeline. Der ToDo-Entwicklungszyklus 2024 lief auf einem schriftlichen Research-Plan, 5 dokumentierten Nutzerinterviews mit vollständigen Protokollen in einer geteilten Tabelle, einer 16-seitigen Studie zu einer neuen Darstellung des Aufgaben-Moduls, die die Ergebnisse konsolidierte, und einem Vereinbarungs-Log, in dem jede Stakeholder-Entscheidung festgehalten statt neu verhandelt wurde. Ein paralleler CustDev-Zyklus 2024 — 8 Dokumente — speiste die Modul-Roadmap.

The competitor work got the same treatment: two dedicated competitor studies — one on task lists (14 pages), one on the task view (18 pages) — so every pattern decision could point at evidence, not taste.

Die Wettbewerbsanalyse bekam dieselbe Behandlung: zwei eigenständige Competitor-Studien — eine zu Aufgabenlisten (14 Seiten), eine zur Aufgabenansicht (18 Seiten) — damit jede Pattern-Entscheidung auf Belege zeigen konnte, nicht auf Geschmack.

5
documented user interviews in the ToDo 2024 cycle — protocols kept in a shared spreadsheetdokumentierte Nutzerinterviews im ToDo-2024-Zyklus — Protokolle in einer geteilten Tabelle
16pp
study on the new task-module representation — the research results in one documentStudie zur neuen Darstellung des Aufgaben-Moduls — die Research-Ergebnisse in einem Dokument
32pp
of competitor analysis across two dedicated studies — task list (14pp) and task view (18pp)Wettbewerbsanalyse in zwei eigenen Studien — Aufgabenliste (14 S.) und Aufgabenansicht (18 S.)
90MB
master Figma file for the ToDo 2024 cycle — the scale of iteration behind the shipped specsMaster-Figma-Datei des ToDo-2024-Zyklus — das Ausmaß der Iteration hinter den Specs

04Design decisionsDesignentscheidungen

Navigation. A drawer plus swipe navigation across aggregating lists — All, Due today, Upcoming, Overdue — alongside user-created lists with sharing.

Navigation. Ein Drawer plus Swipe-Navigation über aggregierende Listen — Alle, Heute fällig, Anstehend, Überfällig — neben nutzereigenen Listen mit Freigabe.

Speed over ceremony. Tap-to-complete for the reward moment, FAB creation for the seconds-fast capture the interviews demanded. Task fields cover priority, reminder and assignees; recurrence works like a simplified calendar pattern instead of a rules engine.

Tempo statt Zeremonie. Tap-to-Complete für den Belohnungsmoment, Erstellung per FAB für die sekundenschnelle Erfassung, die die Interviews forderten. Aufgabenfelder umfassen Priorität, Erinnerung und Zuständige; Wiederholungen funktionieren wie ein vereinfachtes Kalender-Muster statt einer Regel-Engine.

The invisible constraint: authorization runs through two servers with different functions — an architectural reality the flows had to absorb without the user ever noticing.

Die unsichtbare Randbedingung: Die Autorisierung läuft über zwei Server mit unterschiedlichen Funktionen — eine architektonische Realität, die die Flows schlucken mussten, ohne dass Nutzer je etwas davon merken.

05Built on Material 3 — nativelyAuf Material 3 gebaut — nativ

The module wasn't skinned to look vaguely Android — it was built natively on Material 3 from day one. The team's Mobile Design System mirrors M3's own structure: every component is documented as Anatomy / States / Design tokens / Usage, the same four lenses Google uses. The UI kit covers 33 M3 components plus foundations, and the Tasks module contributed its own DS snippet — the Task Item, the row every list in the app is assembled from.

Das Modul wurde nicht auf „sieht irgendwie nach Android aus" geschminkt — es wurde von Tag eins nativ auf Material 3 gebaut. Das Mobile Design System des Teams spiegelt die Struktur von M3: Jede Komponente ist als Anatomy / States / Design tokens / Usage dokumentiert — dieselben vier Linsen, die Google nutzt. Das UI-Kit umfasst 33 M3-Komponenten plus Foundations, und das Aufgaben-Modul steuerte einen eigenen DS-Baustein bei — das Task Item, die Zeile, aus der jede Liste der App zusammengesetzt ist.

I proposed and documented 15 design-system components along the way and pushed the system towards design tokens, so a spec could reference a token instead of a hex value — and survive a theme change.

Unterwegs habe ich 15 Design-System-Komponenten vorgeschlagen und dokumentiert und das System Richtung Design Tokens bewegt — damit eine Spec ein Token referenziert statt eines Hex-Werts und einen Theme-Wechsel überlebt.

Artifact · Mobile Design System, component templatemirrors Material 3 documentation
LayerEbeneWhat it fixesWas sie festlegtExample — Task ItemBeispiel — Task Item
Anatomynamed parts and their layout slotsbenannte Teile und ihre Layout-Slotscheckbox · title · due date · priority marker · overflowCheckbox · Titel · Fälligkeit · Prioritätsmarker · Overflow
Statesevery interactive state, no "designer will decide later"jeder interaktive Zustand, kein „klärt die Designerin später"default · pressed · completed · overdue · disabledDefault · Pressed · Erledigt · Überfällig · Disabled
Design tokenscolors, type, spacing by reference, not by valueFarben, Typo, Abstände per Referenz statt Wertsurface, on-surface and error roles from the M3 paletteSurface-, On-Surface- und Error-Rollen aus der M3-Palette
Usagewhen to use it — and when not towann man sie nutzt — und wann nichtlists and search results; never as a standalone cardListen und Suchergebnisse; nie als freistehende Karte
Why native M3 matters in enterprise AndroidWarum natives M3 im Enterprise-Android zählt Enterprise users don't get onboarding time — the app has to behave like the Android they already know. Native M3 means platform-standard touch targets, dynamic color and accessibility for free, and engineers implementing against Material components instead of reinventing them, which is exactly what made a spec-first process enforceable. Enterprise-Nutzer bekommen keine Onboarding-Zeit — die App muss sich wie das Android verhalten, das sie schon kennen. Natives M3 heißt: plattformübliche Touch-Targets, Dynamic Color und Accessibility inklusive, und Engineers implementieren gegen Material-Komponenten statt sie neu zu erfinden — genau das machte einen Spec-first-Prozess durchsetzbar.

06The spec archiveDas Spec-Archiv

The module shipped on six [UX_UI] specification documents — about 140 pages including research — written so that engineering and QA never had to guess. The centerpiece: the View/Edit/Create Task spec, 31 pages covering every state and edge case — the single largest spec in the whole archive.

Das Modul lief auf sechs [UX_UI]-Spezifikationen — rund 140 Seiten inklusive Research — geschrieben, damit Engineering und QA nie raten mussten. Das Herzstück: die View/Edit/Create-Task-Spec, 31 Seiten mit jedem Zustand und Edge Case — die größte einzelne Spec im gesamten Archiv.

Artifact · [UX_UI] specification set6 documents · ~140 pages incl. research
SpecSpecPagesSeitenWhat it coversWas sie abdeckt
View / Edit / Create Task31All states and edge cases of the core object — the largest spec in the archiveAlle Zustände und Edge Cases des Kernobjekts — die größte Spec im Archiv
Task list19aggregating and user lists, sorting, badge navigationaggregierende und Nutzer-Listen, Sortierung, Badge-Navigation
Delete Task12deletion flows and their edge casesLösch-Flows und ihre Edge Cases
Complete Task in Task List7tap-to-complete — the reward moment, specifiedTap-to-Complete — der Belohnungsmoment, spezifiziert
Task navigation / Drawer7drawer structure and list-to-list movementDrawer-Struktur und Bewegung zwischen Listen
Task View (early)(früh)first-generation view spec, later superseded by the 31-page documentSpec der ersten Generation, später von den 31 Seiten abgelöst
Artifact · Pages from the real spec archiveArtefakt · Seiten aus dem echten Spec-Archiv
View/Edit/Create Task spec — task creation screens with annotations
View/Edit/Create Task spec (31 pp) — the creation flow, screen by screenView/Edit/Create-Task-Spec (31 S.) — der Erstellungs-Flow, Screen für Screen
View/Edit/Create Task spec — edge-case states with screen and state tables
Same spec — edge-case states, each screen paired with its state tableDieselbe Spec — Edge-Case-Zustände, jeder Screen mit seiner Zustandstabelle
Task spec page — error snackbars and leave-without-saving dialog with UI copy table
Unhappy path in the same document — error snackbars and the leave-without-saving dialog, copy includedUnhappy Path im selben Dokument — Fehler-Snackbars und der „Verlassen ohne Speichern"-Dialog, inklusive Texten
Task list spec — aggregating list screens with completed states
Task-list spec (19 pp) — aggregating lists with completion statesTask-List-Spec (19 S.) — aggregierende Listen mit Erledigt-Zuständen
Competitor study page — task list patterns of competitor apps side by side
Competitor study (task lists) — competitor screens dissected pattern by patternCompetitor-Studie (Aufgabenlisten) — Wettbewerber-Screens Pattern für Pattern seziert
Design system Task Item component — anatomy with annotations
DS · Task Item — the component's anatomy, annotated element by elementDS · Task Item — die Anatomie der Komponente, Element für Element annotiert

Documents are in their original working language — shown as authentic process artifacts.Die Dokumente sind in der Original-Arbeitssprache — gezeigt als authentische Prozess-Artefakte.

07Validation: letting data decideValidierung: die Daten entscheiden lassen

Concept split-test. Two UI concepts — badges/tabs vs accordions — tested with an external panel of 100 plus 134 internal users. Badges won on both measures: participants completed the task set faster (97s vs 125s total) and preferred them 62 of 133. Badges shipped.

Konzept-Split-Test. Zwei UI-Konzepte — Badges/Tabs vs. Akkordeons — getestet mit einem externen Panel von 100 plus 134 internen Nutzern. Badges gewannen auf beiden Achsen: Die Aufgaben wurden schneller abgeschlossen (insgesamt 97s vs. 125s) und 62 von 133 bevorzugten sie. Badges wurden ausgeliefert.

Evidence-based cuts. A 3-state task status looked popular — until the data showed the demand spike came almost entirely from Jira users (31 of 42). Cut. Overdue tasks were pinned to the top of Today, matching what users expected, and completed tasks moved to a separate section so done work stops cluttering the list.

Evidenzbasierte Streichungen. Ein Aufgabenstatus mit 3 Zuständen wirkte beliebt — bis die Daten zeigten, dass die Nachfrage fast ausschließlich von Jira-Nutzern kam (31 von 42). Gestrichen. Überfällige Aufgaben wurden oben in „Heute" angepinnt — genau wie Nutzer es erwarteten — und erledigte Aufgaben zogen in einen eigenen Bereich, damit Erledigtes die Liste nicht verstopft.

08OutcomesErgebnisse

First year after launchErstes Jahr nach dem Launch
600
downloads in the first year — goal metDownloads im ersten Jahr — Ziel erreicht
~40%
active users — goal of 40% metaktive Nutzer — Ziel von 40% erreicht
3
tasks completed per week per active user on averageerledigte Aufgaben pro Woche und aktivem Nutzer im Schnitt
~40%
retention vs the 60% goal — next step: analytics-driven iterationRetention vs. 60% Ziel — nächster Schritt: analytics-getriebene Iteration

The honest note: retention landed around 40% against a 60% goal. That gap is the agenda for the next cycle — closed with analytics-driven iteration, not with wishful thinking.

Der ehrliche Punkt: Die Retention lag bei rund 40% gegenüber einem Ziel von 60%. Diese Lücke ist die Agenda für den nächsten Zyklus — geschlossen mit analytics-getriebener Iteration, nicht mit Wunschdenken.

What I'd tell another designerWas ich anderen Designern mitgebe Kill features with data, not opinions. Cutting the 3-state status saved weeks of engineering — and nobody missed it. Features tötet man mit Daten, nicht mit Meinungen. Die Streichung des 3-Zustände-Status sparte Wochen an Entwicklungszeit — und niemand hat ihn vermisst.
Next case studyNächste Case Study

Enterprise Email Search · MyOfficeEnterprise E-Mail-Suche · MyOffice