The Product Designer’s Pre-Launch Shotgun List: 7 Things to Verify Before You Ship

You’ve polished the mockups, the prototype feels right, and the engineering team is ready to merge. That last sprint before launch is a high-stakes moment: one overlooked edge case can turn a smooth release into a fire drill. This guide is a pre-launch shotgun list—seven verification points that catch the most common and costly oversights. We’ll walk through each check with concrete examples from architecture and product design contexts, so you know exactly what to look for before you hit ship.

1. Interaction Model: Does It Match User Expectations?

Every interface carries an implicit promise about how it behaves. When a user clicks a button, they expect a response within milliseconds. When they drag a component in a 3D modeling tool, they expect smooth transformation feedback. The first thing to verify is whether your interaction model aligns with established patterns in your domain. For an architecture design tool, that means checking that pan, zoom, rotate, and selection gestures behave consistently with industry-standard tools like Revit or SketchUp.

Consistency with platform conventions

If your app runs on the web, users bring expectations from browser-native controls. For example, right-click should open a context menu, not trigger an unrelated action. In a recent project for a building information modeling (BIM) plugin, the team discovered that their custom scroll behavior conflicted with the browser’s native scroll, causing users to accidentally zoom instead of scroll. The fix was simple—use standard event handling—but it was caught only after a pre-launch review.

Feedback for every action

Every action should have a clear, immediate response. When a user adjusts a wall thickness parameter, the 3D view should update within 100 milliseconds. If the update takes longer, show a loading indicator or a skeleton placeholder. We’ve seen teams skip micro-interactions like button state changes (hover, active, disabled) because they assumed users wouldn’t notice. They do. A quick pass through your prototype with slow-motion recording can reveal missing transitions.

One reliable method is to script a set of critical user journeys and record screen captures at 60 fps. Then review frame by frame: is there any frame where the UI appears frozen or unresponsive? If so, that’s a candidate for interaction redesign. Teams often find that their “instant” response is actually 200–400 ms because of async data fetching—add a spinner or optimistic update to bridge the gap.

2. Accessibility: Who Is Left Out?

Accessibility is not an afterthought—it’s a core requirement. Yet many product designers treat it as a final checkbox. Before launch, verify that your design meets at least WCAG 2.1 Level AA standards. For an architecture platform, this includes considerations like color contrast for floor plans, keyboard navigation for toolbars, and screen reader support for annotations.

Color and contrast

Architecture diagrams often use subtle color gradients to indicate zoning or structural loads. Those gradients may be invisible to color-blind users. Use a contrast checker to ensure that text and interactive elements have a ratio of at least 4.5:1. Also test with grayscale simulation: can you still distinguish all layers? If not, add texture or pattern overlays as a secondary cue.

Keyboard and screen reader flows

Try navigating your entire interface using only the keyboard. Can you reach every button, input, and menu? If your tool uses drag-and-drop for placing building components, provide a keyboard alternative—like arrow keys to nudge and Enter to confirm. Screen readers should announce dynamic updates, such as when a new floor is added or a dimension changes. We’ve seen teams forget to set aria-live regions on real-time measurement displays, leaving blind users unaware of critical changes.

Accessibility testing tools like axe or Lighthouse can catch many issues automatically, but manual testing with real assistive technology is irreplaceable. Schedule a 30-minute session with a screen reader user if possible; their feedback often reveals gaps that no automated tool can find.

3. Error States and Edge Cases: What Happens When Things Go Wrong?

Happy paths are easy to design. The real test is how your product behaves when something unexpected happens. Pre-launch, map out every possible error state for each user flow. For an architecture design tool, this includes network failures, invalid input (e.g., negative room dimensions), unsaved changes, and concurrent edits by multiple users.

Meaningful error messages

Instead of a generic “Something went wrong,” tell the user what happened and how to fix it. For example, if a user tries to set a window width larger than the wall, show: “Window width exceeds wall length. Reduce width or select a different wall.” Include a clear action button or link to the relevant settings. We’ve audited products where error messages were hidden in console logs—that’s unacceptable for production.

Recovery paths

Every error should have a recovery path. If a save fails, allow the user to retry or save locally. If a 3D render fails due to memory limits, offer to simplify the model or reduce texture resolution. In one case, a team building a collaborative structural analysis tool discovered that when one user’s session expired, their unsaved changes were lost permanently. The fix was to auto-save drafts every 30 seconds and restore them on re-login.

Edge cases like empty states also matter. What does the interface look like when a project has no floors yet? Show a helpful placeholder with a call to action, not a blank canvas. Similarly, test with extreme data: a building with 200 floors, or a site with 50,000 points. Does the UI remain responsive? If not, implement virtual scrolling or level-of-detail culling.

4. Performance and Load: Does It Feel Snappy?

