Fastanel | Mysite 2

Enhancing Fastenal's Inventory Management System

Overview

FASTCrib was entering a critical phase of modernization as Fastenal worked to rebuild its legacy inventory platform for scale, reliability, and future growth. I oversaw UX across the inventory domain, shaping the standards, patterns, and workflows that would define the new platform. Custom Attributes is featured here as a focused case study — illustrating how a complex, high-risk configuration workflow was transformed into a clear, reliable, and scalable experience.

Year 2025

Role Senior UX Designer (Lead)

Contribution UX Strategy · Research · Design Systems · Interaction Design · Team Leadership

Problem Statement

The legacy FASTCrib inventory system had become outdated and difficult to use, leading to fragmented workflows, duplicate steps, and frequent user errors. Warehouse staff, managers, and customers struggled to complete tasks efficiently, often needing to leave the application to find information or resolve issues. Over time, this complexity eroded trust in the platform and limited its ability to scale. A modern, user-centered redesign was needed to streamline inventory workflows, reduce errors, and restore confidence in the system while supporting Fastenal’s future growth.

Standards & Design Foundations

To create a consistent, efficient, and user-friendly system, I defined the visual and interaction standards for FASTCrib:

Typography & Spacing Rules: Established sizes for headers and body text, spacing rules, and hierarchical structures to improve readability.

Color Palette & Visual Language: Selected colors that aligned with Fastenal’s brand while enhancing usability and clarity in workflows.
Templates & Components: Created reusable templates and UI components using Material UI, ensuring consistency across the system.

Design Guidelines: Documented rules for component usage, interaction patterns, and page layouts to guide offshore designers and maintain quality.

Mentorship & Reviews: Led 4 offshore designers, holding regular design reviews to ensure alignment with standards and UX strategy.

These foundations allowed the team to scale design decisions consistently while speeding up development and improving user experience.

So how did we get here?

How Insights Were Identified

Interviewed warehouse staff, managers, and inventory teams to understand real-world workflows

Audited the legacy FASTCrib system to identify friction, duplication, and breakdowns

Synthesized interview notes and observations to surface recurring patterns and themes

Validated insights against user journeys to ensure they reflected end-to-end experiences

This led to a clear set of pain points and opportunity areas grounded in both user feedback and system behavior.

User Research & Journey Mapping

Interviewed 8 warehouse staff and managers to understand real-world workflows and day-to-day frustrations

Mapped the end-to-end experience to surface friction, duplicate steps, unclear flows, and moments where users left the system to find information

Visualized these insights in a journey map that highlighted inefficiencies, uncertainty, and opportunity areas

Used the journey map as a shared artifact to align the team and stakeholders around the highest-impact redesign priorities

Screenshot 2025-10-01 at 4.24.09 PM 1.png

User Journey Insights  The journey map shows how FASTCrib improves the daily workflow of a maintenance supervisor by streamlining critical steps, reducing downtime, and building user confidence.

Reduced Friction: Simplifies part location through to order fulfillment

Increased Efficiency: Faster identification and ordering of parts minimizes downtime

Improved Visibility: Real-time inventory data and tracking provide certainty

Enhanced Experience: Modern, mobile-friendly design supports work on the go.

Early IA mapping revealed overlap between Inventory and Work Orders. We streamlined navigation and added cross-linking patterns to reduce confusion and improve task flow.

Screenshot 2025-10-01 at 4.36.19 PM 1.png

At the start of the project, our review of FASTCrib’s information architecture revealed overlapping functions between Inventory and Work Orders. This overlap caused confusion in the navigation and disrupted user workflows. By mapping the IA early, we identified where these pages should live in sub-navigation, and recommended UI patterns for cross-linking related content. This provided clearer pathways for users and reduced the risk of task duplication or misdirection.

MoSCoW Meathod

MoSCoW Prioritization Workshop  To align the team and stakeholders, I facilitated a MoSCoW workshop (Must, Should, Could, Won’t). Together, we:Defined and prioritized features critical to the redesign.Balanced business goals with user needs to focus on “must-have” improvements.Created clarity around what could be deferred without sacrificing usability.Built consensus early, reducing rework and scope creep later.This exercise helped the team stay focused on delivering the highest-value features within project constraints.

User flows

User flows were a critical checkpoint in the process. They allowed the team to pressure-test logic, confirm alignment with stakeholders, and resolve complexity early—so we weren’t spending time designing or building the wrong thing.

Created detailed user flows to map key tasks end-to-end before moving into wireframes

Used flows as a primary alignment tool with stakeholders to validate logic, edge cases, and system behavior early

Identified gaps, redundancies, and unnecessary steps upfront—reducing rework and saving build time

Ensured everyone shared a clear mental model of the experience before investing in visual design

Custom Atributes

Although this case study spotlights Custom Attributes, I was responsible for the broader FastCrib redesign, including onboarding, inventory, supplier catalogs, and units of measure. Custom Attributes illustrates a full end-to-end workflow, highlighting how I aligned strategy, UX, and engineering across the product.

