Process instance

The more steps a process has, the more fields there are to be completed. It also means more people (actors) will be involved in completing those fields in addition to referencing fields completed by prior actors.

“Too much scrolling”

Once our product managers gathered all of the issues and suggestions from our client, they immediately requested to implement collapsible sections to address the major concern being that the page was "overwhelming” and had “too much scrolling” in addition to other suggestions such as changing the layout and updating to our new design system and meet corporate standards.

The concern was understandable and of course, modernizing the design was a given, however, the UX team felt that we didn’t have enough information to support the accordion implementation.

We needed more information and didn’t have the time or support to perform user research to validate the concern.

The decision to implement collapsible accordion sections was out of our hands in UX.

Compromises

This project had a lot of obstacles. Many came from product management, some came from our client, and several came from our development team.

There was a lot of independent interpretation when it came to understanding the collaboration with our client and what the contract really required. In the very beginning, both product and development wanted to take advantage of small wins as often as we could which meant taking their design suggestions and implementing them right away.

Being the sole designer on this initiative, I had to face most of these battles alone and if there’s one thing to know about me is that I’m very (productively) stubborn.

I pushed against the accordions because we didn’t know if it was a true need for all of our users. In fact, we barely understood the problem we were trying to solve. “Too much scrolling” could mean a lot of things and approaching how we display the input fields really opened the door to a variety of solutions. Jumping to accordions felt premature.

Unfortunately, I did not win the argument but I was okay with that because it allowed me the opportunity to test the solution in our legacy product while I worked on applying the new design system.

Initially, I recommended A/B beta testing all of the sections collapsed and all of the sections expanded. The goal was to test the adoption by seeing if our users would collapse sections if they found them automatically expanded and also learn if seeing less on the screen would address the scrolling concern (showing the sections automatically collapsed).

Development wasn’t keen on the idea and argued that if all sections were expanded that no one would adopt the accordions and that we should automatically have them collapsed at first. I advised that was the point of the test because if nobody adopted collapsible sections, we clearly didn’t need that particular enhancement. We moved forward with my intent to A/B test.

While building this internally (before releasing it to users) there was an uproar about all sections being collapsed and most believed that they had lost information or that there was a bug. This was great feedback so we decided to keep the sections expanded and I added “expand all/collapse all” buttons saving development from having to set up A/B testing. I was then able to set up product mapping using Gainsight analytical to continue tracking adoption.

Research begins

Now that all of that was settled, I could continue understanding the problem further. We didn’t have enough information and I needed all I could get before hopping into figma.

I created two research plans, one specific to the process instance (the long form page) and the project landing page (this is where users search existing processes and start new ones).

There was a lot of pressure when it came to timing, so I also created a roadmap to help communicate to our client what to expect and when. As weeks went by, I would complete each phase and link any deliverables I was allowed to share with them.

Transparency was the biggest ask from our client and their involvement with the actual design was minimal. Not that it wouldn’t have been welcome, but I was happy to say there were few design obstacles and it would later be very well received.

Missing information

Modernizing the look

e-Builder was acquired by our parent company Trimble Inc. in 2018 and Trimble had their own style guide that we were asked to slowly implement.

One thing I had in the back of my mind at all times was that the new layout and the updated look of the input fields would likely solve a lot of the issues for how the form was digested by our users and while I was going to continue exploring the collapsible sections, there were a lot of elements that would do nothing but enhance the usability of the page.

I felt that I had a lot of information to support the design decisions I was about to apply but it was really important that whatever I did to this page would serve as a “template” for other pages that would later be enhanced with the new design system.

Using miro, my UX team and I conducted an audit of the legacy product and established what that consistency would look like across the board including main action buttons, form fields, data visualization, etc.

This also meant submitting a handful of components to the design system team and even spawned a dedicated tiger team I would later be a part of to design advanced tables (grids) with filter and view capabilities.