Schlumberger sells complex multi-million dollar industrial equipment. It was typically engineered-to-order (i.e. custom engineered), a costly and time consuming approach. The industry was shifting towards configure-to-order equipment instead, and Schlumberger wanted to do the same to increase margins in a competitive market. They wanted to develop an in-house product configurator as the part of the new process for designing equipment.
We were tasked to develop a configurator design concept that got leadership buy-in and funding for development. Previous attempts at developing configurators had failed. Users refused to use them, partly due to a poor UX. To complicate things, the configurator UX was to be driven by a complex configuration engine, which was already designed by a consulting firm. Furthermore, the engine was implemented using an out of the box SAP configurator solution. Both needed to be understood and factored in when developing the concept to ensure they integrated without impacting the design.
The product configurator design concept did get executive leadership buy-in and funding, however, the COVID pandemic's effects on the industry reduced funding significantly, preventing it from being developed. Nonetheless, all the end-users and various stakeholders, agreed the design concept provided the type of UX they were hoping for, one that would get adopted. Furthermore, the industry expert consulting firm, that designed the configurator engine, had never seen such a modern configurator UX in this market and delivered in such short time.
Conducted a kickoff meeting to layout the approach, timeline, objectives and set expectations.
Employed an Objective-Based UX Research Plan for Flexibility
The UX research plan was focused initially on the objectives of the research, since I wanted the flexibility to choose the research methods based on what I was learning along the way. It was too complex of a domain to grasp quickly, hence I needed the time to acquire a certain level of understanding in order to choose the most appropriate methods.
Chose a Co-creation UX Strategy for a Complex Domain
The research and design phases originally didn't have much overlap, however, as the project progressed we encountered several challenges that lengthened the actual timeline. Having conversations without visual aids become quite challenging, since the domain was complex and we were discussing a new process & new ways of working with stakeholders representing 6 different job profiles.
I adjust the approach to make it more co-creative, with really tight feedback loops & crude preliminary designs that we iterated on frequently as way to clarifying and extract user needs.
A series of stakeholder interviews with the main stakeholder at the beginning gave me a crash course in a number of relevant areas.
Understanding the Equipment Lifecyle & As-Is Tendering Process
This is essentially how equipment is designed, engineered & sold. The configurator would need to support aspects of the tendering process, however, it would change it in some foundational ways. The process is complex & can take months to a year to complete, with many people involved. An understanding of the as-is process, would help me identify where the configurator would be involved, and give me the necessary context needed to envision the new process.
Clarifying Terminology & Concepts
With so many new terms, I took the time to understand and clarify concepts related to Manufacturing, the pilot Product Line and tenders, including the relationships between these. This would significantly aid conversations with stakeholders & users. Some of the terms that were crucial to understand were: Tenders, Products, Configurations, Revisions, Parts, Modules, Assemblies, Components, Attributes, Values.
Pilot Product Line & Product
I needed to understand what type of product it was, what it did, what it consisted of, how it was designed, engineered & manufactured, how it looked and much more. This background context really helped understand the CTO model, engine and implementation and thus the constraints on the UX.
Identifying the Job Profiles Involved
There were many job profiles involved in the tendering process, with several being the key profiles using the configurator: Tendering, Engineering, Costing & Estimation and Supply Chain & Manufacturing. I learned that the Engineering profile would be the primary users, spending the most time with the configurator. This gave me a starting point to study the needs of the different roles.
There were alot of complex topics that I needed to sit with and understand, since I didn't have access to the consultants who fully understood them. Additionally, I needed to acquire them quickly if I was to make best use of my research activities. These learnings would serve as the foundation for the rest of the activities.
Understanding the Configurator Engine: CTO Model & Engine
The model laid out how the configurator should function in a very detailed way. It was complex with many rules, parts, attributes, etc. Over hours and days of sifting through, reading and rereading the documentation & diagrams, I got a sense of how it functioned conceptually.
Discovered Pre-existing UI Requirements
The consulting firm had already identified a bunch of requirements for the UI through a workshop. We needed to ensure our design addressed those where appropriate. Understanding how the consultants arrived at them would be helpful in determining importance and how genuine the need was.
Explored a Referenced Configurator to Clarify Requirements
During the UI workshop conducted by the consultants, the client referenced a Bicycle Product Configurator many times as a means to communicate their requirements. So, I reviewed this tool in-context to the requirements and experimented with it to clarify requirements.
%20Module%20UI.png)
Dependencies on the SAP Variant Configurator (VC) Module
The configurator engine would ultimately be implemented using the SAP Variant Configurator module, so any constraints or limitations that this module introduced would be helpful to understand. Furthermore, I'd get a tangible sense of how previous product configurator initiatives had failed, since they too leveraged the SAP Variant Configurator. Given SAP's really unfriendly UI, we would easily be able to develop a more user-friendly UI compared to that.
Leveraging Product Configurator Design Best Practices
Product configurators are found everywhere, with alot of free advice on designing & developing these. I took a careful look at industrial product configurators, which are much more complex, compared to simple ones, such as those that are used to design a pair of shoes or t-shirt. I took note of typical challenges when designing them, best practices, how they function, useful design patterns to apply. No sense in reinventing the wheel!
Experiment with Specific Product Configurators from Dell & BMW
The client had specifically mentioned configurators from Dell and BMW as being good examples of what they were envisioning, citing specific aspects of the configurators that would be valuable to replicate in the configurator. I spent time reading articles about both, experimenting with them and relating it back to the structure of the configurator we were designing.
Getting the Perspective of Different Job Roles
I attended weekly focus groups with the core team, a set of the key stakeholders representing the different departments (i.e. job profiles) and also future users of the system. While focus groups aren't ideal way to get unbiased input, this was the only way we could get regular input from all the key stakeholders on a regular basis, given their busy schedules. The core team helped me recruit participants for user interviews I'd conduct for the primary job roles that would interact with the configurator. I spent alot of time understanding how the current process worked from each Job Profile's perspective, what they were trying to accomplish, what they were concerned about.
Configurator Only Supports Part of the Process
A tender can have a long list of products & services provided as part of it. The configurator pilot was targeted to only support the configuring of a single product model within a specific product line. Typically, this particular product model is just a small part of a tender’s Scope of Work (SOW). All of the other equipment in SOW will still be configured the as-is way it is done, outside of the configurator. Hence, using a Configurator to only configure this product, would result in some additional work for users in the near term, since it’ll have to plug into existing processes that are used for all the other products. So, during the tendering process, there will be touchpoints with the configurator where users will need conduct tasks.
Uncovered Points of Friction Relating to Touchpoints w/ Business Systems
There are a variety of systems utilized by various teams as part of the tendering process, a few of the ones that are relevant to the Configurator: (SOW Builder, Tender Database, SAP, Lots of Excel Spreadsheets). These systems have taken years to build due to the technical nature of the work and the deep subject matter expertise that it requires to correctly develop. The configurator must integrate into the existing tendering process and potentially with these other systems either through manual user interactions or system integrations (in the future). The handoffs between these systems that the user will have to do, will be a definite source of friction that should be lessened as much as possible.
I built this Service BluePrint to integrate some my initial findings and to provide a means to facilitate conversations around user needs. I reviewed it with the core team to validate it and make adjustments as appropriate. Particularly, I used it to validate potential high-level touchpoints with the Configurator during the “tendering” process, as well as key workflows and anything that was missing.
Creating it live on a conf call would not have been an effective use of time, given how past meetings went and might have been hard for users to envision a future process from the future configurators perspective. I needed to deduce this from understanding their perspectives.
These key workflows were assembled to capture how the configurator would work at a high-level given the CTO model functionality. Each workflow consisted of a series of tasks that the user would execute within the configurator to achieve a particular goal. It also highlighted the tasks that occur most frequently, are the most crucial and the ones that'll be executed within the configurator.
Create Quote
This focused on the initial creation of a quotation from scratch. Users would typically start the configuration at the beginning and go through the entire configuration process step-by-step, as opposed to jumping around.
Update Quote
During most of the tendering process after the initial configuration is created, there will be many updates to the quote. And even in cases where a new quote is created, they'll base it on a previous configuration, hence there will be this type of behavior where users will want to jump to particular place in the configuration to make adjustments.
Answer Queries/Add Notes to Quote
Updates to a quotation are in response to comments about the configuration by the client or internal team members and are typically in context to a particular aspect of the configuration. User will be responding to these quite frequently. Additionally, noteworthy comments about aspects of the configuration will be important to capture based on conversations. These too, will be contextual and important to capture.
There was not enough behavioral information to generate personas, we were stuck with Job Profiles. We got a sense of what the needs would be for a particular Job Profile, but nothing more specific beyond that. From the research we did, we identified numerous job profiles that would interact with the tool from the different departments:
Derived 65 Requirements from the Research Findings
Each of the requirements was structured to include information that would facilitate product strategy & planning, enable traceability of design decisions and inform future requirements as needed. A different team would be developing the product, so I wanted to ensure they had everything they needed.
Ensuring the UI Requirements are Addressed
The UI requirements given to us from the consultants, was further validated with users before being mapped into the UX requirements I derived. This way we could ensure they were addressed within the design and had evidence-based rationale.
Several user needs were uncovered solely through user research and were not addressed by the SAP VC implementation. If the solution was to get adopted, then it needed to address these needs. A few examples included...
User Need: Support for Product Configuration Revisions within a Quote
You can only create a single revision for a product configuration as part of a Quote. However, most of the time customers request changes to the configuration as a way to find cheaper cost, shorter lead time, etc. configurations, so making revisions that can be traced and easily compared is essential to the tendering process and frequently occurs.
Customers like to explore configuration options and one of the main advantages of products configurators is that they support this need in a flexible and forgiving way.
User Need: Support for generating Multiple Quote Types for each Product Configuration
You can only generate a quote of a single type for a product configuration. However, when generating a product configuration, tendering folks would like to generate alternative quotes for certain configurations, which allows them to easily compare different quote types for a given configuration.
Once again, this is a common advantage of product configurators that users find tremendously valueable.
A number of key principles were derived from the research that shaped & guided the design, a few examples included ...
Catch & Prevent Accidental Configuration Changes
Catch accidental changes, make users aware of them, make it hard to make them and easy to recover from them. This principle piggybacks off of a standard usability heuristic around "error prevention & recovery", but needed to be called out due to its importance for this type of application. The particular product being configured is quite expensive, with many parts and a lengthy configuration process, so accidental changes can negatively impact one of the key goals of the tool (reducing product cost). The playful quality that the configurator enables, combined with a long configuration process might cause users to not be as careful during the process. Secondly, the CTO engine is quite interconnected, so a change in one area can trickle automatically into several other areas quite quickly & unknowingly to the user, so the impact of an incorrect change can be significant.
Flexibility During Configuration Process
The design needs to be flexible to support exploring different configurations, attribute selections, part selections, etc. without the worry of losing previous work or an inability to go back to a previous version. Secondly, upon making certain selections, users may want to quickly see impacts on Cost and Lead Time and use those impacts as input into decisions on whether to explore other changes or revert back to previous selections.
Leverage Visual Methods to Communicate Data Meaningfully
Many of the key screens need to communicate lots of data, so leveraging visual methods to do so meaningfully while ensuring easy readability and scan ability, would have tremendous value in this process.
With such a complex project, so many people involved, dependencies on complex business systems, integrations and a short time to conduct such work. Its important to note areas of concern that could impact the implementation of the design.
Design based partly on a theoretical model, not on actual implementation
The SAP VC was being implemented in parallel to this UX work, hence we relied on the CTO engine documentation to understand how the CTO model was designed to work, instead of the implementation. Additionally, during this time, there were clarifications & changes the consultants made in conjunction with the SAP team that were not accounted for in the UI design.
Hard to discover authentic user needs when the product configuration process will be different using the CTO model.
Understanding and studying the current process, isn’t completely applicable since the process will be changing. Hence, the discovered user needs might be built on assumptions or hypotheticals and probably need to be validated further. Taking an approach to build a basic version of the configurator and then have feedback from usage inform priorities for future functionality is a safer (i.e. less risky) way to build the configurator.
Configurator must integrate smoothly with a complex & existing tendering process that touches multiple systems and multiple user roles
Given the complex process, some requirements were probably missed and potentially unclear. Furthermore, certain systems have been developed over a long period of time and can’t be adjusted in short timeframes. Hence providing options for the configurator to export data (to Excel) enabling it to better integrate with the current processes that touch these systems, should enable greater adoption and should elucidate user needs to drive future functionality.
There were countless iterations of the design, however I'll focus on how the design generally evolved over time for one particular area of the app.
Round 1 - Flat Hierarchy
A simple 2 level hierarchy without breadcrumbs was initially used. Breadcrumbs didn't seem necessary at that point in the project, since our understanding of quotes was simple (and incomplete, as we later found out later).
Certain screens would have lots of vertical scrolling due to the functional & data elements needed on those screens, so primary navigation was placed in a column on the left side. This traded off less horizontal screen real estate for more vertical real estate above the fold.
The concept of a quote had several different aspects, each with a sizable amount of data and different roles focused on each aspect in isolation. Tabs were used to represent the different aspects of a quote, isolating the data and functionality mirroring the way users worked.
Round 2 - Simplify
As we learned more about the project, we realized there could be multiple quotes for a given tender. There were higher levels of organization that were missing from the design. Instead, we a flat list of quotes across tenders, which would make it hard to compare quotes for a given tender. We adjusted the design to support the concept of tenders and adding breadcrumbs to support navigation across the new structure.
The data from certain main tabs was integrated into others tabs (e.g. Resolved BOM), while certain sections (e.g. Changes & Comments) were moved into the side Steps panel, simplifying the secondary navigation and making better use of the space.
Lastly, Cost & Lead time roll-up could be up top to guide the user display only the information that would support the configuration process.
Round 3 - Deeper hierarchy
After getting a more realistic sense of the controls and interactions needed during the configuration process, we decided to move the primary navigation to the top to free up horizontal space. A complete concept of Tenders, Products and Configurations was introduced, better supporting the business process. We removed irrelevant project information from the screen, since we could include that on new screens that were higher up in the new & deeper hierarchy.
Round 4 - Final
Since the primary navigation didn't have many sections, we replaced it with the breadcrumbs, as a way to repurpose that real estate for something more useful. This offered a standard way to give the user quick context of where they were in the Product Hierarchy, while being able to navigate to those areas all within a small piece of screen real estate.
Added the ability to see visualization of the final configuration, when a small visual thumbnail was tapped. A search was added to side panel, since this would be crucial to the iterative nature of building a product configuration.
A dedicated overview screen was created to show all sorts of visualizations & analytics about the configuration, helping the user make better decisions about the configuration. This makes it easy to analyze the configuration during the configuration process, without losing your place in the process.
The organization & structure of the application, navigation, search & labels evolved alot during the design phase. The final version is depicted below:
Deep Organization Scheme & Structure, Not Flat.
Divided up the information and functionality into different levels, as opposed to a flat hierarchy. Multiple levels capture the structure and relationships between Tenders, Products and Configurations and other data elements matching the users mental model and reflecting the business process. More specifically, it supports the user need for multiple configurations, which is essential to the way tenders are developed. Another level of hierarchy for “configurations” gives the user the ability to see multiple configurations on the screen in detail, to understand its evolution.
Scalable to Accommodate Future Scope
There were plans to expand this concept to numerous other product lines, so the configurator is structured to support these new products courtesy of the deep hierarchy that was used. The concept of Tenders, Quotes, Configurations is common across the product lines, but the contents of the Configurations will vary, so functionality & data that is common is abstracted out, while product line specific functionality & data is accessed at the deepest levels of the hiearchy.
Factored in a Transient Product Posture
Configuring a product was a small part of an engineer's job. The process had lots of tasks that weren't conducted within the configurator, so they'll be coming to the configurator to execute a task or series of tasks, then leave sometimes for extended periods of time and then comeback. They needed to jump right into the main areas and easily jump out.
Maximized Screen Real Estate to Optimize Configuration Screen
Users will spend the bulk of time within the configure screen, which is deep within the hierarchy, hence by creating the levels, it allows the user to get the most of the screen real estate for their main activity.
Limits Exposure to Irrelevant Data
Structured in a way to isolate the configuration & costing of different products (i.e. work packages), since they are conducted by different teams and to prevent the team from being distracted by other aspects of the tender that are not of their concern.
Labeling Built on Existing Business Processes & User Terminology
Utilized the labels and terms the users were commonly using and validated it with them. Since we were introducing new concepts as part of the configurator, we needed to add new terminology that wasn't used before. Examples, include: Tenders, Product X, Configurations, Specifications, Attributes, Values, etc. Parts, Modules, etc. Quotes
Search Provided Locally, not Globally.
Local searches were provided for the data objects that would be large in volume, such as Tenders, Configurations, Steps, Notes, Change. Particularly, during "update configuration" types of tasks, the search functionality would be essential to increase efficiency.
To showcase our thinking when it came to Interaction Design, I'll focus in on the Configure screen to show deeper levels of navigation and the screen which users will use the most. Furthermore, it also captures most of the IA and IxD elements.
Configuration Overview
Top right corner has an overview of your configuration, always available during the configuration process, so engineers are aware of cost when configuring and the lead time, 2 key indicators. Large changes in these should be something to take note of. The "Overview” section allows users to quickly see various stats about the current configuration, so they can adjust their decision making appropriately.
Configuration Navigation
Configuration navigation (next & previous) will be used during the initial configuration, when users will go sequentially through the configuration steps. When revising the configuration, the side panel provides an easy way to jump to the relevant steps as needed. During the initial configuration, the user will need to step through the entire process, so the ability to remove the Side Panel can make for a less cluttered experience and increased focused during a crucial and long activity.
Configuration Notes & Changes in Context
Notes made at each step can all be viewed from the side panel at once and users can navigate to the part where the note was made. Same for changes that are made to the configuration.
Leveraged Common Email Design Pattern
This screen is structured similar to an email client, which has a side panel with a listing of emails where the user chooses a single email and the email gets displayed in the details panel. We borrowed this common design pattern, since it seemed to naturally support the way users would be configuring this product: Users had upto 126 steps to go through and for each step there were a bunch of selections that needed to be made.
Attribute & Part Selection Connection
Based on the values selected for the different attributes during a given step, the different Parts available for choosing should appear, hence the attributes and part selection need to appear on a single screen to facilitate such decision making. We used a carousel design pattern for the Part Selection, since we need to communicate that there was an explicit order to the Parts List, so a single line communicates the more clearly, than a grid. Additionally, it makes best use of the screen real estate and most of the time they'd be picking the 1st value.
Vertical Scrolling over Horizontal
The number of attributes to display in the details panel would be more than that space could support a decent amount of time, so scrolling would commonly occur anywhere from 30-40% of the time. We used vertical scrolling, instead of horizontal scrolling or pagination for faster & easier navigation within a screen. Vertical scrolling is more usable and easy-to-use than horizontal scrolling, so we optimized the UI to use vertical scrolling in the Side Panel & Attributes area since there would be a lot of hopping around and adjusting the different attributes.
Instant Saving
As Attribute-Value and Part Selections are made, they are saved and applied, reducing clicks, since the users will have many selections to make and would need to see the impact of those selections as an input into the next selection they make. Furthermore, a given selection for a particular step can have far reaching impact on steps elsewhere in the configuration, as well as affecting the available attributes and attribute-values.
UI Element as Buttons
Many of the data objects (Tenders, Products, Configurations, Parts, Attribute Values, etc.) could be acted upon by the user, hence we decided to make the objects tappable, a common practice, as users find this more intuitive.
Breadcrumbs
Given the deep hierarchy, breadcrumbs were used in the header to provide a sense of where the user was and a means to navigate out and around.
Lots of thought went into the design and it was shaped by findings from the research. Here is a sampling of some of the thought that went into one of the main screens, where engineers would be configuring the product:
Collapsable Side Panel
This wasn't as important during initial configuration, when they'll be going through all the steps sequentially, but would be essential later when the user would be hoping around. Being able to collapse it would give them more screen real estate.
Clear Configuration Naming
The large configuration name just below the breadcrumbs eliminates any confusion of where the user is at, which can help prevent mistakes when changing configurations. When there are multiple pieces of equipment, each with multiple configurations, it can be easy to loose track of where you are and any mistakes can waste alot time and money.
Final Configuration Thumbnail
Eventually, the configurator will support an on-going 3D modeled visualization of the product being configured. Given the tight screen real estate, we embedded it behind a small product thumbnail while still making it easy to access, since it isn't important to see, except for during a few steps of the process.
Custom Large Scroll Bar for Easy Scrolling
Layouts needed to automatically be scalable to a large number of attributes, so screens would probably have lots of vertical scrolling occur. The design uses a multiple column vertically scrolled panel with a larger than normal scroll bar optimize the reading and browsing experience.
Leveraged Wizard Design Best Practices
Listing the actual next step under the “NEXT” text increased the information scent, making it much clearer what is next without having to tap it. Communicating current step, total number of steps, percentage completion also helped give the user context of where they were at. Lastly, giving the users the ability to hop around to different steps in an ad-hoc manner supported their workflow when updating configurations.
The wireframes detail most of the UX requirements, specifically communicating the screen flow and how the interactions work in detail. Screen details around data and functionality are communicated in context to each screen, factoring in the volume of the different data elements and the functionality. A prototype was used to communicate the flow more effectively.
Configuring a Product Involved a High Volume of User Interactions Combined with Unique Behavioral Patterns.
Configuring a product involved up to 126 steps, with numerous attributes at each step that an engineer would need to specify. Many of those attributes were single & multi select inputs that would dynamically enable/disable based on other attribute selections. Behaviorally, engineers scan attributes & values back & forth and would need to see immediately the impact of selections on the form. As the configurator evolved, the number of attributes & values could increase, so the controls would need to automatically scale to accommodate such changes without additional coding. Lastly, there wasn't alot of screen real estate left for these controls and we wanted to minimize the amount of scrolling.
Option 1: Use Drop Downs
Using drop downs for select input controls would allow more controls to fit on the screen, while minimizing the amount of scrolling. However, this would increase the interaction cost by 1-click for each control. Drop downs would also make it harder for users to explore possible configuration options easily. Further more, with drop downs the impact of such changes might not be so clear, yet they would scale to include large amount of values without any additional coding.
Option 2: Use Push Buttons
Push-button controls allow users to make a selection faster and allowed the user to scan the screen and see the info upfront and see all the options quickly. It would result in great efficiency gains compared to drop downs. However, certain fields had a large number of values and so push-buttons wouldn't scale well for those scenarios since the control would consume too much of the screen real estate.
Option 3: Use a Mix of Drop Downs & Push Buttons
We conducted an analysis on all the attributes and values. It was clear that most of the fields had 5 or less values. So, we decided to use push-button controls for these and for anything with larger than 5 values, would use a drop down. This way most of the time, we can use the more efficient push button controls covering most of the fields, while the UI still scales to support the minority of fields with large amounts of values. This allowed us to maximize the number of attributes that can use the more usable push button control.
On this project, I worked with & mentored a visual designer with 6+ years of experience in that realm. She had the desire to expand into interaction design and user research. So I exposed her to the research I was conducting on a regular basis and collaborated with her heavily during the IA and IxD phases of the project, so she could contribute to that and bring an additional perspective to the design process. She made many notable contributions to the design, applying design patterns in situations I hadn't considered.
We focused on how to critically think & apply user research findings, such as a persona's task behavior, to inform design pattern decisions, how to leverage industry best practices, such as usability studies from NN/g or industry leading design language systems, and how to justify design decisions with solid design rationale during critiques.
Here is some feedback she'd shared with me: "...I am really grateful for your encouragement, guidance and support. I am thankful, that I got a chance to work with someone who has vast experience in this area. I have learnt a lot from you in this journey..." - Visual Designer (Mentee)
Once we had some of the IA and interaction framework designed, we needed to validate them with end-users since they were high risk parts of the design. If these were incorrect, then everything in the design beyond this point would significantly impact usability and would be expensive to fix.
Usability Plan
I ran 1-hr long individual usability sessions with 4 tendering engineers, who had never seen the design. They were the primary job role for the configurator. I used a clickable Invision prototype that used black & white wireframes because we needed to validate flow and interactions, not the look of the design. I also updated the design with real data that I pulled from the CTO model, so I could get more reliable and meaningful feedback.
During the sessions, I would start off by giving some background context on the project and then explain the overall goal of the workflow (i.e. configuring a product) that they'd be conducting with the configurator. Then I asked them to complete a particular task on the 1st screen and so on, until they had worked their way through the entire workflow.
Since this process was a new way of working than their current method with new processes that senior members would establish, the junior members I was testing with had to make many assumptions about the process based on their perspectives.
Learnings
We validated and learned many things from these sessions:
The visual designer conducted visual design studies to explore different visual design languages (i.e. color schemes, icons, UI element stylings, data visualization methods, typography, etc.) She addressed the branding guidelines as part of this activity and was up to speed since I'd been regularly briefing her during the user research phase and she'd been involved during the interaction design phase. We evaluated the different visual design languages by factoring in the configurator’s intended use, usage behavior, user profiles, etc.
Visual Design Language 1 - Light & Deep (WINNER)
Followed a light color scheme with more easily differentiated surfaces creating a more distinct visual hierarchy, making each of the data elements standout clearly. This made reading and scanning easy.
Concept 1 was the winner. We stuck with a light color scheme, since this tool is used in an office where there is plenty of light and users will be conducting alot of reading (as opposed to infrequent short bursts). Additionally, this design provided a more distinct & clear visual hierarchy essential on the key screens that pack in alot of interactive elements that impact each other. We did borrowed elements from the 2 design languages to augment this one.
Visual Design Language 2 - Light Flat & Minimalist
Followed a more flat color scheme, with minimal colors & UI element treatments with a subtle visual hierarchy, giving the screen a more integrated look. Additionally, the business units particular branding was more strongly emphasized by making it the primary action color. Some of the gauges didn't visually communicate certain data elements accurately. The major data elements weren't as easily to differentiate either.
Visual Design Language 3 - Dark Flat & Minimal
Followed a similar flat & minimal look, but with a darker colors to give it a more edgy modern look. There were similar data visualization challenges and the dark color didn't seem appropriate given that the intended usage was in the office and involved alot of reading.
The visual design language was further refined as the project progressed. The final UI was only created for the 8-10 main screens from the wireframes, the detailed design was to be completed as part of the development effort. There were many different UI treatments that were applied to enhance the usability of the design, a few of which include:
Leveraged Standard & Generic Iconography
Only the most standard icons (Success, Error, Warning, Info, Search) were used to improve efficiency. For parts in the product hierarchy, we used generic shapes, which didn't have a particular meaning out of context, as way to differentiate between the different part types. Using basic shapes to identify Modules, Part Family & Interfaces, enabled the user to delineate them with speed and accuracy.
Hierarchical Display of Data
The data was represented most prominently, then the unit of measurement and lastly the label. This approach is common and puts the emphasis on the data, which optimizes the speed at which the tool can be used for intermediate and expert users, which is who this tool is targeted at.
Badges. Badges. Badges.
We leveraged badges of different kinds to communicate information and states in small amounts of space. Certain badges had on/off states, while others had visible/hidden states and other badges had 4 different states. Icons, colors and other treatments were used to differentiate the different badges, while also tying some of them together. Badges allowed the design to visually surface relevant info quickly using small amount of space.
Entire Product & Individual Part Data Visualizations
Explored different ways of visualizing data that was communicating a certain portion of a whole. We had X steps out of Y, X parts out of Y total parts, X percentage of the total parts are Part A. We explored different ways to communicate these different pieces of information and settled on a simple linear progress bar, which worked for all the different use cases, was easy to implement and commonly found on lots of applications.
Communicated Information in Multiple Modes
Used more than 1 visual method to communicate information. For example, each of the 3 types of parts in the product hierarchy was assigned a different shape and different color.
Visually Depict Configuration Hierarchy
Indentation differentiates between Level 1 and Level 2 Part Families & Interfaces, combined with colors & shapes to further differentiate parts in addition to labels.
BEFORE
WIREFRAME
AFTER
UI
The client had a vision that this configurator, someday, could be taken onsite with salesman to be shown to clients as way to quickly turn around configurations that could be easily manufactured, with good profit margins while maximizing the usage of the inventory. We needed to ensure the design would be usable on tablets without development rework or too much extra coding. We established relevant breakpoints for key screens in the app and designed all components so that they scale easily to smaller sizes, based on the patterns we used. Some of what we factored in, included:
Large Tap Targets
Made touch targets large enough and with enough padding for quick, accurate & easy tap ability. The configurations on the Product Configurations screen were big tappable cards, the Next & Previous buttons on the Configure screen would frequently be used so were made into larger square buttons, most of the single-select input controls were push-button controls and the tab controls were made to be large.
Reflowing Cards & Forms
We used a card based design for the Tender Listing, Product Listing and Configuration Listing pages, since they are easily responsive with content reflowing to accommodate the reduced width of the screen. Screens with forms used 2 or 3 column layouts, which could easily flow down into 1 column layouts as needed.
Part Selection Carousel
We used a Carousel design pattern for the Part Selection section of the Configure screen. This made sense since the list was prioritized based on Most Recommended part and most of the time the 1st item would be the part the user would select. The probability of selecting a 2nd item was low and the 3rd item was even lower and all 3 most recommended parts fit on the screen. So in most cases the carrousel controls would never be used, however, this pattern supported this edge case without sacrificing screen real estate unnecessarily.
We needed to support the client's pitch to the executive leadership team so they could get funding for the development of the configurator. The pitch was part of a larger meeting agenda related to other topics, so there was a small window for the pitch. Since the audience was executives, we needed to keep it high level & to the point and it needed to be eye-catching, needed to communicate the value in a simple & relatable scenario.
In collaboration with the stakeholders, we decided to use the final full color UI screens and a scenario that could quickly help the audience visually get a feel for the user experience of configurator.
Leverage UI Kits for Greater UI Implementation Accuracy
The configurator had alot of custom UI components and more advanced than typical for this development team. To increase the likelihood that the designs would get implemented with the highest accuracy, we conducted an assessment to find a few UI kits that developers could leverage, which would also ease development.
Search for Official Bootstrap UI Kits
The product configurator was going to be a web application that would integrate with the SAP VC implementation as the backend with a piece of middleware. Bootstrap was to be used for the front-end and the developers said they would be comfortable using a Boostrap UI Kit.
Assess & Short-list Best UI Kits
I guided the visual designer to review only Bootstrap's approved themes and generate a short-list of at least 5+ themes. Then they were to assess all the themes to find the Top 3 that provided the best coverage for the design patterns in our designs, that adhered to the design principles laid out, that aligned with the visual design the best and allowed for future growth of app functionality (i.e. supported the most design patterns). Below is a list of the Top 3, including the assessment of design patterns.
Concept Approval from Executive Leadership, Stakeholders & Users.
While not a guarantee for adoption, it nonetheless validated that we were headed in the right direction with the concept and the client got the funding to start developing the configurator, proving so. Given the complexity of the domain, this at least validated that the design would support the complexity of the process.
Validation from Experts in the Industry
The consultancy that designed the CTO model & engine, was a top-tier international consulting firm that specializes in designing these product configurators for different companies, different types of products and different industries. After getting a demo of the prototype concept we designed, they were "floored" at the quality of the user experience & design we created and short turnaround time for such a complex configurator. They hadn't seen such a high quality user experience in the market, as the one we produced.
Value in User Research & Design
With the consultant's endorsement, the client felt they got value out the engagement with us and got a quality configurator UX design validated by industry experts and at a fraction of the cost the consultants would have charged. This led the client to refer us for future work with another department and subsequently, they have been implementing the design using SAP's Hana framework.
Co-Design Speeds Up Design Process for Complex Domains
Certain domains are quite challenging to grasp, so co-designing with with users and stakeholders when working "problem space", is an efficient way to understand user needs. This fast tracks the process by not having to expend lots of time acquiring all the know-how prior to entering the "solution space".
Conducting Additional UX Research After 3rd-Parties Have Conducted Research is Challenging
The consultants had already conducted a variety of different types of research, that we needed to leverage. However, it was conducted with different goals in mind, so not all of it was applicable and there were gaps. We had to ensure we learned as much as we could from this research without reconducting it and appearing like we are redoing the same work to the client.
Client-side Product Managers Are Crucial to Guiding Conversations
With so many stakeholders and such a complex process, we were unearthing alot of different user needs. Some were relevant to address initially, some later on and some were not relevant to the scope of the project. The key stakeholder was crucial in creating boundaries during discussions, moving conversations forward, since I didn't have the strategic role nor knowledge to make the call.
Clarify Expectations around Collaboration with Development from Beginning
While we did conduct design reviews with the SAP VC team and the front-end development teams, they weren't as deep and frequent as they should have been. As a result, such a complex solution is bound to run into issues when development commences. Before the engagement started, we should have laid out expectations around collaboration with the development teams. Preferably we would have designed everything while the CTO model and engine were designed and before the implementation began.