Performance is a feature. Users will tolerate a lot, but not a laggy interface. Before launch, profile your application under realistic conditions. For an architecture tool, this means testing with large models, slow networks, and low-end devices.

First load vs. subsequent loads

Measure time to interactive (TTI) on a 3G connection. If it exceeds 5 seconds, consider code splitting, lazy loading, or server-side rendering. For a BIM viewer, the initial bundle might include libraries for 3D rendering, measurement, and collaboration—but not all users need all features immediately. Load the core viewer first, then fetch additional modules on demand.

Animation and interaction smoothness

Animations should run at 60 fps. Use Chrome DevTools’ performance tab to identify jank. Common culprits are layout thrashing (recalculating styles repeatedly) and heavy paint operations (e.g., drop shadows on every element). For architectural renders, consider using WebGL-based rendering instead of SVG or Canvas 2D for complex geometries. We’ve seen teams switch from SVG to Three.js and reduce frame times from 120 ms to 8 ms.

Don’t forget about memory leaks. Long-running sessions can accumulate event listeners or detached DOM nodes. Use the memory profiler to take heap snapshots before and after a series of actions. If the memory grows steadily without garbage collection, investigate. In one project, a forgotten interval that polled for updates every second caused the app to consume 500 MB after an hour—easily fixed by clearing the interval when the component unmounts.

5. Data Integrity and State Management: Is the Truth Consistent?

Users trust your product to keep their data safe and consistent. Before launch, verify that the application state is always reliable, especially during complex operations like undo/redo, multi-user collaboration, or offline sync.

Undo/redo stack

Test undo after every possible action: adding a floor, deleting a wall, changing a material. Does undo revert to the exact previous state? Are there any actions that break the stack (e.g., saving a project should not clear the undo history)? We’ve encountered tools where undo after a save would revert to a state before the save, effectively losing recent work. The fix is to maintain a separate history that persists across saves.

Collaboration conflicts

If your tool supports real-time collaboration, define conflict resolution rules. When two users edit the same wall length simultaneously, whose change wins? Use operational transformation or conflict-free replicated data types (CRDTs). Test with simulated concurrent edits—have two testers modify the same property at the same time and verify the outcome is deterministic and sensible. In an early version of a structural analysis tool, concurrent edits caused the model to corrupt; the team had to implement a last-write-wins strategy with a visual indicator when a conflict occurred.

Offline support adds another layer of complexity. If users can work without internet, ensure that changes are queued and replayed in order when connectivity returns. Test with intermittent network throttling (e.g., 50% packet loss) to verify that sync doesn’t duplicate or drop edits.

6. Security and Privacy: What Data Is Exposed?

Security is often left to engineers, but designers have a role too. Pre-launch, review the data your product collects, stores, and transmits. For an architecture tool, this might include building floor plans, client names, and structural load calculations—all potentially sensitive.

Data minimization

Only collect what you need. If your app uses analytics, anonymize IP addresses and avoid tracking individual user actions inside projects. For example, you don’t need to log every mouse move—just feature usage events. Review your data schema and remove any fields that aren’t essential for functionality.

User permissions

If your product has sharing features, verify that permissions are enforced correctly. Can a user with “view” access download the original file? Can they see comments? Test with different roles: admin, editor, viewer. In one case, a team discovered that their “view only” role could still export the full BIM model as a PDF because the export endpoint didn’t check permissions. A simple server-side permission check fixed it.

Also consider UI-related security: does your interface expose internal IDs or error stack traces? Never show raw database IDs in URLs—use opaque identifiers. And ensure that error messages don’t reveal implementation details like “SQL error: column ‘password’ not found.”

General information only. Consult your security team for specific compliance requirements.

7. When Not to Use a Formal Pre-Launch Checklist

As useful as a checklist is, it’s not always the right tool. For very small changes—like a typo fix or a minor CSS adjustment—a full seven-point review is overkill. Use judgment: if the change affects user experience or data, run the checklist; if it’s cosmetic or behind-the-scenes, a quick peer review may suffice.

Rapid experiments and prototypes

If you’re shipping a prototype to validate a hypothesis with a small group of users, a formal checklist might slow you down. In those cases, focus on interaction model and error states, and skip performance and security reviews until you have a validated concept. The key is to be explicit about the risk: label the feature as “experimental” in the UI and set expectations with users.

When the team is already overloaded

If your team is in crunch mode, adding a checklist might feel like another burden. In that situation, prioritize the checks that have the highest impact: accessibility and error states. Those are the ones that affect real users most directly. You can automate parts of the checklist—like accessibility scans and performance budgets—to reduce manual effort.

Finally, remember that a checklist is a guide, not a substitute for critical thinking. If something feels off but passes all checks, trust your instinct and investigate further. The goal is to ship with confidence, not to tick boxes.

Now, take this list, adapt it to your own product, and make it part of your launch ritual. Your future self—and your users—will thank you.