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.
‘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
‘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
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:
- Identify patterns used in previous projects: find tendencies and best practices together with developers
- Create high-level customer journeys of existing applications: identify user activities
- Group existing patterns and match them with user activities
- Define what each area needs when creating applications
- Define the initial stages and templates of applications
- Draft first designs based on template and component requirements
- Create initial prototypes of templates and components
- Define configurations and document them
- Create a development package based on components
- Keep evolving the development package and fix bugs based on ongoing research (user interviews, focus groups, usability testing, eye tracking, and surveys and questionnaires)
- 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:
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.Scalable design and development
Developers can reuse prebuilt modules, which speeds up development and guides them toward a stronger user experience.Efficient team collaboration
We created a shared language for talking about solution ideas, with patterns and modules as the vocabulary.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 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 (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
The 3 patterns form the cornerstone of Appway's Design System.
Learnings
From this project I took away four main lessons:
- 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.
- Make allies across teams: I had one or two ambassadors across teams who gave regular feedback and supported Design System adoption.
- 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.
- People don't read: documentation needs visual material and an interactive part to support it. When possible, create videos to get the message across.
Appway's Design System mission and call for feedback.
