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.

 Sketch snapshot of the wireframe system in the making.

Sketch snapshot of the wireframe system in the making.

 

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.

 
 Listing app UI elements and spotting inconsistencies. 

Listing app UI elements and spotting inconsistencies. 

 Inventorying gestures.

Inventorying gestures.

 Documenting the app patterns in use. 

Documenting the app patterns in use. 

 

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:

🤙 Affordance

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.)

✨ Simplicity

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…

🌈 Tolerance

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 😩

✂️ Consistency

Language use is clear, behaviors, interactions and UI elements are consistent. (Eg. Keep it clean, just one tab selector is fine!)

🤸 Structure

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.

 Team activity to establish what the design principles for our project are. 

Team activity to establish what the design principles for our project are. 

 Establishing when the user interaction biggest discomfort in usage happened.

Establishing when the user interaction biggest discomfort in usage happened.

 Team discussing what our product's experience should be like. 

Team discussing what our product's experience should be like. 

 

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.   

 
 Basic shared library. 

Basic shared library. 

 

 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

 Different shared libraries that help us build high-fidelity prototypes faster and with better accuracy. 

Different shared libraries that help us build high-fidelity prototypes faster and with better accuracy. 

 

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.

 
 Discussing processes with the core framework team.

Discussing processes with the core framework team.