CASE STudy —
Leading Design at New Millennium
[A]
I led the design for the Sales Application overhaul at New Millennium Building Systems. As the sole in-house designer, I grounded every decision in real research, making sure what we built was exactly what users needed and something we could actually maintain without a full design team behind it. That meant working closely with Project Owners and Developers, and staying in constant conversation with stakeholders and internal users across the company.
[B]
New Millennium is a steel joist and deck manufacturer, a subsidiary of Steel Dynamics, a Fortune 500 company. Their existing systems got them this far, but staying ahead of the competition means building something new.
[C]
2025 - Present
[Fig 1] The solution
Sales is the backbone of how the business quoted, tracked, and closed projects, and everyone had learned to work around problems rather than solving it.
[1]
The Problem
The process starts with structural drawings. Estimators place repetitive, unintuitive markups in Bluebeam, count everything by hand, transfer the numbers into Excel, and backcheck their work. Then they re-enter it all into a legacy system that's hard to use and doesn't cover everything they need. So they rely on workarounds, then workarounds for those workarounds, and more on top of that.
Sales is estimated to review 10x more projects than engineering, yet has less than half the automation. If we can cut estimating time and get quotes out faster, the business can win more projects.
[2]
The Opportunity
To find where this workflow could improve, we visited all seven of the company's sites. If we were building a new application, we wanted to get it right. At each site, we ran a two-day workshop.
Day 1:
Shadowed real users to understand what they do day to day, where things break down, and what needs fixing.
Ran a journey mapping workshop [Fig 2] with users to confirm we'd captured everything correctly, identify pain points, and uncover opportunities.
[Fig 2] Journey mapping for one site
Day 2:
Brainstormed potential features for the new application that would improve the workflow.
Ran a MoSCoW workshop (Must, Should, Could, and Won't have) with users to prioritize that list [Fig 3].
[Fig 3] Summarized MoSCoW
[3]
The Users
It quickly became clear that many different types of users would rely on this application, each with their own needs and goals. As the designer, I wanted to understand them beyond what we saw during shadowing, so I conducted several user interviews and used them to build user personas. I grouped participants by role and defined each persona's key responsibilities, which parts of the application mattered most to them, and where we could improve their experience [Fig 4].
These personas also give the team a lasting reference for the Sales department's users, useful for any future projects involving them.
[Fig 4] Sales user personas (Fake names and photos used)
[4]
The Solution Intent
After extensive discussions with stakeholders and the product owner, we decided to build a single web application that would house all of Sales' responsibilities. The product group later expanded this vision into a company-wide intranet where multiple departments could work in the same place, making it much easier to manage data that's shared across departments.
[5]
The Sketches
With direction set, we got straight to work. Since the user groups were eager to stay involved, we took an agile, iterative approach to the project. Here are a few rounds of early sketches [Fig 5]:
At this stage, we didn't want to get caught up in details. This was the time for big-picture thinking, which is why the sketches use Comic Sans and squiggly lines. Keeping the visuals deliberately rough helped keep conversations about the screens focused on function over form.
[6]
The "UI Kit"
As the only in-house designer, I knew a fully custom design system wasn't realistic. It would need ongoing maintenance that only a dedicated team could sustain. After discussing it with our external UX designer and the product team, we decided to build on an existing component library instead: shadcn-svelte. We applied customizations to fit our needs and recreated the components in Figma, giving us a consistent design foundation that developers can easily utilize from the library and requires very little upkeep [Fig 6].
[7]
The Milestones
By this point, our feature list had grown far beyond what we could build all at once. Trying to deliver everything would have delayed the release for too long, and the business needed something in users' hands soon. So we prioritized. We created a milestone timeline that defined our Alpha goals and an MVP release schedule [Fig 7], starting with the most essential features and planning to add the rest over time. With an agile approach, the first release doesn't have to be the finished product. It just has to be a solid foundation we can keep building on.
[Fig 7] Project timeline
[8]
Final Designs
The biggest challenge was ensuring that developers had a clear understanding of what needed to be built. A significant part of my role involved keeping Figma files as up-to-date, organized, and detailed as possible to minimize ambiguity and prevent miscommunication during handoff. With our design team of just two supporting a development team of nearly 50, maintaining a clear and reliable source of truth was especially important to ensure everyone stayed aligned throughout implementation.
[Fig 8] One example of how everything is organized on Figma
[9]
Reflection
This project taught me a lot, both as a designer and as a collaborator. Since it took place during the emergence of AI in the workplace, I was able to explore how AI could support my workflow and improve efficiency. As the sole designer on this project, I had to be mindful of how I managed my time to meet deadlines. AI helped take on some of the heavier lifting, particularly in data consolidation, research analysis, and brainstorming, allowing me to dedicate more time to the actual design work. I'll elaborate more on how I incorporated AI into my process below.
Beyond the design work itself, this project gave me a deeper understanding of the project lifecycle and the importance of communication in keeping everyone aligned. From product owners to developers and ultimately the end users, each stakeholder played an important role in shaping the outcome. As the bridge between these groups, I learned how to better communicate my design decisions, advocate for user needs, and identify what information or support I needed from upstream stakeholders to move the project forward.
AI also played a significant role in my research and ideation process. Using Claude Code, I was able to consolidate user research findings, organize feedback, and identify recurring themes without having to manually document and sort through everything. This made it easier to translate research into actionable design decisions. It also served as a brainstorming partner, helping me explore alternative approaches and consider ideas I might not have thought of on my own. While AI helped streamline the process, I learned the importance of applying my own judgment to validate its outputs and ensure that the final decisions remained grounded in user needs.