Understand
Audit the Console, map first-time journeys, and study comparable cloud products.
Most recent internship · Cloud infrastructure
Making complex cloud workflows feel clear.
Crusoe provides the computing power that AI teams need to build and run products. I worked on the Console, the web app where customers create resources, monitor them, and understand what they cost. This case study covers three projects: first-time guidance, a usability review, and a clearer connection between usage and billing.
00 · ContextInfrastructure at the scale behind the Console.
Selected internship work is presented at an appropriate level of detail.
ProcessShared across all three projects
A repeatable path from ambiguity to an implementation-ready direction.
Each initiative moved at a different pace, but the underlying process stayed consistent: understand the system, frame the right problem, design at multiple horizons, and align the final direction with the people building it.
Frame
Connect recurring friction to user needs, technical constraints, and product priorities.
Design
Explore interaction patterns, test near-term and future directions, and refine the system in critique.
Align + hand off
Partner with engineering, product, brand, and writing to prepare implementation-ready work.
Project overviewConsole empty states
Turn an empty screen into a useful starting point.
An empty state is what someone sees before they create a resource or receive data. These screens were inconsistent across the Console, so I audited the product and designed one reusable pattern. The first version was simple enough to ship quickly, with a second version showing how guidance could become more helpful over time.
12surfaces audited
6interface patterns
2versions planned
5partner teams
02 · Audit
I looked for the same problem across the whole Console.
I reviewed twelve screens and interface patterns, then followed a new account through five product areas. This showed where first-time users repeatedly lost context or reached a dead end.
Uneven guidance
Some empty pages explained the product. Others assumed users already understood the infrastructure.
Create buttons without context
Users could start an action without knowing what they needed first or what would happen next.
Different states looked the same
Empty, blocked, loading, error, and recovery moments often used the same message.
Before · existing Console
The same first-time moment looked different in every product area.
These are six real screens from the audit. Some offered only a create button, some relied on technical language, and others revealed missing requirements only after the user tried to continue.
Users received different amounts of context depending on where they entered the Console.
Create buttons appeared before prerequisites, expected outcomes, or useful starting choices were clear.
Truly empty, blocked, and missing-prerequisite moments were not clearly distinguished.
03 · Problem framing
The real problem was not an empty screen. It was not knowing what to do next.
The goal became clear: explain what the product does, recommend one next step, and keep users informed after they start an action.
An empty page with too little explanation.
Users could tell that nothing existed, but not what the resource did, why they needed it, or what to create first.
A short explanation and one clear next step.
First-time users needed enough context to begin without reading a wall of technical instructions.
One pattern that changes as the resource changes.
The guidance covers setup requirements, creation in progress, failure, recovery, and the next step after success.
04 · Competitive analysis
I studied how other cloud products guide new users.
I compared how similar products explain resources, recommend a first setup, place documentation, and show progress or errors. I used the clearest patterns as principles, not as screens to copy.
Compared
Explain the product
How other cloud tools introduce an unfamiliar resource.
Crusoe response
Use a specific title and one short explanation instead of a generic “no data” message.
Compared
Recommend a first step
Whether users see only a create button or receive a useful starting point.
Crusoe response
Lead with one action now; add recommended setups in a later release.
Compared
Show help in context
Where other products place documentation, command-line steps, and prerequisites.
Crusoe response
Keep documentation visible and explain requirements before users reach a dead end.
Compared
Explain what happens next
How the interface responds after a user starts an action.
Crusoe response
Use banners to show progress, failure, retry, and readiness after creation begins.
Competitive takeaway
The clearest products explained the resource in plain language, recommended one starting path, and showed visible feedback after the user acted.
05 · V1
The first release focused on consistency.
Every empty state received the same basic structure: a relevant illustration, a clear title, a short explanation, one primary action, and a link to documentation.
Say what is missing
Name the specific resource or data instead of using a generic “nothing here” message.
Explain why it matters
Give users only the context they need to understand the screen and the next step.
Lead with one action
Make the best next step obvious and keep documentation available as a secondary option.
Cover what happens next
Design for requirements, progress, failure, and recovery instead of stopping at the first empty screen.
06 · V2
The next version adds guidance before and after creation.
Recommended setup cards help users make the first choice. Persistent banners then explain what is happening, what went wrong, or what to do next. Keeping this work separate allowed the simpler first release to move forward.
Edge-case banner system
The cards recommend where to start. The banners explain progress, failure, recovery, and readiness.
07 · Collaboration
Team feedback shaped what we shipped first.
I reviewed the work early with design, product, engineering, brand, and technical writing. Together, we chose a focused first release and made each part easier to build and reuse.
Choose what to ship first
Design and product helped separate a focused first release from ideas that needed more time.
Check what was buildable
Engineering confirmed which states, actions, and requirements the Console could support.
Make it feel like Crusoe
Brand and technical writing refined the illustrations, terms, instructions, and help links.
AI-assisted workflow
Claude Code helped me organize findings and test alternatives.
I used AI to group repeated observations, compare wording options, and look for missing states. I checked every result against the original research, and the team made the final decisions about accuracy, feasibility, and tone.
What the team decided
We shipped a simple, consistent first version and saved the more advanced guidance as a clearly documented next step.
08 · Outcome
One pattern, applied across the Console.
The team received a first version ready to build and a clearly documented plan for a more guided second version.
Design principle
Give users enough context to act, without making an empty moment feel heavy.
04 · CollaborationDesigning across the system
Frequent reviews kept the work clear and buildable.
I worked with design, product, engineering, brand, and technical writing throughout the internship. We reviewed problems early, agreed on scope, refined the experience together, and documented decisions before handoff.
05 · Outcomes
Clearer experiences for customers and clearer plans for the team.
The internship produced improvements the team could ship now, reusable patterns for future work, and clear documentation for larger ideas that needed more time.
Reusable patterns
Created one empty-state system for the Console, with a focused first release and a clear next version.
Clearer billing
Connected AI usage, cost, the responsible product, and the system activity behind it.
Shippable priorities
Turned usability findings into Jira tickets ranked by user impact and engineering effort.
Clear handoff
Delivered final designs, edge cases, behavior notes, and implementation guidance.
06 · Reflection
What I'm taking with me.
Infrastructure products feel easier when users can always see what they selected, what the system is doing, and what will happen next.
A strong first release can solve the immediate problem while still leaving a clear path for a more ambitious version.
Design documentation should help the team understand the decision, not only show the final screen.