ORACLE COMMERCE CLOUD CONSULTING DESIGN SYSTEM
INTERNAL COMPANY PROJECT
Duration: 1 Year - 2022~2023
Team: 3 designers, 1 engineer
Role: Main UX designer
PROJECT OVERVIEW
Summary:
-
We revamped the Oracle Commerce Cloud Consulting Design System to improve clarity, reducing the need for frequent clarifications and edits during implementation for the engineers and QAs. A requirement for this design system would be to allow the design system to be a jumping off point for all projects.
Problem:​
-
How do we present the design system in a way to decrease the amount of times the engineers have to discuss with the designers for clarifications or having to go back to make additional changes so that we can free up the designers and engineers time to actually work on new projects?
-
How can we make sure that this design system is easily adaptable to quickly change and match the branding of different clients?
Users to consider:
-
UX Designers who need to create new wireframes using the design system
-
Engineers who are implementing the designs
-
QA who need to know what the design requirements are to test the live site
-
Customer Clients who would need to see the design system rebranded to fit their brand requirements
​
What we did:
-
Conducted competitive analysis and took a look at existing design systems (both internal and external) to understand best practices
-
Restructured our existing wireframes based on the competitive analysis and components to use as talking points with the engineers
-
Conducted user interviews with the internal engineering and QA team to get feedback
-
Restructured the files based on the new feedback
​
Project Contraints:
-
We had a limited timeframe to conduct interviews with our internal team so we had to turn to outside research to create our initial structure. Thus, we utilized lean UX methodology.
RESEARCH
Project Origins
The repetitive design/engineering team pain points prompted the design system reorganization:
.png)
Competitive Analysis
With limited resources for user interviews, we initially examined existing design systems to glean best practices. ​​​
status label indicating design status
status label indicating design status
annotations close to components
DESIGN
User Persona
Here are some personas we kept in mind as we restructured the design system:​
Design Ideation - Round 1 (Design)
Based on the insights from the competitive analysis and keeping the user persona in mind, we took an initial stab the restructuring. Some ideas we had implemented were:
Click to Zoom
status label indicating design status
Explicit screen flow
Annotations close to components
Design Ideation - Round 1 (Feedback)
After an initial assessment of the developers' and QAs' first design ideas, we identified a few issues:
Status pretty small
This frame 'Screen Flow - Mobile' itself was too large, difficult to navigate
Red arrows may not be suitable when multiple actions are possible on a single screen.
More functionality documentation for repeated components needed
Design Ideation - Round 2
In order to address these issues we did the following:​​
Wireframe - Static Annotation (Click to Zoom)
Each frame is smaller, only contains 1 state of the wireframe
Design State clear
Each frame has a number that can be referenced during a screen flow and just overall navigation
Wireframe - User Flow Annotation (Click to Zoom)
Screen change referred to by number rather than just red arrow
Functionality annotations of related components shown right below where it's being used in the wirefram
Building Blocks - Annotation (Click to Zoom)
Create a separate documentation file for repeated components, showcasing all states with detailed annotations.
User Research
We conducted user interviews with engineers and QAs using the Design Ideation - Round 2. Based on the interviews, these were the main takeaway points:
.png)
User Goals
Based on all the research and the user persona, these were the goals we had in mind as we started designing:​
Updated Design
Based on the feedback we got, these were updates that we made regarding the flow. Coincidentally, around the same time, the larger Oracle Design team had also revamped their own design system. We saw that our teams were facing similar issues, thus we based a lot of these new changes on the changes we saw on the revamped Oracle Design systems as well. Here were some changes:
-
File divided into 2 distinct sections
Comp Documentation (click to zoom)
Option to go to the 'Atoms Documentation' file with more detailed functionality documentation
More detailed status, broken down to design status and development status
Description section, where we can put down where the specific updates have been made on the wireframes and other notes.
User flow to give the engineers an overview of how the wireframes would relate to one another
Atoms Documentation (click to zoom)
Change log to highlight what and where the changes are
Usage and Anatomy section giving more detailed functional annotation
Variants section to show all the different states for the components
Design System in Use​​
NEXT STEPS
We are planning to take these files (Comps Documentation and Atoms Documentation) to our engineers and QAs and perform user testing to validate whether the implemented changes effectively addressed their concerns