It all started when I ran moderated interviews for Language & Market project with Chemical Manager customers across Denmark, Norway, the UK, Finland, and Latvia, combined with sessions with EcoOnline Product Specialists.

These were the key findings relevant to the redesign:

• The form lived in a dismissible modal. Clicking anywhere outside it would close the window and erase everything the user had typed. In a form with eight required fields, this was causing real frustration and data loss.
• The supplier field, one of the most critical inputs, had no search functionality. Users had to scroll a tiny dropdown or find an almost-invisible secondary input to type a name manually. In testing, a third of participants selected the wrong supplier simply because they couldn't find the right interaction pattern.
• The form offered no guidance on what it needed. There were no hints about accepted file formats, no explanation of what "SDS market" or "SDS language" meant, and no indication of what would happen if a storage location was flagged as incompatible.
• Several customers noted they had no idea what happened after submitting a request. There was no confirmation, no status update, and no notification when their request was approved or declined.

Every poorly-filled request landed with EcoOnline's internal SDS services team, creating processing overhead on both sides and long wait times for customers.

In regulated environments, these aren't minor inconveniences. Organisations rely on this data to maintain accurate chemical inventories, conduct risk assessments, and prevent workplace incidents.

Three distinct user groups interacted with this workflow, each with different stakes and contexts.

Amy, Lab Assistant (desktop, admin user)
Responsible for maintaining a compliant chemical inventory under constant time pressure. Badly filled requests created back-and-forth with the services team, adding delays she couldn't afford. Her success metric was an accurate, up-to-date inventory with minimal friction.

Mary, Lab Intern (mobile, read user)
Needed to access safety documentation quickly, sometimes in emergencies, often from a different building. Delays caused by rejected or incorrect requests directly affected her ability to make safe decisions in the field.

Terry, EcoOnline Services (internal)
The person on the other side of every submission. Incorrectly filled requests (e.g. wrong supplier, wrong market, mismatched file) landed on his queue and required manual correction. His challenge was volume: a constant flow of new cases, many of which were fixable problems that better design could have prevented upstream.

Round 1, Moderated usability testing (12 participants)
I built an initial prototype using the new platform's design system and ran moderated sessions focused on a single task: completing an SDS request submission. The findings were clear:

• 2 out of 6 participants requested incorrect supplier because they couldn’t find the input field.
• 2 out of 6 participants tried to change location after they saw the incompatibility sign.
• Not all users want to select location at the SDS request stage.
• The incompatibility warning may stay ignored (“Make it mandatory to change location before you procede. If its possible to ignore, people will ignore it”).

These findings shaped a substantial iteration before we moved to broader testing.

Round 2, A/B testing (35 participants)
With the moderated findings incorporated into a new iteration, we moved to a broader non-moderated A/B test with 35 Chemical Manager users and EcoOnline employees. The two variants tested different visual treatments of the location incompatibility warning, alongside the updated supplier field and restructured form hierarchy.

Task completion was measurably higher than in the August prototype, rising from 60% to 85%. The overall Customer Effort Score for the form reached 3.9 out of 5. Incorrect supplier selections decreased, though some users still struggled to find the manual entry path, which informed the final refinement before launch. The A/B test also confirmed that Version B's warning treatment was more noticeable, though even then awareness wasn't universal, which fed directly into the trade-off discussion around blocking vs. non-blocking behaviour.

The modal vs. page decision, and why I lost (temporarily)
The single most impactful structural fix was obvious from the earliest research: the dismissible modal had to go. Users were losing data, losing confidence, and in some cases abandoning the process entirely. A dedicated page, stable and persistent with a proper back/cancel flow, was the right solution.

Engineering agreed in principle. The problem was cost. The platform migration was already stretching the team's capacity, and rebuilding the request flow as a full page required more development effort than the team could commit to in the initial release window. The modal stayed for several months post-launch while the page rebuild was scheduled for a later sprint.

This was a real trade-off, and a frustrating one. I documented the risk clearly, made sure the decision was visible to stakeholders rather than quietly absorbed, and prioritised every other improvement that could ship within the modal constraint. When the page rebuild eventually landed, the transition was smooth because the interaction patterns had already been validated.

The supplier field
The research was unambiguous: users needed to be able to search for suppliers, not scroll an unsorted dropdown. The redesign introduced a searchable input with progressive filtering. For suppliers not in the database, we surfaced a clear manual entry path, previously a near-invisible secondary field that most users simply didn't find.
One participant in the A/B test suggested an even better pattern: a single input that both searches existing suppliers and allows inline creation of new ones, rather than two separate interaction modes. This was a valid improvement I couldn't implement within the current build constraints, but it's the direction I'd push for in a next iteration.

The location incompatibility warning
This was our most contested design decision during testing. The form allowed users to select a storage location flagged as incompatible with the product, and we had to decide whether to block progression or warn and allow it.
We A/B tested two visual treatments of the warning message. Version A used a warning triangle icon; Version B used an info icon with stronger visual weight. Version B showed better noticeability, with 50% of participants reporting they saw it, compared to lower awareness in Version A. Even then, awareness was far from universal. Some participants didn't read it because surrounding fields were already pre-filled and their attention was elsewhere. Others read it but didn't understand what action it required.

The core tension was compliance vs. usability: making the warning blocking would prevent errors but would also halt users who had legitimate reasons to proceed. We chose the non-blocking path with improved visual treatment, though I wasn't fully satisfied with this outcome. In a future iteration, I'd explore progressive disclosure, surfacing a clearer explanation of what incompatibility means in context and offering a shortcut to fix the settings without leaving the form.

The redesigned flow addressed both the structural failures and the cognitive friction of the original. We replaced the dismissible modal with a stable, dedicated request flow (shipped in a later release), added a searchable supplier field with a visible manual-entry path, restructured the field hierarchy to reflect the order users naturally think through a request, product identity first and compliance details second, surfaced location guidance contextually rather than as an upfront blocking requirement, added inline help text explaining what SDS market, SDS language, and file format requirements mean, and updated all components to current design system standards.

Task completion rate rose from 60% to 85% across A/B testing with 35 participants. The overall Customer Effort Score for the form reached 3.9 out of 5. Incorrect supplier selections decreased measurably due to improved field design and information hierarchy. Users reported increased confidence completing the form without external help.

Internally, the reduction in incorrectly-submitted requests reduced processing overhead for EcoOnline's services team, a direct operational benefit that hadn't been part of the original success metrics but emerged clearly from post-launch feedback.

The biggest thing this project reinforced for me: research is a political tool as much as a design tool. The SDS Request problems were known. What wasn't known, because nobody had documented it rigorously, was the scale of impact and the downstream cost to the services team. Putting that evidence in front of the right people at the right moment, during a platform restructure when the cost of changing things was already being absorbed, was what got this into production.

On the design side, there's a version of this feature I'd still like to build. Most of the information users have to manually enter into the form, including supplier, product category, article number, and market, already exists in the SDS PDF they're required to attach. A smarter form would parse that document on upload and pre-fill as many fields as possible, reducing the submission to a confirmation task rather than a data entry task. That would be the real fix. The current redesign made a broken workflow significantly better. Automation would make it nearly effortless.

I'd also return to the location incompatibility problem with more time and a clearer brief, ideally designing a contextual resolution flow that lets users fix the underlying settings without abandoning the request entirely.