CATEGORY:
Enterprise Software
YEAR:
2012-2019
ROLE:
UI, UX, User Research, Product Management, Marketing Design, Branding Design
Image Relay was a small but mighty Vermont SaaS company — a digital asset management platform used by 400+ companies worldwide. I started there in 2012 as a freelancer and came back four years later as their first full-time designer. Over the next two-and-a-half years I owned the entire design function: product, research, marketing site, and a fair bit of strategy.
Setting up a way to work
I'd just come from IBM, where I'd spent a year working on bringing design thinking into the enterprise. When I rejoined Image Relay full-time in 2016, I wanted to bring some of that with me. Less "what should we build next," more "what's the actual problem we're solving."
But before I could change how we made decisions on individual features, I needed to change how we made decisions, period. The team was small, scrappy, and good at shipping. What it didn't have was a shared way of figuring out what to ship and why. So that's where I started.
The process
The first deck I put together wasn't about a feature. It was about us. I pulled the canonical design thinking frameworks together in one place (Stanford d.school, IDEO, IBM) and proposed a slimmed-down version for Image Relay: four phases, Understand, Explore, Make, Reflect.
The point wasn't process for process's sake. It was to give a four-person product team a shared vocabulary for moving from "we think we should build X" to "we know why we're building X, what we're learning from it, and how we'll know if it worked." Each phase had a defined output. Understand produced a clear problem statement and user research. Explore produced multiple solution directions, sketched and pressure-tested. Make produced a scoped MVP. Reflect was where we measured against success metrics and decided what to do next.
Alongside the framework I introduced a project structure: a strategic roadmap split into Near, Mid, and Long term (Cupcake, Birthday Cake, Wedding Cake), themes that grouped related problems together, and a project brief template that every three-month chunk of work had to fill out before it got built.
The roadmap workshop
With the framework in place, I ran a full-day workshop with the team to figure out what we were actually working toward. We worked through Hopes and Fears, mapped the six experiences inside the product, ran empathy mapping, and walked away with three user types we'd carry through everything after: the Governor, the Producer, and the Consumer. From there we turned needs statements into a Now and Later timeline, and the timeline into our first real roadmap, bucketed into three themes: Governance and Sharing, Triggers and Notifications, and Collaboration.
Redesigning the core DAM
The next big swing was a full redesign of the DAM itself, the heart of the product. This one came with proper user research, multiple rounds of iteration with existing customers, and a rollout plan I'm still proud of.
Rather than flip a switch, we soft-launched to a handful of specific clients first so we could learn in deployment and keep iterating. When we opened it up more broadly, we shipped walkthrough videos I produced and built in a toggle so users could move between the old and new systems on their own timeline. The full rollout took about six months from soft launch to everyone-on-the-new-thing.
We weren't tracking metrics in a rigorous way, but the customer service team became a useful proxy. The new system kept coming up in support conversations as something people genuinely liked. Our customer base grew through that period and attrition stayed very low.
Rethinking Collections
Collections was a feature people used, but not the way it was designed to be used. It was built for sharing files across folders, but in practice everyone was treating it as a one-off. Make a collection, send a link, never touch it again. So we re-cast it.
The new Collections was a presentation tool: a place to build a kind of homepage of assets, lay it out the way you wanted, share it publicly, and update it whenever. This was the first feature we built explicitly for the Consumer persona we'd defined in the workshop. To preserve the original use case without bloating the new feature, we let people select assets across folders and route them through the existing share function. Same job, no separate UI for it.
This one had a long discovery and testing tail before launch, and it's also where we started using the HEART framework (Happiness, Engagement, Adoption, Retention, Task Success) to think about success more rigorously. Honest aside: we were better at setting the metrics up than following through on them. With a team this small, everyone was wearing several hats, and metrics work was usually the hat that came off first.
The rest of the story
The other hats
Around 2017 I introduced the company to Airtable and built out a feature backlog so we could prioritize as a team instead of as a free-for-all. It sounds small, but it was the first time the company had a single source of truth for what was being considered, what was in flight, and what had shipped.
In parallel, I architected and designed the marketing site, partnering with a writer to define the voice and decide how each feature got framed visually. It was the first time the brand felt cohesive across the product and the front door.
A bigger bet: PIM
The last major thing I helped lead was the strategy for our biggest planned launch. The team was deciding between two directions, chase the creative workflow space (where Box, Dropbox, and others were headed) or build a PIM (Product Information Management) offering. I made the case for PIM. The competitive whitespace was bigger, and our existing customer base skewed toward product companies who already had the use case.
I led the early strategy work: pitch deck exploring what it could be, project briefs, discovery research with customers, test plans, and a results deck the team could rally around. It was the most structured project intake we'd run. We were about 60% of the way to launch when I moved on from the company. (Image Relay was acquired by Canto a few years later.)
What I took with me
Two-and-a-half years as the only designer at a small SaaS company is a particular kind of education. You learn to make trade-offs in real time, build systems that scale beyond you, write a project brief and then design the thing in it, launch something on Tuesday and start interviewing users about it on Wednesday. You also learn what falls down when one person is doing all of it, which is a useful thing to know walking into bigger teams.