SilverVuecase manager & cms reporting software

Designing at startup speed without lowering the bar

How I joined a healthcare product already in flight, learned the domain while delivering, and built the trust and working systems that helped a fast-moving team ship better software.

Role: Senior & Lead Product Designer
Team: 2 PMs, 2 Dev Teams, QA Team, 1 Designer
Domains: Discharge planning, Post-acute care
Products: SilverSearch, SilverSign, PAC Portal, Check
Constraints: Limited runway, Production deadlines
Rhythm: learn → design → build → QA → ship → improve

02.01I joined a product already moving at startup speed

When I joined SilverVue in January, I wasn't walking into a clean greenfield project or a mature UX organization.

SilverSearch was already in production, product and engineering had been doing the design work themselves as best they could, and the team was already deep into the next set of releases. They did not need me to stop the train and introduce a perfect UX process. They needed me to get on the train while it was moving.

SilverVue had some customers and revenue, but runway was limited and there was real pressure to expand the product suite and find more revenue quickly. Two product managers, two engineering teams and QA were already working hard. My job was to get up to speed on hospital discharge planning, build trust with the people already doing the work, and make the product meaningfully better without becoming the reason anything slipped.

SilverVue interface screens showing provider search and discharge-planning workflows, with a callout highlighting over 50 interactions and features launched in three months.

02.02I learned the domain while I was already delivering

I started on January 23rd and my notes from January 24th were already full of decisions about sorting, filtering, provider types, service areas, insurance and preferred networks.

That pretty much captures how I had to work at SilverVue: learn and deliver at the same time.

I read everything I could get my hands on about discharge planning, the IMPACT Act, post-acute care and our competitors. I mapped the existing product and spent long stretches with our two Product Managers, asking questions and listening to how they thought about the problem.

A random person might have found those multi-hour domain conversations mind-numbing. I found them fascinating. At the same time engineering and QA still needed screens, so I used my best judgment, showed work early, listened to feedback and got more accurate as my understanding grew.

Pages from the official CMS Discharge Planning booklet, with a callout explaining that I read it to get up to speed.

02.03I raised the UX bar without stopping the train

Before I arrived, the product managers and engineers had successfully gotten the product built and launched, but the interface had grown out of implementation decisions rather than a coherent experience.

The functionality was there but the interaction mess had buried it. My job wasn’t to redesign the product from scratch; it was to make what was already being built easier to understand, more consistent and more human.

I reduced visual noise, created clearer hierarchy and grouping, cleaned up controls and started turning one-off decisions into repeatable conventions. I also started a living SilverVue style-guide on my first day with things like buttons, borders and the search box, then kept expanding it as the products grew.

The goal was not perfect Apple-level redesign. The goal was a much better product the team could still build on the schedule they already had.

SilverVue provider search before and after cleanup, comparing the original engineering design with my clearer layout, filters, and provider cards.

02.04I made room for real users when there was no time for research

The product team already knew the domain well, so at first I leaned heavily on their experience. But I kept asking for direct exposure to users because I’ve learned that no matter how much thought smart people put into a design, real users will show you things you wouldn’t come up with on your own.

By April I was at the American Case Management Association conference in Washington, D.C., where I talked with 14 people over two days at our booth.

Later I joined a customer visit in Evanston, Wyoming, specifically because I wanted to see case managers in the environment where the tablet was actually used.

I also sat in on a long interview with Dr. Khan while the product and executive team explored Medicare quality work. It was not a perfect research program but it was enough to turn abstract healthcare workflows into people and situations I had actually seen and heard.

Research at the ACMA conference, a customer visit to Evanston Regional Hospital, and a group interview with Dr. Khan.

02.05Early friction with my PM became one of my best product partnerships

Our product manager was writing most of the detailed requirements when I joined, and she was used to working out a lot of the design herself.

I came in expecting to own more of that work. We clashed almost immediately. What mattered was what happened next: Our manager listened to the issue, the the PM and I talked it through, and the disagreement turned into a trusted relationship instead of politics.

