Overview
Itemize was my first application-development job out of college. I was hired as the first frontend engineer, and once the team saw I also designed, they brought that work in-house to me as well. Anything involving UX became my domain.
Problem
Itemize’s design and frontend had been outsourced, so the product had no in-house owner for its UX. The web app ran on an inherited interface that was costly to change, the data-entry experience was mouse-heavy and slow, and small improvements were hard to ship, which meant design questions rarely got answered at all.
Constraints
- Small early-stage team and limited resources
- An inherited interface that was expensive to change
- Data-entry throughput directly affected the business
Approach
Working directly with the PM, and with the backend teams where needed, I took on everything UX. Shipping a chart estimated at multiple weeks in a single day bought me the credibility to propose more, and the new web app I built off the back of it became the direction the CEO embraced for the product. From there I added saved filters and team management, redesigned the data-entry flow to be keyboard-first so operators spent less time traveling with a mouse, helped build a team payment system, and rebuilt the marketing site so the marketing team could run it themselves.
Key Decisions
Build a new web app rather than keep patching the inherited interface
| Reasoning | Alternatives |
|---|---|
| The old interface put a ceiling on what could be designed at all. Replacing it turned UX from a negotiation over what was feasible into a question of what was right, and the result became the company’s product direction. | Continue incremental fixes to the existing interface |
Redesign data entry around the keyboard
| Reasoning | Alternatives |
|---|---|
| The operators using this all day were the highest-frequency users in the business. Cutting mouse travel meant more documents processed, so a UX decision showed up directly in the company’s numbers. | Keep the mouse-driven workflow |
Let the marketing team change their own site and pricing
| Reasoning | Alternatives |
|---|---|
| Every copy and price change had been routing through engineering. Handing marketing a way to make those changes themselves removed a standing dependency between two teams and freed engineering from routine requests. | Hand-code every marketing and pricing change |
Result & Impact
- First win: Shipped a feature estimated at weeks in a single day
The new web app became the company’s product direction and shipped within my first year, and across my time there anything touching UX, the app, internal tools, payments, and the marketing site, ran through me.
Learnings
- One early, visible win buys the credibility to propose the larger change
- Optimizing the highest-frequency workflow pays outsized dividends
- Giving another team a way to help themselves is a design decision, and it removes a standing dependency
The story behind it
Itemize was my first job in application development out of college. I was hired as the first frontend engineer; until then the work had been outsourced to a team in India. During the interview their lead engineer was weighing frontend frameworks and asked what I thought of the up-and-coming Angular; I told him you didn’t need Angular, and he respected the honesty where others would just agree. They also liked the side projects I did, focused on solving problems in style.
When they saw I also did design work, they eventually cancelled the outsourcing contract and handed me both roles. From there, anything involving UX was mine, down to small touches like a receipt-capturing game on the marketing site for engagement.
All projects