Wireframe Design System
Project: Analytical reporting tool
Goal: Create a UI/UX system for a cloud reporting tool that was in the process of being build. The team recognized there were some inconsistencies in the team and we agreed the design process has to change and accommodate for the rapid agile developer sprints while keeping design thinking methodologies up and running.
My role: UX
Team: 1 UX designer
I managed the project for myself, applying design thinking methodologies within the team to find out how we can improve our processes. You can read my detailed post about this project that was published in UX Collective.
Step 1 - Measuring
I started this project with the goal of improving communication in my team and between my team and the UI framework team who were building the company's core design system.
The developers and designers were spending a lot of time discussing interaction patterns. The main issue was there was no source of truth. So that was what we all needed to sit down and agree on together.
But first we needed some structure. I started off by diligently making a list of all the UI elements in the app. I documented patterns and behaviors in a file called 'Inventory' and shared my findings with the team. The goal was to spot inconsistencies and pave the way for a consistent UI experience.
Step 2 - Team interviews
Next I met up with the extended team (PMs, devs, researchers, designers, QA) to find out what each of us thought the product we were building lacked and what we thought should be the focus for a better design process.
I organized an activity where we split into groups and so we could discuss the key elements we wanted our product to inspire. These are the principles that helped shape our process further on:
The controls should map to a logical, expected outcome. (Eg. If an arrow is pointing left then by pressing it it should move elements to the left of a page. 'Of course' you might say but oh how easy it is to reinvent the wheel. In fact it is MUCH easier.)
Each step in a flow feels trustworthy and easy. BI is essentially all your company’s intelligence in one place. In our case, the cloud. So a browser. Obviously we aim to not send our users to the ER with a heart attack because they pressed back right in the middle of refreshing a pivot…
Users must be able to recognize, diagnose and recover from errors. BI can also be heavy and tricky. We needed to come up with a pattern for helping users to easily recover from mistakes. Because they will press that back button 😩
Language use is clear, behaviors, interactions and UI elements are consistent. (Eg. Keep it clean, just one tab selector is fine!)
Information hierarchy and content structure are laid out clearly. (Eg. In a building flow users need to focus on different UI elements at different times. Make it clear what those are.
Step 3 - Establishing the success metrics
On a different meeting, we also discussed the success metrics of the wireframe system. In order for the system to prove its utility for the team it had to:
*be easy to use so that designers can focus on solving problems instead of reinventing the wheel
*use the same component taxonomy as the UI developers
*make the experience consistent for end-users
Discussing with the UI developers helped establish the information architecture of the system and the holistic component classification. I used the atomic design approach for building components in order to align with the core design system. We put together a better way to showcase the prototypes in InVision by creating an annotation library which includes cover images, sticky-notes for describing interaction and so on.
Step 4 - Testing
After a few iterations I asked for peer feedback form the designers in my team. Were they able to use the library and build prototypes to share their ideas? Was it faster? Were developers able to understand interactions easier without having to consult the core library? - these were some of the questions I had in mind and the result was positive.
Some of the improvements as mentioned by team members were
*easier to 'read' designs - mentioned by developers
*"I don't have to worry about how to start a new project." - mentioned by a new design hire.
*faster research prototyping
*consistent UI experience
*more time spent on how to improve the user experience
Step 5 - Improvements
The library is just a starting point. I used my analytical thinking and creativity to work through what was essentially a communication problem. Setting up some rules not only provides structure for new hires as well as team members who are not necessarily designers but also makes more space for creative problem solving.
Our next step is to come up with a better UX process between the core and app teams.