Kevin McComas
I design interfaces for technical products, with a focus on making complicated systems feel clear and familiar.
For three years, I led design at Satellite, a privacy-first encrypted chat startup. I was responsible for the design system, onboarding, desktop and mobile experiences, and a lot of the brand work.
I'm looking for a product team that cares about strong visual design, thoughtful systems, and the people who actually have to use them.
- Product design
- Design systems
- Prototyping
The challenge
Satellite gave people ownership of their identity and account recovery. The catch: we handed new users a crypto-style recovery phrase about ten seconds after they opened the app, before they had any context for why it mattered.
The move
I reordered onboarding around familiar setup steps, generated recovery credentials quietly in the background, and reframed recovery around an encrypted, password-protected file. The raw seed phrase stayed available for advanced users.
The result: the redesigned flow shipped on desktop and mobile without weakening the product's self-custody model. Account setup became clearer and much less intimidating.
Overview
Satellite was a privacy-first, censorship-resistant messaging app built around people owning their own identity, their own data, and their own account recovery. It was made for people who care a lot about privacy. The hard part was that the security model, as good as it was, asked a lot of anyone who wasn't already fluent in crypto-style recovery.
As Lead UI Designer, I redesigned the onboarding flow across Satellite's desktop and mobile apps. The goal was to make account creation feel familiar to people without recovery-phrase experience, without weakening what made the product private in the first place.
The original flow put a recovery phrase in front of people almost immediately. Recovery phrases are second nature if you live in crypto, but they're unfamiliar to just about everyone else. When I sat people down to actually use it, the confusion showed up before they'd even finished making their account.
So the redesign flipped the order. Familiar setup steps came first, the recovery credentials got generated quietly in the background, and recovery itself got reframed around an encrypted, password-protected file. Advanced users could still get to the raw seed phrase if that's what they wanted. That version shipped publicly on both desktop and mobile.
My Role
Lead UI Designer. I owned the onboarding redesign from the first scrappy usability observations all the way through design exploration and developer handoff. That looked like:
- Running lightweight moderated usability sessions with non-technical friends and family
- Mapping out the original onboarding flow, step by step
- Finding the exact moments where account creation lost people
- Designing the revised flows and screens in Figma
- Writing implementation tickets for engineering
- Working closely with the developers to brainstorm and pressure-test solutions
- Keeping ease of use, privacy, decentralization, and self-custody all standing at the same time
This was more than a visual update. The recovery system was wired straight into the app's decentralized architecture, so the fix meant working closely with engineering to figure out what could actually move, what had to stay put, and how much complexity we could keep out of the user's way early on.
The Problem
The original flow made sense on paper. It just showed people the most complicated part of the product first. Roughly, it went:
- Open app
- Create account
- Get a recovery phrase
- Write down the recovery phrase
- Make a username and PIN
- Add a profile picture, banner, and bio
If you've used a crypto wallet, that order feels totally reasonable. If you haven't, it asks you to make sense of the highest-stakes part of the app right away. Watching people test it, they'd stall out on the recovery phrase screen and ask the same handful of things:
“What do I do with this?” · “Where do I save it?” · “Do I need this every time?”
That told me it wasn't just a copy problem or a layout problem. The real issue was that we were asking people to understand a technical recovery model before they'd built any mental model of the product itself.
The word “PIN” added to the mess. The app said PIN, but the field really behaved like a password. That little mismatch left people unsure what they were even creating, how careful they needed to be with it, and how it related to that recovery phrase. The product was leading with its architecture when it should have been leading with what people already expected.
Research Approach
Satellite was built around privacy and minimal tracking, so watching people through analytics or behavioral tracking was off the table on purpose. There also wasn't a formal research budget to lean on.
So I kept it small and hands-on: lightweight moderated sessions with non-technical friends and family. I'd hand someone the app, ask them to give it a go, and watch for where they hesitated, misread something, or looked to me for help.
That group gave me exactly the kind of feedback I needed. A lot of them weren't technical or crypto-native, so they wouldn't quietly work around a rough edge the way a power user might. If something was confusing, it showed immediately. The seed-first recovery experience was what tripped everyone up. People understood the familiar parts: pick a username, set a password, add some profile details. What they didn't understand was why they were being handed a long recovery phrase before they'd even used the app.
The Insight
The recovery phrase mattered. It just didn't need to be the first thing anyone consciously dealt with. The old flow treated “technically transparent” and “clear to the user” as the same goal. In practice, showing the recovery phrase that early made the whole app feel more intimidating and less familiar than it needed to.
The opening was to keep the self-custody model exactly as strong as it was, and only change when and how people ran into the complexity. The principle I kept coming back to:
Show the complexity when it becomes useful, not before someone has any context for it.
Design Goals
The redesigned flow had to:
- Make the first few steps feel familiar to people without crypto experience
- Take the confusion out of account recovery
- Avoid centralizing recovery just to make life easier
- Keep the privacy and censorship-resistant model intact
- Leave the advanced recovery options right there for technical users
- Work cleanly across both desktop and mobile
Which meant the answer couldn't just be “make it like every other social app.” Satellite had real security and decentralization requirements that weren't going anywhere. The job was to make that model easier to understand and follow.
The Redesign
The new flow moved the familiar account-setup tasks up to the front. It became:
- Open app
- Create account
- Choose a username
- Create a password
- Add a profile picture, banner, and bio
- Generate recovery credentials in the background
- Offer recovery through an encrypted, password-protected file
- Keep the raw seed phrase available for advanced users
Instead of opening with a recovery phrase and a high-stakes save-this-now moment, the app started with the patterns people already knew from social and messaging products. You could build an identity first: username, password, profile photo, banner, bio. That alone made the whole thing feel familiar and lowered the amount of technical context you needed just to get going.
The bigger move was pushing seed generation into the background. Technically the seed could still be created first. The difference was that you no longer had to babysit a list of recovery words before you'd even finished setting up. Recovery got reframed around an encrypted, password-protected file. Lose access or want to sign in somewhere else, and you'd use that file plus your password instead of hand-typing a long phrase.
And the raw seed phrase was still there for anyone who wanted direct control. It just stopped being the default hurdle everyone had to clear.
Before and After
Before
The flow put technical recovery ahead of familiar account creation. People were asked to save a recovery phrase before they had any context for what it was, why it mattered, or whether they'd need it every single time they logged in. That bred hesitation right out of the gate. The “PIN” label made it worse, since the interface language and the actual security behavior didn't match.
After
The flow put the user's confidence first. People started with familiar setup steps while recovery credentials were quietly generated in the background. The system stayed fully self-custodial, but the default recovery experience got a lot easier to grasp through that encrypted backup file. The raw seed phrase was still available for advanced users. It just wasn't the first big idea every newcomer had to wrap their head around.
Working With Engineering
Because onboarding was tied straight into Satellite's account architecture, I was in constant contact with the developers through the whole redesign. I'd build the screens and flow diagrams in Figma, then use those to talk through implementation options with engineering. We dug into how to keep the security model whole while pulling complexity out of those critical first few minutes.
I also wrote up implementation tickets so the work could be broken into pieces the team could actually pick up and ship. The final direction came straight out of that back and forth: keep the recovery seed as part of the underlying account system, but stop letting it be the first wall a new user runs into.
Outcome
The redesigned onboarding shipped publicly across Satellite's desktop and mobile apps. Since the product was built around privacy and minimal tracking, there wasn't an analytics-heavy funnel to measure. I went back to the question that started the work: did the new flow clear up the confusion I'd watched people run into? The redesign helped:
- Take the conceptual friction out of account creation
- Make the app feel familiar to people without crypto experience
- Clear up the difference between passwords, recovery files, and seed phrases
- Keep account recovery decentralized
- Avoid centralizing recovery for the sake of convenience
- Bridge the gap between privacy-first technology and what everyday people expect
The part that mattered most was that people no longer had to understand a crypto-native recovery model just to make a basic account. The app stayed private and self-custodial, while the first run felt like a normal onboarding flow.
What I Took Away
This one shaped how I think about designing for privacy-focused products. A security feature only counts if people can actually understand it and finish it. In a product built on decentralization and censorship resistance, the right move isn't always to copy the convenience patterns of the big centralized apps. Sometimes it's to keep the underlying model exactly as it is and just change how and when someone bumps into its complexity.
The onboarding redesign was never about making Satellite less secure. It was about making the existing security model easier to understand and use.
Visual Notes
The screens here are early Figma explorations from the onboarding redesign. The version that actually shipped kept evolving through the work with engineering, but these show the core direction: the flow changes, the reframed recovery, and the usability calls that carried through to the desktop and mobile release.
Satellite.im Lead UI Designer
Satellite was an immutable, open-source, end-to-end encrypted chat platform built around privacy, censorship resistance, and letting people actually own their own data. I led design on it for three years. Here's the tricky part: because Satellite was built on purpose without invasive analytics or user tracking, I couldn't just watch dashboards to figure out what was working. So improving the experience meant doing it the hands-on way. I leaned on direct feedback, lightweight usability testing, competitive research, and close collaboration with engineering to make a complex privacy-first product approachable to people who weren't already fluent in the technology.
Content creation
I've spent a lot of time making things for streams and other content projects: thumbnails, overlays, VTuber characters, and the systems behind them. I usually make the assets myself, and the VTuber work is still my favorite because it mixes character design, costume design, and UI.
3D design & modeling
I came into 3D through hardware prototyping, designing physical things that actually have to get manufactured: parts that need to be producible, ergonomic, and still look good on a shelf. I usually model in Fusion 360 for the dimensional accuracy my engineering-focused projects need. The Mag Handle was a real product concept, and the prop-pin work came out of a personal hardware project I care about a lot.
Freelance & independent work
Client work taught me how to move quickly without letting the details fall apart. I've worked on car show posters, event flyers, logos, and full brand identities. The brief changes every time, the timelines are usually tight, and the final files still have to work everywhere from a phone screen to a four-foot banner.
The American Freedom show pieces needed to feel loud enough for an event, patriotic without disappearing into stock-graphic territory, and clean enough to survive large-format print.
I built a repeatable visual family for the car and motorcycle events: high-impact type, bold contrast, and layouts that could flex without losing the identity. Client work moves fast. The system is what keeps “fast” from turning into “sloppy.”
The assignment
Create event artwork for the American Freedom car and motorcycle shows that could grab attention from a distance and still hold together when reproduced at very different sizes.
The approach
I treated the pieces as a small identity system instead of a pair of one-off graphics. The typography does the heavy lifting, the patriotic cues stay unmistakable, and the supporting elements can move around without making each new format feel like a new brand.
That gave the client a visual family they could reuse across the related events while still giving the car and bike shows their own moment.
What mattered
Production was part of the design problem from the beginning. The artwork had to stay legible, keep its energy, and avoid delicate details that would fall apart outside a tidy screen mockup. It's the kind of constraint I like: make it bold, make it useful, and make sure the file behaves when somebody sends it to print.
About me
I'm a UI/UX designer who gets a little obsessed with the details. I'm the kind of person who will rebuild a component system because the old one is making everyone work harder than they need to, and I sleep better once it's cleaned up. Three years at a startup gave me a bit of everything: product UX, brand identity, pitch decks, and marketing campaigns. I like building things that last, and I do my best work when design is part of the process from the beginning.
I also write code, model hardware in 3D, and have made more VTuber sprites than I'm prepared to admit out loud. Based in Columbus, OH, and open to remote and hybrid roles.