GOVERNMENT · COMPLIANCE PLATFORM
Minnesota Scrap Metal Reporting Platform
Client
RFP response to MN Dept. of Public Safety (not awarded)
Role
Lead UX/UI Designer
Timeline
2024
Platform
Government Web Application · Desktop
110
Registered dealers
Statewide users the system was designed to serve
6
RFP workflow areas
All covered in the working prototype
2
Role-based experiences
Dealers and state staff, one shared record
My role
Design lead on Savage's bid for a state compliance system, serving dealers and state investigators. The contract went to another vendor.
Team
Project Manager · Technical Lead · Engineering
Scope
Requirements Analysis · Information Architecture · Role-Based Access · Interaction Design · UI Design · RFP Demo
Tools
Figma · Jira · Confluence
This project was created as part of a competitive State of Minnesota RFP. Our team designed and demonstrated the proposed solution, but we were not awarded the contract. The work shown here represents the proposed product strategy, workflows, UX/UI, and prototype rather than a production system deployed by the State.
01 Context
The requirements were already written. The workflow was not.
Minnesota needed a statewide system for recording and reviewing scrap-metal transactions involving detached catalytic converters and motor vehicles. The RFP defined authentication, dealer and organization management, transaction reporting, auditing, restricted access, and a large amount of required information and documentation.
Dealers needed to record seller information, vehicle details, converter information, payments, signatures, receipts, and supporting documents. State employees needed to search across those records, review activity, audit transactions, run reports, and export information. My job was to turn that requirement set into a product structure the team could estimate, design, build, and demonstrate.
The target MVP date was August 1, 2024, following a late-March kickoff, so the proposal also needed a realistic boundary between what had to exist at launch and what could come later.
Dealers needed a structured way to report each transaction, including purchaser details, seller information, scrap items, payment records, and required documentation.
The same reporting system also had to support state oversight, giving authorized users a way to review dealer status, transaction activity, and audit history across participating businesses.
02 Discovery
I broke the RFP into people, workflows, and information.
The procurement document described what the system needed to support, but individual requirements did not always map cleanly to a single screen or feature.
I broke the requirements down by user group, responsibility, dependency, information relationship, and launch priority. A requirement such as recording seller information could involve identity documents, signatures, validation, vehicle information, file uploads, and data that state employees would later need to review. Looking at those relationships made the product much easier to understand.
Discovery 01
One transaction connected a lot of different information.
A single purchase could include the dealer, employee, seller, payment, vehicle, multiple converters, signatures, receipts, titles, registration documents, and other evidence. Those pieces needed to remain connected as one transaction.
Discovery 02
Dealers and state employees were using the same data for different jobs.
Dealers needed an efficient way to create a compliant record for their own organization. BCA employees needed broader access across organizations so they could search, review, audit, report on, and export that information. The underlying record could be shared without giving both roles the same interface.
Discovery 03
Required information still needed hierarchy.
The RFP required a lot of information. Giving every field, upload, and requirement the same visual weight would make the process difficult to scan. People still needed to know where they were in the transaction, what they needed to complete, and what would happen next.
Breaking the transaction into clear stages helped expose how much information had to be captured before a report could be considered complete, including identification, vehicle details, signatures, and supporting documents.
Reporting requirements also had to be organized around the different questions state users needed to answer, from dealer activity and transaction volume to converter counts and payment totals.
03 Decisions
Make the transaction the backbone of the product.
The RFP was organized around requirements, so I organized the product around the work. Seller information, purchased material, vehicle details, payment, documents, signatures, and final review all became parts of completing one transaction, and that same record could then support state reporting, auditing, and investigation.
Decision 01
Keep every piece of a purchase in one record.
Purchaser, seller, material, payment, and documentation data all belonged to the same piece of work. Keeping those relationships visible gave users a clearer way to understand the process and gave the system a more coherent structure.
Tradeoff 01
Dealers complete one long multi-stage entry instead of quick separate forms, balanced by a single review step at the end.
Decision 02
Separate entry from oversight.
Dealers needed an efficient way to create and manage transactions for their own organization. State employees needed tools for searching, reviewing, auditing, reporting, and investigating activity across organizations. I designed those as separate experiences around the same underlying data instead of forcing both jobs into one navigation model.
Tradeoff 02
Two navigation models to design and maintain instead of one.
Decision 03
Put compliance into the workflow.
Compliance lived inside each step instead of in a checklist at the end. Converter details, reuse status, recovered contraband, vehicle ID, and supporting documents were captured where they happened in the transaction, so a report was complete the moment it was submitted.
Tradeoff 03
More required steps inside each transaction, in exchange for reports that were complete at submission.
04 DELIVERY
From requirements to prototype.
The State wanted vendors to show working functionality, not just concept screens, so the design had to stay close to what the team could realistically build. I worked through the requirements with product and engineering, mapped the role-based workflows, and translated them into the information architecture, screens, and prototype. As I worked, I kept checking the design back against the RFP: what requirement does this support, who needs access to it, what information does it depend on, and where does that information go next?
The prototype brought the dealer transaction flow, organization management, access, reporting, and auditing together into one connected system we could demonstrate end to end. I used familiar patterns for forms, uploads, tables, detail views, and status states, split large transactions into manageable stages, and let state users move from organization-level activity into individual records without losing context.
The transaction flow handled item-specific requirements inside the same process, including converter details, reuse status, recovered contraband, vehicle identification, and supporting documentation.
Before submission, the transaction was brought back together in one review step so dealers could verify the people, signatures, purchased items, and total amount before finalizing the report.
On the state side, dealer records connected organization details with purchase history so authorized users could move from a dealer-level audit into the transactions behind it.
05 IMPACT
An end-to-end prototype the team could demonstrate live.
Our team was not awarded the contract, so the platform was never deployed. What we delivered was a working prototype that covered all six RFP workflow areas and could be demonstrated end to end: dealer registration and organization management, the full transaction flow, restricted access, and state reporting and auditing.
The proposal also drew a clear MVP boundary. Authentication, organization management, transaction management, reporting, auditing, and restricted access made up the core release, while 16 additional features, including OCR scanning, API access, multi-location support, expanded commodities, and seller tools, were sequenced for after launch.
The prototype connected dealer transactions, organization management, access, reporting, and auditing in one system, so the team could show working functionality instead of concept screens.
06 REFLECTION
A strong product response does not have to invent more than the problem requires.
This project gave me a much better understanding of the gap between a procurement document and the system people eventually have to use. The State had already done a significant amount of work defining what the platform needed to support. My job was figuring out how those requirements related to one another once someone had to move through them.
That meant thinking about roles, permissions, dependencies, compliance, information structure, and delivery at the same time as the interface. It also made the MVP conversation very concrete. There were a lot of things we could have added, and some of them would have been useful. The important part was knowing what needed to exist for the core reporting system to work and keeping everything else from taking over the first release.
We did not win the contract, but the work still gave me one of my clearest examples of translating complex business and regulatory requirements into actual product behavior.