The Custom Attributes feature was designed to give inventory managers and field staff more flexibility when tracking their unique data needs. The challenge was to create a system that felt intuitive, reliable, and scalable while maintaining clarity and reducing errors.

Users needed to define and manage up to 30 attributes

Each attribute included a name, data type, and required/not-required toggle

Business goal: modernize legacy workflows and reduce user confusion

User goal: provide clear progress, easy edits, and confidence that work was saved

Design goal: balance speed with control while avoiding overwhelming layouts.

Design Iterations

Iteration 1 – Bulk Entry Page

Showed all 30 attribute slots at once

Users could enter attributes directly into a large table

Feedback: overwhelming, confusing, high cognitive load.

The first approach displayed all 30 attribute slots at once, letting users enter multiple attributes directly in a single table. While this gave full visibility, it quickly became overwhelming and confusing for users, creating a high cognitive load. Stakeholders initially liked the idea of bulk entry, but in practice, it proved difficult to navigate and error-prone, signaling the need for a more guided, stepwise approach.

Iteration 2 – Add and save as you go

After testing the bulk-entry approach, we realized users were overwhelmed by 30 blank slots at once. The next iteration, Save-As-You-Go, simplified the flow by letting users enter one attribute at a time directly on the page.

Each attribute had its own form with name, data type, and required toggle

Once an attribute was successfully entered without errors, an “Add Attribute” CTA appeared, prompting the user to add the next one. This ensured users couldn’t skip attributes unintentionally

Users could save an attribute individually at any time, but the intended workflow was to enter all attributes first and then save them together, giving flexibility while maintaining efficiency

Stakeholders responded positively — the design felt cleaner, more intuitive, and aligned with user needs

Limitation: backend constraints meant we couldn’t guarantee that attributes would always save reliably, which created a technical risk.

Observation: while the CTA ensured sequence, users weren’t aware at the start that they needed to complete each attribute before adding the next, which could lead to confusion.

This iteration highlighted a key lesson: Balancing usability with technical feasibility is critical. While cleaner for users, it required further refinement to ensure reliability — setting the stage for the final, modal-based solution.

Iteration 3 – Modal-Based Flow

After uncovering backend limitations with the Save-As-You-Go approach, we needed a solution that was both user-friendly and technically reliable. The final iteration introduced a modal-based workflow that gave users clear control and visibility while ensuring data integrity.

Users clicked a “Create Attribute” CTA, opening a modal to enter the attribute name, data type, and required toggle.

Boom - Pow! A modal opens. 

A modal gives users a clear “you’re doing a thing now” moment.

The beauty of this approach

It kept the mental model clean

It made repetitive creation feel rhythmic

It prevented users from skipping steps or getting ahead of the system

But here’s the twist: this wasn’t just a UX choice — it became a reliability choice. If a user moved on too quickly, or if the backend choked for even half a second, attributes could fail silently. That’s a trust killer. And trust is everything when you're building a workflow tool.

Engineering walked me through the persistence limitations, and the tradeoff became obvious.  A little more structure (modal) → way more reliability. That moment is where the whole design direction clicked.

This flow lowered user error by%32, gave us crystal-clear error states, made troubleshooting easier, and reinforced a reliable pattern for repetitive actions.  Users always knew what was happening, what succeeded, and what needed fixing — and I guided them straight back to the happy path with helpful microcopy and inline validation.

But there was a twist.Moving to modals meant confronting real-world issues like:What if the backend fails?What if the user tries to create a duplicate?What happens when they hit the max limit?What if the user closes the modal too early? What if the state doesn’t update in time? In other words: How do we keep users on the happy path even when things go sideways?

Instead of letting errors break the rhythm, I designed each failure mode to act like a friendly hand on the shoulder, nudging the user back into flow

Clear inline error states for invalid names and duplicates
Save failure messaging with retry logicHard limits that explain why the user can’t add more attributes
Instant list updates so users see their changes reflected immediately

Each error state wasn’t just a warning — it was an invitation to recover gracefully.  This gave users the confidence that the system wouldn’t betray them mid-workflow.

What I’d Do Differently

If I were starting this project again, I’d bring engineering into early concept exploration sooner. Not to limit design ideas, but to pressure-test them earlier against real system behavior. While the early concepts were strong from a UX standpoint, deeper technical context earlier would have helped us converge faster and avoid rework.I ’d also document iteration decisions more formally as they happened. Many of the strongest insights came from live conversations and problem-solving moments, and capturing those earlier would have made stakeholder alignment even smoother.

That said, working through these challenges strengthened the final solution and reinforced the value of designing with constraints, not around them.

Collaboration & Ownership

Throughout this project, I worked closely with product, engineering, and architecture partners to align user needs with technical realities. I often acted as the connective tissue between teams — synthesizing feedback, clarifying trade-offs, and helping move decisions forward when requirements or constraints were unclear. When conflicting information surfaced, I proactively reached out across roles to gather full context rather than designing in isolation. This helped the team converge on a solution that was both usable and reliable in production, and reduced downstream surprises.