Table Of Contents
Tink — Design System for the City of Antwerp
Tink is an in-house design system built at Digipolis, the IT provider for the City of Antwerp. It was created to unify UI across a growing ecosystem of digital products—internal dashboards, public-facing websites, and citizen forms—while improving accessibility, consistency, and development speed.
Role: Frontend designer & engineer
Timeframe: September 2014 – July 2015
Focus: Design systems, frontend architecture, accessibility
Context
Digipolis supports a wide range of digital products for the City of Antwerp. These include tools for city personnel as well as public services used daily by citizens.
At the time, teams operated largely independently. Applications differed in look, behavior, accessibility quality, and technical approach. As the number of products grew, this fragmentation increased development cost, slowed teams down, and resulted in inconsistent user experiences—especially problematic in a government context.
A shared design system was needed to bring coherence to this ecosystem.
The Problem
The challenges were both practical and structural:
- Inconsistent UI patterns across departments
- Accessibility issues in many existing applications
- Repeated reinvention of common components
- Increasing maintenance overhead as products scaled
The goal was not just visual consistency, but a system that teams would realistically adopt and use in production.
Approach
Tink was built as a greenfield design system, loosely based on Bootstrap’s naming conventions. This was a deliberate choice to reduce friction for developers already familiar with Bootstrap, allowing teams to become productive quickly without steep learning curves.
The guiding principles were:
- Solve the most common UI problems first
- Optimize for adoption over theoretical completeness
- Bake accessibility into components by default
- Ship early, validate in real products, and grow organically
My prior experience working on a global design system at Sony—covering e-commerce flows and marketing pages—strongly influenced this pragmatic, adoption-first approach.
Design System Foundations
Tink followed an atomic design methodology, building from small, reusable building blocks toward complete interfaces.
Core deliverables included:
- A frontend component library
- Design tokens for color, typography, spacing, and layout
- A layout grid system
- Usage guidelines and standards
- An internal documentation website
- Public-facing documentation
- Distribution via NPM and integrations with design tools
Rather than attempting to cover every possible use case upfront, the system focused on the components teams needed most.
Anchor components included:
- Forms and form fields
- Tables
- Alerts and feedback components
- Layout grid
- Dashboard UI patterns
These formed the backbone of most city applications.
Accessibility & Audits
Accessibility was a hard requirement. As a government client, compliance and usability were non-negotiable.
Tink targeted WCAG 2.1 / AA, with emphasis on:
- Readability and typography
- Color contrast
- Keyboard navigation
- Clear focus states and affordances
UX interviews and audits of existing screens revealed recurring accessibility failures and inconsistent patterns. Instead of retrofitting legacy applications, teams were given Tink as a foundation to overhaul their products using accessible components by default.
Accessibility became an outcome of using the system, not an extra step at the end.
Templates & Real-World Usage
To ensure Tink worked beyond isolated components, it included concrete, production-oriented examples:
- Dashboard templates for city personnel
- Page layouts for common application types
- Form-heavy citizen-facing flows
These templates served as reference implementations, onboarding tools for teams, and proof that the system scaled to real use cases.
Adoption & Rollout
Tink was adopted across multiple city departments and became a required dependency for new digital projects.
While governance itself was outside my role, adoption was actively supported through:
- Familiar naming conventions
- Clear, practical documentation
- Real examples instead of abstract rules
The system prioritized usefulness over theoretical purity, which proved critical for uptake.
Tink continued to exist after my involvement and later evolved under a different name.
Outcomes & Impact
Although no formal metrics are available to me, the impact was tangible:
- Faster development through component reuse
- Fewer inconsistencies across applications
- Improved accessibility in newly built products
- Reduced cognitive load for designers and developers
- Higher overall UX quality for citizens and city staff
Teams spent less time reinventing solutions and more time focusing on product-specific problems.
Learnings & Reflection
Building Tink reinforced several key lessons about design systems:
- Start small and grow organically. Systems built fully upfront often overwhelm teams and go unused.
- Adoption is harder than creation. Code is the easy part; documentation, advocacy, and trust drive real usage.
- Governance matters early. Without clear decision-making processes, systems either stagnate or fragment.
- Measure impact, not output. Reuse, reduced friction, and consistency matter more than component count.
- Technical debt is inevitable. Design systems must be built for change, not perfection.
- The hardest problems aren’t the UI. Motion, tone, edge cases, and cross-product consistency are often more complex than components themselves.
