Design process
This document serves as a guide for UX, UI and front-end development at NML.
Process flow and current tools
- Miro for product definition, research, analysis, information architecture and wire-framing
- Figma for UI design, prototyping and developer hand off
- Storybook for front-end components
UX Process - Miro
Product definition
- Define context and purpose
- Define business goals
- Define users
Research
- Compile qualitative data about the target audience, such as their needs, wants and behaviour.
- Understand competitors and industry standards
Analysis
- Create personas (if required)
- Create user stories
- Map user flows
Information architecture and wire-framing
- Organise and label the content of of the application
- Wireframe as a foundation for mockups and prototypes
- Collect real data from API if available
UI Process - Figma
- Create design specification and library - fonts, colours, all visual design assets
- Create design system - system of components, patterns, and styles
- Use real data from API
Front-end Process
Developer hand off
- Figma components and assets shared with developers
- Design system built in Storybook following atomic design principles
- Mock actual data from API in Storybook
Testing and validation
- Ongoing throughout the process
- User testing
- Surveys
- Analytics
Wasted UX work
Often UX work is wasted because it is demoed too early in the process. This is especially true of wireframes. Often we spend days (weeks) on wireframes that no-one needs.
Wireframes should never be shown to clients as that invites feedback way too early in the design phase and creates confusion. User flows are way more important than wireframes.
Personas often offer no real insight to users. Testing and validation is a far better tool.
Storybook
With Storybook, the entire team can simultaneously collaborate on the development of components in an application-like environment, minus all the business logic. All compnonents and states can be reviewed without having to trigger them in the application each time. It also greatly promotes one of the biggest selling points of components in the first place – code reusability
Storybook allows the entire team (design, front- and backend) to work together on components eliminating duplication of front-end code. This allows greater code reusability and cuts down on development time. Consistent UI design is easier to maintain across the entire application as any component can be reused by any developer on the project.
From a QA perspective all components in Storybook have states and can be tested in the design system before they make their way into an application, thus improving overall quality and cutting down on time in testing. The UI can also be shared with all stakeholders and built-in commenting makes it easy to collate all UI requirements and changes in the tool itself for story creation.
Overall Storybook offers a superior system in the long term as it serves as a living design system for re-usable UI components, speeds up development time, improves QA and allows for easy documentation.
White labelling
Applications can be designed to accommodate branding changes. However, due to the nature of the components, these are somewhat limited in scope in order to make maintenance of the project as a whole manageable.
To this end colour variables that do not involve custom changes to components can be done to the following:
- Text colour. This applies to headings, text blocks, form field labels, tabular data
- Button and link colours
- Logo
As soon as we attempt additional changes we will have to either:
- do css/class changes (very bad for maintenance), or
- incorporate a project specific css file. (less bad, but will break consistency)
This would then mean that we would have to go back and check for breaking changes on all different client instances if we do an update on the main project.
In addition, all requested colour changes need to pass accessibility tests.
White label process
We pass a custom brand class through a prop to the page component, which adds that class to a parent div. This allows us to have a partial css file per client that is bundled into the main stylesheet.
The advantage of this approach is that we change props in a place we already change it per client, ie where we change the name and logo for example.
A minor disadvantage is that custom classes are merged into the main codebase, so the css would be a few kb more than it technically needs to be. However, this minimises the risk of custom styles breaking overall styles.