Your small business has a shared inbox — support@, info@, help@, and maybe a dedicated mailbox for the CEO.
Emails come in from customers, and your team needs to figure out who's handling what.
Someone assigns a thread for an email. Someone else adds a note because the customer called in separately.
A third person needs to search for a conversation from last month and save those search parameters so they don't have to reconstruct them every time.
Email Center Pro handled all of this — but it had been built by developers without a designer. The interface worked, but it took too many clicks to complete basic tasks. Search was complex and often difficult to use.
The application had accumulated users, including Adobe, through sheer utility rather than good experience.
Palo Alto Software decided it was time to rebuild. New tech stack, new team, new product — eventually named Outpost.
They assembled a full team of 14 to 18 people: developers, an architect, QA, a project manager.
But when it came to the design, they hit a wall.
Four different designers were hired to create the visual direction for Outpost. Each one was rejected by the CEO, CTO, and VP of Technology.
None captured the direction leadership was looking for — and that direction hadn't been fully articulated yet, making the target difficult to hit.
Formal requirements hadn't been developed, there was no budget for user research, and the product had no logo, brand colors, or visual identity to design against.
Meanwhile, the development team was already in motion — assembling React components based on reasonable assumptions about what the application would need, building the technical structure of a product that had no approved design.
I was working on a different project at Palo Alto Software when they asked me to take on the design.
The timeline was already compressed, and I was starting from a position that four other designers had attempted — with the same stakeholders who had rejected all previous attempts.
There was also no requirement documentation, no user research budget, and no existing design system.
I had to simultaneously figure out what the product needed to do, design how it should look and behave, and produce artifacts detailed enough for a development team that was already building.
Rather than spending weeks developing a comprehensive design proposal — which is what the previous designers had done, and which had been rejected each time — I dove into the existing product.
I used Email Center Pro myself. I sent emails back and forth with team members, testing every workflow. I interviewed stakeholders and the developers who had built the original application.
I gathered and organized every piece of existing user feedback I could find.
From that immersion, I built my own requirements list and then designed fast.
I iterated rapidly — showing work to the team, getting feedback, making adjustments, and showing again. Each cycle refined both the design and the underlying requirements.
The stakeholders who had rejected four designers approved my direction immediately, and I became the lead designer for the project.
The requirements I developed from existing user feedback identified four core capabilities:
The pain points were equally clear:
Based on stakeholder input, I designed the complete application interface — every screen, every interaction, every state.
The inbox view, the conversation thread, the assignment workflow, the search and saved search experience, the tagging system, the dashboard for managers to view performance across mailboxes.
Each element was designed to reduce the number of steps requirred to accomplish what users came to do.
I didn't just produce visual designs. I built HTML/CSS pototypes using Jekyll static site builder and liquid templating language — providing code that developers could reference and directly translate into React components.
The prototypes weren't approximations. They showed exact spacing, responsive behavior, interaction states, and visual hierarchy. Developers used them as their primary reference for implementation.
The development team took pride in matching my prototypes precisely. The gap between design and production was nearly invisible — there were times I clicked on my own prototype expecting it to function, not realizing I wasn't in the actual application.
After 
Before Several months into the project, the marketing team revealed their plans for the Outpost website and brand identity.
The colors, fonts, and design language they'd developed were entirely different from the application interface.
The two had evolved on separate tracks, and the result was a visual disconnect.
This created a problem I couldn't ignore: a customer would visit the marketing website, form an impression of the brand, then open the application and encounter something that looked and felt like a different product. That kind of disconnect makes software appear untrustworthy.
I raised the concern with the marketing designer, but their focus was on the website launch.
So I went to the VP of Technology and the project manager. I asked them to give me some time.
By this point, I'd been working on the application for months. I had deep insight into the functionality, the interaction patterns, and the opportunities for improvement I'd been cataloging along the way.
They gave me the time.
I redesigned the application interface to incorporate the marketing team's visual direction — the cleaner aesthetic, the blue palette that would become the brand's signature color — while preserving and enhancing the interaction design and usability improvements I'd developed over the preceding months.
The redesign wasn't just some new colors. It was a chance to address every interaction I'd flagged for improvement, now unified under a cohesive brand identity.
Stakeholders loved the redesign so much that they requested immediate implementation — postponing several planned features to get the new design into production as quickly as possible.
The application design then inspired updates to the marketing website, completing the brand unification in the opposite direction from where it started.
The tagging system was a key organizational tool — users labeled email conversations with colored tags for quick visual categorization.
With tags, I needed to convince the team and stakeholders to make tags easy to apply, edit, and delete. Some wanted to move the delete to a different views, others didn't want to include color.
I negotiated all the concerns and through my designs convinced them of the benefits of this design.
Working with the QA team, I selected tag colors so that colorblind individuals could differentiate between each tag easily.
I chose the palette deliberately, informed by accessibility standards, because a team email tool used by diverse organizations couldn't afford to exclude anyone from one of its primary organizational mechanism.
Over 40 new business customers signed up during Outpost's initial trial release — validating that the redesigned experience was compelling enough to attract users in a competitive market for team email tools.
Outpost became the #1 Google search result for "Team Email Application" and quickly outpaced competitors.
User feedback reported saving an average of 40 work hours per month per account, which is 480 work hours saved per year.
The brand unification I initiated became the product's visual identity. The blue palette and design language from the application redesign carried through to marketing materials, creating the seamless experience from website to product that hadn't existed before.
Outpost was eventually discontinued as the company shifted priorities, but the design work demonstrated what a unified, user-centered redesign could achieve.
If I were to do this project again, I'd push harder for even a small user research budget at the start.
I built the requirements from staff knowledge and existing feedback, and the results validated that approach — but there's always a gap between what internal stakeholders think users need and what users actually struggle with.
Even a handful of usability sessions with real customers during the first month would have either confirmed my direction or revealed blind spots early enough to address them.
I'd also document the design rationale more explicitly from the beginning.
The rapid iteration that got stakeholder approval was the right move for the moment, but it meant that some design decisions lived in conversations and whiteboard sessions rather than in written records.
When the brand unification redesign happened, I had to reconstruct the reasoning behind earlier choices.
A lightweight decision log would have preserved that context without slowing down the pace. ▪️
All work © Jayna Bergerson unless otherwise noted.
