Project duration: Varied timelines | 2019-20
System design, Component design, Pattern design.
Design principles of Delite Design System Foundations. Image credits: Delite Design system team.
The Problem
The product UI and interaction pattern inconsistencies are exponential across Software AG's product portfolio. Although Software AG is a 50-year-old enterprise software company with hundreds of products & solutions catering to multiple diverse customers, there is no dedicated Design Language System to address these issues. With the growth of the UX design team in the company, there's the emergence of the 'Delite Design System' with a dedicated set of UI/UX designers and engineers. But, Delite was at a nascent stage with only a few core components fully designed & developed for consumption. At the same time, not all of the product designers/product teams were ready to use these available components or build new components based on the Delite Design System foundations.
The growth of webMethods products in the cloud platform led to prioritizing unified experience by addressing product inconsistencies across all the cloud products.
My role
Designed five components and patterns altogether, by collaborating & co-creating with product designers, and product managers in gathering the requirements, and sharing the design foundation, and pattern design hand-off with Delite Design System designers & UI engineers.
Core team and stakeholders structure (varies from component to component)
Component/pattern designers - Team of 1/2(including myself) | DLS team of designers and UI engineers | Product management - Team of 5 | Development team and webMethods product team members.
Component/pattern designers - Team of 1/2(including myself) | DLS team of designers and UI engineers | Product management - Team of 5 | Development team and webMethods product team members.
Project Vision
Building Delite Design Language system components and patterns that address all the requirements of webMethods' products by collaborating and co-creating with Product Designers.
Design process
© Software AG. All rights reserved.
Project kick-off
Design system harmonization workshop
Workshop facilitator: A team member from the design system team
Participants: 20 participants comprising Product Designers (from both India and Germany teams), Design system designers & UI engineers, Sr Architects (from all the 3 webMethods.io products), and Product owners.
Participants: 20 participants comprising Product Designers (from both India and Germany teams), Design system designers & UI engineers, Sr Architects (from all the 3 webMethods.io products), and Product owners.
It was a 5-day intense workshop focused on creating a backlog of components/items for designers and developers, coming up with a collaboration model, and forming a team agreement.
The team behind the webMethods' product unification experience.
Day 1: Key objectives & understanding of the product eco-system
The participants have been given a walkthrough of the exercises planned for the workshop and the objective behind them. First of which is the session from the architects to understand the iPaaS(integration Platform-as-a-service) product ecosystem that comprises product portfolio strategy, capability overview & key challenges of the three products of webMethods. The first-day session ended with the walkthrough of the product UIs from the respective Product Designers from the Screen museum that has been set up.
Product eco-system sketch from the workshop.
Day 2: Identifying the components
We split into 5 groups to understand design decisions and identify the components to the atomic level in all of the products' UI. We agreed on the corresponding common terminologies of the components and categorized them to cast a vote to decide what should be part of the design backlog.
Workflow UI screen & component-related comments from participants.
Day 3: Process map
The team has been shown the process map - a collaboration model between product designers, developers, and the design system team. Post this, the prioritization of design backlog items has been done using the impact-effort scale method concerning designers.
Day 4: Risks and opportunities
Everything envisioned cannot always come to life as planned, so the exercise done here was to break/strip down the vision with all possible potential risks and define opportunities.
Day 5: Team alignment/agreement
The last day of the workshop ended with an agreement on team ground rules for the collaboration, and a team contract. The workshop came to an end with a fun exercise in naming the project!
Collaboration model between design leads and product owner, the decision-makers.
Design backlog
Design system components
In toto, there are 21 new components and 8 new patterns resulting as part of the design backlog exercise. The backlogs are then prioritized based on the designer's impact/effort scale.
Backlogs are classified into 4 categories; Yellow - New component, Blue - WIP component, Purple - New Pattern, and Green - Existing component in Design System. The votes on each component shown below are derived after a heat-map of the votes by designers.
Sneak peek into the Impact Effort matrix for a few of the design backlogs.
Components & Pattern design
Components
Cards, Modal, and Date range picker
I designed the above-mentioned components and documented the process in three major stages.
• Stage 1: Define the component and consolidate various design systems' approaches toward the same component and collate the findings.
• Stage 2: Understanding the requirements of the component from product designers, addressing if there are any issues, edge cases/special cases, and resolving the same.
• Stage 3: Laying design foundations by breaking the component requirements into atomic levels under headers like interactions, types, grid, edge cases, responsiveness, etc., and anatomy. These details would vary from component to component. Post the break-down, I create Low-fid digital sketches to help the design system team understand the ideas. The same space is used for addressing any concerns/ queries between both teams.
Template used to record the component design process and communicate between cross-functional teams by commenting & tagging in the Mural tool workspace.
Cards
Design team size: 1, myself | Oct-Nov 2019
Cards display a snapshot of information intended to encourage users to interact with or click to view more details or actions. Below are the key properties of cards:
• Cards are used for grouping information and content.
• Cards present a summary and link to additional details.
• Cards allow for a flexible layout.
• Cards are used for grouping information and content.
• Cards present a summary and link to additional details.
• Cards allow for a flexible layout.
Types of cards and the requirements for webMethods Integration product.
Anatomy of the card shared with Delite.
Modal
Design team size: 1, myself | Jan 2020
A modal window is an element that sits on top of an application’s main window. It creates a mode that disables the main window but keeps it visible with the modal window as a child window in front of it. Users must interact with the modal window before they can return to the parent application.
Basic wireframes of all the modal requirements.
Modal Anatomy.
Updated margin specifications - shared with Delite.
Date range picker
Design team size: 2 (including myself) | Apr 2020
A date picker allows users to select a date or range of dates and in some use cases, it is combined with a time picker.
Date & time range picker requirements
Proposed ideas for the Date range picker, Date & time range picker
Patterns
Start page
Design team size: 2 (including myself) | May 2020
The start page or opening page of a product is intended chiefly to greet visitors and provide information about the product as well as help the user onboard the product. I have done the Visual Design for the Start page of all three webMethods products. As part of the requirements, I also did illustrations for the card components wherever it was required.
User management
Design team size: 2 (including myself) | Aug 2020 - Oct 2020
• User management is a complex and comprehensive pattern design. Each one of the webMethods products has different definitions & terminologies for user management, the only common element being the admin persona's use case of managing user access.
• The major chunk of work happened at stage 2 of the process. I broke down the pattern to the details of Trigger, Personas, and Persona-based flows and information architecture, and detailed user journeys. I interviewed all the three product managers to dig deeper into understanding the pattern, existing issues, and future expectations with the new design.
• We had to scope down the requirements as it was affecting the core information architecture of the products, which cannot be resolved with this pattern design in a short time frame.
• Considering the upcoming product release cycle, the scope is to have a common terminology, Navigation/Trigger point in place for all the three webMethods products.
• We conducted usability testing with 5 Sr. Architects (who also play admin roles in respective products) with the purpose of how they navigate to find the user management section and what is the terminology they use/know for user management.
(L-R) 1. We defined the Purpose of the UT and possible scenarios with follow-up questions to the users for the UT session. 2. Seen here is how we captured the highlights from one of the individual UT sessions. Segregated the findings based on Positive/negative/neutral highlights and any ideas, or quotes from the user.
• Post the UT, we analyzed the findings by clustering & prioritization and came up with 3 proposals for the trigger/navigation. We then presented those proposed solutions to the same 5 users by conducting a short survey, intending to find a suitable solution from the three proposed solutions to trigger user management.
The results had a tie between options 2 & 3. We further got into the details of why the users have chosen the respective options.
We created quick iterations based on the findings derived from the UT sessions. Did a short survey to gather another round of feedback based on the proposed ideas.
Survey results show a tie between options 2&3.
• Later, we conducted another set of short surveys for icon choice and menu naming using the iterations we created to the same users for the final vote. Option 3 was the chosen proposal for further detailing. With this, we concluded on trigger and terminology and I created high-fid UIs and shared them with the development team for final implementation.
Iterations for 'Icon' from where user management is accessible.
Settings - The gear icon is chosen as the final design sign-off. Also, categorized and grouped various settings under one menu.
The final design for accessing User management under Administrative settings via the overall settings icon on the top right.
Impact
The goal of this project has been achieved to a great extent by bringing consistency across all the three products of webMethods using Delite.
• Design evangelism: The unified experience project for webMethods products helped us promote the design system usage within Software AG and evangelize more product teams to adopt 'Delite' with usable, accessible, and visible components.
• Bridging the gap between cross-functional teams: Product designers played a key role in creating design foundations by gathering all possible use cases from the product perspective. This laid a rock-solid foundation for the design system designers to come up with high-fid components in a much more efficient way. Also, this collaboration opened doors for more product teams to reach out to the design system team for easier adoption and to communicate additional requirements.
• Ease of use: Leveraging the design system into products not only addresses consistency issues, but the overall user experience is far easier to use.
Challenges & Key takeaways
• The process of designing a component that will be used in multiple products makes you get into the atomic details of the design. It is also challenging when you need to provide a better and more cohesive solution of the same component which is already being used, represented in different ways across various products.
• Adopting this new change and implementing it in the products is not an easy job considering design and development efforts. Though there was a dedicated dev team supporting the pattern and component implementation into products, the collaboration model did not last forever due to the resource crunch.
