Design
System 

Pictogram explaining the Design System

Main illustration of Appway's Design System

Problem

New client project UIs were built from scratch or copied from another project, even when the requirements were different. Overall, there was no shared way to build projects, and upgrades were expensive because every part was custom-made.

A person wearing glasses
				Description automatically generated with medium confidence

‘Let's focus on integrating the backend first and see what we do in the frontend afterwards... we could use an old project’

Application Developer

Needs to create the UI of projects from scratch or hack his way through existing projects

A person with a beard
				Description automatically generated with medium confidence

‘Every change/upgrade in the front-end of my solution is very expensive’

Client Project Manager

Had a tailor-made application made for her organization

Pictogram for Patterns Pictogram for Screen components Pictogram for Screen Templates Pictogram for Solution Components Pictogram for Theming

The 5 pieces of Appway's Design System: Patterns, Screen Templates, Solution Components, Screen Components and Theming

Proposal & Process

The proposal was to create a Design System that let developers recreate designs more easily by using premade UI components and modules, and by following a shared set of patterns.

Over 6+ months, we worked through hundreds of activities. Research stayed in the loop throughout: user interviews, focus groups, surveys and questionnaires, usability testing, and eye tracking on critical flows. The key activities I took part in were:

  1. Identify patterns used in previous projects: find tendencies and best practices together with developers
  2. Create high-level customer journeys of existing applications: identify user activities
  3. Group existing patterns and match them with user activities
  4. Define what each area needs when creating applications
  5. Define the initial stages and templates of applications
  6. Draft first designs based on template and component requirements
  7. Create initial prototypes of templates and components
  8. Define configurations and document them
  9. Create a development package based on components
  10. Keep evolving the development package and fix bugs based on ongoing research (user interviews, focus groups, usability testing, eye tracking, and surveys and questionnaires)
  11. Keep documentation, development packages, and E-Learning up to date

All of these activities were part of an iterative process. Many of them happened more than once across numerous Sprints.

Result

This project had 3 main deliverables: a development package with all of the UI code for the frontend, a website that documented the principles, patterns, and components, and an E-Learning course that explained in detail how to use the Design System.

Those 3 deliverables led to these results:

  1. Continuous improvement

    Clients can now get UI updates for their projects with the click of a button, because the Design System’s self-contained architecture makes rollouts much smoother.
  2. Scalable design and development

    Developers can reuse prebuilt modules, which speeds up development and guides them toward a stronger user experience.
  3. Efficient team collaboration

    We created a shared language for talking about solution ideas, with patterns and modules as the vocabulary.
  4. Cohesive experience across applications

    Customers got a more consistent experience because modules looked and behaved the same, and because the client’s brand theme could be applied across their ecosystem of applications.

How to work with the Design System sales Demo.

Impact

The success of the Design System helped drive a change in the company's way of working and business model.

The company started as a service business that supplied developers to work on top of an in-house platform. It moved toward a product company that offered a set of ever-evolving functional application packages that clients could mix and match in their ecosystem.

For the business model, that meant clients would no longer pay one time for project development and maintenance. Instead, they would subscribe to the application packages they acquire. That subscription included upcoming updates, documentation, and E-Learning.

This also opened the door to a business-logic approach where business stakeholders can configure applications and the UI is configuration-driven, without extra coding. That same foundation also prepared the ground for AI-driven UI generation.

 Documentation of Templates

Documentation of 3 Screen Templates: Space, Activity and End Screens.

Challenges

This initiative faced many difficulties, including:

  • Fear of change among many colleagues in the Customer Success (CS) team meant I had to convince people to start adopting the Design System. Meetings, workshops, demos, and hackathons helped bring CS colleagues into the journey.
  • A lot of learning by doing: we started from scratch, so almost everything was new for me and the team. That meant plenty of trial and error in the early designs and code.
  • There were many layers of coordination across multidisciplinary teams: backend platform developers, frontend, design, package development, E-Learning, Customer Success, and finally sales.
  • Documentation had to stay clear and current. It started as a PDF and grew into a website with 100+ pages that we updated every week.
Ricardo Gerstl presenting

Ricardo Gerstl (with very short hair) presenting Appway's Design System in a conference

Role

This initiative asked me to wear one big hat:

User Experience Engineer (Lead)

  • Research: investigate users’ goals and the problems we are trying to solve with the product through user interviews, focus groups, surveys and questionnaires, usability testing, and eye tracking
  • Evolution: own the transition from legacy elements into the new Design System
  • Design: create solutions for those problems with thorough concept prototypes and facilitate user testing
  • Engineering: build the product’s UI with technical feasibility, accessibility (a11y), and usability in mind; ran accessibility reviews on components (keyboard, focus, contrast, and ARIA) before each development-package release
  • Management: lead a team through new releases, bug fixing, quality assurance, documentation, and product evolution
  • Communication: develop and share the design principles with stakeholders, colleagues, and clients
Design System Patterns

The 3 patterns form the cornerstone of Appway's Design System.

Learnings

From this project I took away four main lessons:

  1. Bring people into the journey: that means a lot of talking. I prepared a generic slide deck and demos that I presented regularly to stakeholders.
  2. Make allies across teams: I had one or two ambassadors across teams who gave regular feedback and supported Design System adoption.
  3. This project was always evolving, so its success or failure could not be judged against one end date. That is why we split it into smaller projects to better track progress.
  4. People don't read: documentation needs visual material and an interactive part to support it. When possible, create videos to get the message across.
Ricardo Gerstl presenting

Appway's Design System mission and call for feedback.

Browse the documentation, rebuilt as a static archive: The Appway Design System
The original, still running on the Appway platform: design.appway.com
Next Case Study: interactive Elements