I realized very quickly that the PM put an unusual amount of thought into requirements and flows, and I respected that because I worked the same way. She quickly realized I was actually listening to what she was trying to accomplish rather than trying to replace her thinking with mine. She could talk through a complicated idea, I could make it visible fast, she would point out everything I had misunderstood, and we would go back and forth until it felt right.

Over time she relaxed more around the design because she knew I would cover it, and I relaxed around the product details because I trusted how deeply she thought them through. I loved working that way.

Printed SilverVue interface designs and sticky notes on a wall, used by my product manager and me to collaborate and iterate.

02.06Engineering and QA were part of the design loop, not just a handoff

I brought the engineering leads into new design work from the beginning, showed them iterations as I was drawing them, and tried to understand the implementation constraints behind what I was drawing from the get-go.

One engineering lead in particular was especially front-end focused, and I spent time looking at how his components were built and made design-system decisions with him rather than just throwing finished screens over the wall.

QA pushed me in a different and equally useful way. On one SilverSearch feature I had created 1 art-board and expected engineering to infer the facility variations. QA came back and asked for drawings of every scenario explicitly defined so they had a full checklist to test against. I expanded the prototype to 11 detailed art-boards so they had the explicit requirements.

One line from my design-system notes captures a core belief of mine about working with engineering: “How organized I am as a designer directly affects how organized the programmer is.”

Eleven detailed SilverVue facility-page design variations, created to give the QA team an explicit checklist of scenarios to test.

02.07I learned to use design levers to avoid becoming the bottleneck

I spend a good amount of time thinking through a complicated workflow, and when the risk justifies it that is a strength. Other times, like at SilverVue, I also scaled that design process to fit the time we actually had.

I think of design as having levers. I can change fidelity, the amount of documentation, how many states I make explicit, how broadly I explore before converging, and what gets sequenced into the next iteration.

What I don’t treat as optional are the things that create real user risk, break the core workflow, make the design too hard to build or create expensive rework later.

At SilverVue, if the PM asked for a change I tried to get it in front of her within a day or two depending on the scope; if engineering or QA found a missing detail that blocked the sprint, I resolved it the same day. That speed kept design inside delivery rather than becoming a separate process the rest of the team had to wait on.

UX design levers shown as sliders for fidelity, amount of documentation, number of states, iterations, and timing, illustrating how to adjust the process for faster handoff.

02.08The working model scaled across the product suite

The most important outcome was not that one SilverSearch redesign went well. It was that the relationships and way of working survived into the next projects.

After the SilverSearch and SilverSign work, the team moved into PAC Portal, where post-acute care providers could manage their company information that appeared in SilverSearch. I led the design of that admin product from inception to launch. Then the work moved again into Medicare quality products and the much more complicated Check/MACRA space.

By then we were not rebuilding trust every time a new initiative started. The rhythm was familiar: understand the system, make the problem visible, iterate closely with product, bring engineering and QA along, document the details that actually mattered, ship it, and learn from what happened. Russ later described the result much more simply: “app by app, Jon had redesigned our entire product suite.”

SilverVue product suite screens showing the PAC Portal listing editor and the Check MACRA patient dashboard.

02.09What SilverVue taught me about my best work

SilverVue was financially unstable, but as a working environment it clarified something important about me and how I work.

I don’t need a perfect UX org, unlimited time or complete ownership of every decision to love the work. I just need smart people whose thinking I respect, mutual trust, hard problems, access to real evidence, close relationships with engineering and QA, and a team that actually builds and ships what we are working on together.

I can happily help bring someone else's idea to life when I understand and respect the reasoning behind it. I can move extremely fast when I trust the people around me. I want disagreement to make the work and the relationship better, not turn into control or politics. And I want to stay connected to a problem long enough to see the software become real, learn from it and make the next version better.

SilverVue is still one of the clearest examples of me doing my best work: listening well, diving deep, drawing fast, caring about what engineering actually builds, and helping a group of capable people get more done together.