Harden designs for real-world use by systematically identifying and designing for every condition outside the happy path. Part of the Intent design strategy system. Covers state inventories, error recovery, empty states, loading patterns, first-run experiences, stress testing, internationalization r

Fortify — Harden for Real World Use Overview The happy path is a fantasy. Real users have 47 character last names, 2G connections on the subway, three year old phones with cracked screens, browser tabs they haven't closed in six days, and no patience for something that doesn't work the first time they try it. Every design starts with the ideal scenario: the user has a stable connection, reasonable data, a modern device, and follows the intended flow without deviation. That scenario accounts for maybe 60% of actual usage. The other 40% is where trust is built or destroyed — the empty state that tells the user nothing, the error message that says "Something went wrong" without explaining what or how to fix it, the loading screen that gives no indication anything is happening, the first run experience that asks for 12 pieces of information before showing any value. Fortify systematically identifies every condition your users will actually encounter and ensures the design handles each one with the same care you gave the happy path. This isn't about pessimism — it's about respect for the people using what you build. When to activate this skill: Edge case reviews, error state design, empty state design, loading pattern design, first run experience design, offline mode planning, internationalization readiness checks, stress testing, or any moment someone asks "but what happens when..." Skill family Fortify works alongside the full Intent skill system, with especially tight connections to skills that define the paths you stress test: /journey — Their flows define the happy path; you stress test everything else. Every flow they design generates a set of questions: what happens when this step fails? What if the user abandons midway and returns? What if data from step 2 isn't available at step 4? Your work feeds back into their flow design as additional states and branches. /blueprint — Their failure mode analysis at the system level feeds your UX level resilience design. When they identify that a service can timeout, you design what the user sees during that timeout. When they map a dependency that can fail, you design the degraded experience. System level failure modes become UX level state designs. /include — Accessibility and fortification overlap significantly. Designing for slow connections, small screens, one handed use, and situational impairment is both resilience work and inclusive design. Coordinate to avoid duplication — you own the state and edge case methodology; they own the accessibility methodology and assistive tech requirements. /evaluate — Their assessment identifies what's failing in the current experience; you design the fixes. When they flag missing error states, absent loading indicators, or unhelpful empty states, those findings route directly to you. Your output feeds back into their next evaluation cycle. /specify — Your edge case documentation becomes part of their handoff package. Every state you design, every error recovery flow you define, every stress test result — all of it needs to be in the engineering spec. Coordinate on format: specs that list only the happy path are specs that produce broken products. /articulate — Error messages, empty state copy, loading messages, first run guidance — all of it is content that needs to be clear, helpful, and on brand. You define what needs to be said; they define how to say it. /philosopher — "What's the most embarrassing way this could fail in public?" "What assumption are we making about our users that would be humiliating if wrong?" The philosopher helps you find the failure modes that nobody's imagined yet — the ones that come from questioning assumptions, not from running checklists. Core capabilities 1. State inventory Every screen, component, and flow has states beyond "default." Most designs only spec the default state. Fortify enumerates all of them. The state catalog: Default — The happy path with normal data. This is what the mockup shows. It's the starting point, not the finish line. Even the default state has questions: what's "normal" data? How much? In what format? What happens when "normal" changes? Empty — No data yet. First use, zero search results, cleared history, new account with no activity. The empty state is the user's first impression of most features — and most empty states are a blank page with no guidance. Design them: explain what will appear here, how to get started, and what the feature does. Show sample data or a preview of the populated state if possible. Loading — Initial load, refresh, background update, lazy loading additional content, submitting a form. Each has different UX implications. Initial load needs a skeleton screen or progress indicator. Background refresh should not interrupt the user. Form submission needs immediate feedback that the action was received. Long operations need progress estimation. Partial — Some data loaded, some pending, some failed. This is the most overlooked state and one of the most common in real use. A dashboard where 3 of 5 widgets loaded, 1 is still loading, and 1 failed. A profile where the avatar loaded but the name didn't. Design for the messy middle, not just the clean extremes. Error — Validation errors (user input was wrong), system errors (something broke on the backend), network errors (connection lost), permission errors (user isn't authorized), timeout errors (request took too long). Each requires different messaging and different recovery paths. Generic "Something went wrong" is never acceptable. Success — Action completed. But what specifically happened? A form submitted — what's next? A file uploaded — where did it go? An item deleted — can it be recovered? A payment processed — what's the confirmation? Success states that leave the user asking "now what?" are incomplete. Offline — No connection. What's cached and still usable? What degrades gracefully? What's completely unavailable? How does the user know they're offline? What happens to actions they attempt while offline — are they queued, rejected, or silently lost? Disabled — A button, input, or feature is unavailable. Why? When does it become enabled? The user needs to understand what's preventing the action and what to do about it. A disabled button with no explanation is a dead end. Overflow — Too much data. 10,000 items in a list that was designed for 50. A username that's 200 characters. 500 unread notifications. A table with 40 columns. Design for the extremes — pagination, truncation, progressive disclosure, virtualized lists. For each state, answer three questions: What does the user see? What can the user do? How does the user recover or progress? Example: State inventory for a file upload component State What the user sees What they can do Recovery/progress Default Drop zone with "Drag files or click to browse" Drag files or click to open file picker — Loading File name, progress bar at 43%, cancel button Cancel the upload Cancel returns to default Partial 2 of 3 files uploaded, 1 still in progress Cancel remaining, remove completed, add more Cancel or wait Success 3 files listed with checkmarks, "Done" button Remove individual files, add more, proceed Click "Done" to continue Error File name in red, "File too large (max 25 MB)", retry icon Retry, remove, or choose a different file Retry or remove and continue with other files Disabled Grayed drop zone, "Upload limit reached (10 files)" Nothing — must remove existing files first Tooltip explains: "Remove a file to upload more" Offline Last uploaded files visible, banner "Uploads paused — no connection" View already uploaded files, queue new files Queued uploads resume automatically when connection returns 2. Error recovery design When something goes wrong — and it will — the user's ability to recover determines whether they retry or abandon. Recovery patterns: Inline recovery. Fix it right here, right now. Validation errors should appear next to the field that caused them, with specific guidance on what to fix. Don't clear the form. Don't scroll to the top. Don't make the user find the problem — point directly at it. Retry logic. Automatic retry for transient failures (network blip, timeout) with exponential backoff. Manual retry button for persistent failures ("Connection lost. Tap to retry."). Never make the user start over when a retry could work. Show what you're doing: "Retrying... attempt 2 of 3." Graceful degradation. Partial functionality is better than no functionality. If the recommendation engine is down, show popular items instead. If real time data fails, show cached data with a timestamp. If a non critical feature fails, hide it rather than erroring the whole page. Undo and redo. Time based undo (Gmail's "Undo send" with countdown). Action based undo (Ctrl+Z for content editing). Explicit undo buttons for destructive actions (delete, archive, move). Every destructive action should be reversible, or at minimum require confirmation. Draft preservation. Never lose user work. Auto save form progress. Preserve draft state across sessions. If the browser crashes, the page reloads, or the session times out, the user's work should still be there. This is non negotiable for any input that takes more than 30 seconds to produce. Error recovery anti patterns to eliminate: Generic error messages with no recovery action. Error states that require a full page reload. Silent failures where the user doesn't know anything went wrong. Error states that clear the user's input. Error messages in technical language ("Error 500: Internal Server Error"). Errors that blame the user ("Invalid input" without explaining what's invalid or why). 3. First run experience design The first time a user encounters your product or feature is the most fragile moment. They have the least context, the least investment, and the lowest tolerance for friction. Patterns that work: Progressive onboarding. Learn by doing, not by reading. Introduce features in context as the user encounters them. First task should deliver value immediately. Reveal complexity gradually — show the simple version first, then surface advanced features as the user demonstrates readiness. Value first. Show what the product does before asking for setup. Let the user see a populated dashboard, a sample project, or a preview of the outcome before requiring account creation, profile completion, or configuration. The user should understand the value proposition from experience, not from marketing copy. Just in time guidance. Explain features when they're relevant, not all at once. A tooltip that appears when the user first hovers over a feature is better than a 5 slide tour that explains everything before the user has context to understand any of it. Sample data. Show what "full" looks like. A project management tool with sample projects. A dashboard with sample data. An inbox with sample messages. This gives the user a mental model of the populated state and shows them what they're working toward. Anti patterns to eliminate: Feature dump walkthroughs (5 slide tours that nobody reads and everyone skips). Mandatory profile completion before showing any value. Empty dashboards with no guidance ("You have no projects. Create one to get started." — but what's a project? what should I put in it?). Forced tutorials that can't be skipped. Tooltips that block the interface and must be dismissed one by one. 4. Stress testing prompts Systematic questions designed to break your design. Run these against every screen, component, and flow. Content stress: What if the title is 3 characters? 300 characters? Contains only emoji? What if the name is "O" or "Wolfeschlegelsteinhausenbergerdorff"? What if the content is in Arabic (RTL)? In Japanese (n

fortify