LogicGate Select Field Types
Improving the end user experience with baked-in context & guidance.
Over the summer (2023), I had the opportunity to intern at LogicGate with the End-User-Experience team to address common pain points with confusing or hidden instructions in the record forms in hopes to decrease time spent by end users. I was able to research and design solutions for incorporating context and guidance into select field types.
I was also able to contribute to the design system with banner notifications for desktop and mobile screens. Please see the project here. ->
Timeline
June - Aug 2023
Team
2 Designers
6 Software Engineers
1 Product Manager
Skills
User Research
Visual Design
Storytelling
Interaction Design
Tools
Figma
Survey Monkey
Whimsical
Jira
introduction
What is LogicGate and who are their users?
LogicGate is a B2B company that works in governance, risk, and compliance software to assist in creating automated workflows without the need for coding. While the customization and drag-and-drop features draw in many of their users, it can oftentimes lead to disorganized, cluttered, and let’s face it, ugly interfaces that are hard to navigate. Their two main users are power builders and end users who build the records and fill them out, respectively.
In the end-user-experience team, they were working on an entire overhaul of the platform’s UI with moving the design from a multi-column layout to one-column. Based on previous UX research, the concern for single
column forms was driven by the want to add guidance or context to certain form fields so that the users can understand the meaning behind the selection in more detail.
Overall, users were getting confused and frustrated from spending too long filling out records.
Thus, we asked
How might we offer a custom select field type that would allow builders to include context for each selection so that end users can make an informed choice saving valuable record real estate?
starting the discovery
UX Research
Before starting this project, LogicGate didn’t have any existing research on how users felt about the current context and guidance on their record forms. Because of that, I worked with product designer Justin Siddons and the UX Research team to create a survey along with conducting interviews with various stakeholder: subject matter experts (SMEs), builders, and end-users.
As we started thinking of what goals we wanted to accomplish with our research, we also first looked into the current product and the potential problems that may arise with consolidating everything into a single-column design.
The main goals guiding our approach
Assessment
What’s the value of context & guidance regarding field types and the platform as a whole?
Improvement
What’re current user pain points when completing records? Where can improvements be made?
Validation
How do users respond to design changes and what suggestions do they have?
Current Product Features
Selects & Calculations
Here, the guidance is helpful as it’s right by the selection, but isn’t supported by the one-column update. There needs to be a way to incorporate the two that’s intuitive.
Tables
This is the same case as above in which the guidance is helpfully placed next to the select field, but it’s not supported by the new one-column feedback. This also gives a new opportunity to test out different table designs and formats.
Guidance
In this use case, the instructions at the top section were originally collapsed and hidden, which in-it-of-itself was unintuitive. Additionally, although this example shows only one section of questions underneath the instructions
These designs, along with the automatically collapsed instructions at the top of the record-filling pages have made the process much more complicated and hard to understand when filling out the pages. To address this, I began some iterations on the design to include in the survey so that respondents would understand the problem scope better. Especially since I was coming in during the process of revamping the platform, they already had some research insights in related fields that I was able to bring in to guide what changes we could make.
The survey
After a few more iterations, we finally had some designs to send out to the LogicGate users to get their feedback. With the UX Research team, my project lead, Justin, and I crafted questions to ask that were then input into SurveyMonkey and sent out!
Within two weeks, we received 23 responses: 17% being internal users (employees) and 83% being external users (customers). During this time, I also met with the subject matter experts (SMEs) and the other designers to get their feedback.
You can see the specifics for the research that we did here:
We learned from this that...
01
Users prefer integrating the guidance into the responses more than the current designs.
02
The use of color with labels is helpful with visualizing data and breaking up text.
03
The scalability of the designs must be kept in mind, especially with the tables.
More specifically, a lot of the work we had was validated by our research (yay!) but now we had to address how these ideas would work in different edge cases, as well as the technical feasibilities of some aspects, including the color labels.
iterating on the designs
Color Labels
With the fully customizable interface, I first wanted to look into how the labels would scale if there were more than the five options that my prototypes had.
Meeting with the lead SWE on the EUE team, we discussed the different technical methods that could be used to assign colors to labels: having pre-set colors for a certain amount of labels (ie 10) and calculating a range between that, assigning a color generator and specifying the extremes of spectrum, setting a max amount of colors and not having variability after a certain point, etc. The biggest concerns that arose from this were that the colors in between were oftentimes visually unappealing (especially with green) as well as some issues with accessibility with the text contrast.
We eventually decided that the MVP would be to pre-set ten colors and calculate the colors in between when there are more than ten colors.
The biggest decisions with tables came with restricting the maximum text allowed and choosing what space the ‘select’ feature should exist to be both visible and easy to understand. Additionally, some designs began to play with how the tables would look in a one-column modal, and if/how the content would be clipped.
With checkboxes and radios, there was some uncertainty on how they would be distinguished from the tables on the use cases in which there’s more than one definition paired with a label or term. Unfortunately there wasn’t enough time for me to fully explore how these different select field types might overlap, but I was able to begin some ideation on it here.
At the same time, I also began iterating on how the new feature would appear on the record-building side.
With this, many of the existing designs would remain the same, but the biggest focus was on what the flow for activating the color scale for the labels.
To incorporate it, there would have to be guidance on what it does as well as the option to use it or now; from there, the modal would also need to preview what colors were available.
All of this was then shown to the design team and SMEs again to receive some final feedback as my time interning at LogicGate was (very sadly) coming to an end.
Final Design Recommendations
Builder Color Scale Toggle
On the builder end, we added a simple toggle with guidance on what it would do to the record creation form, similar to many other toggles on the LogicGate platform. This, along with the previews of what color would be assigned to which values, would properly show builders how their actions connect to the final record and still grant them the flexibility of workflow customization.
Drop-down Selects
With the drop downs, I integrated the explanations of the terms into the design, as well as into the select options. As opposed to the original design in which the instructions were separated from the selections, either at the top of the form or in a separate column.
Checkboxes & Radios
Both the checkboxes and radios follow a similar logic in which the definition of the term is now attached to the select.
In order to prevent the different options from being spaced too far apart, character constraints would be implemented for the builders. They would also include the option to incorporate color labels as seen below.
With the labels, as the options scale, the same logic would be applied as described earlier with the color calculations. In many uses cases, however, the typical options are as prototyped here
Tables
The tables also follow a similar logic as the other selects with the labels, but with a different treatment of the formatting of the descriptions, especially in the cases in which there is more than one. Although the modal would always vertically scale to fit the height of the table, the one-column design limits the viewable width; this prototype is an example of how the design would approach an overflow.
Although I was able to progress a lot with my iterations, they are far from finished. Ideally, if I had spent more time with LogicGate, I would have been able to undergo usability testing with the UX Research team and assess if more research was needed. I also was unable to discuss the designs with the product manager to discuss MVP designs and different use cases, and from that, work through the technical feasibility of the designs with the front-end and back-end SWEs. However, I’m incredibly grateful to the End-User-Experience team for working with me over the summer on the project, and providing their endless support.