Mistakes that weaken a system design

01Building before agreeing on the problem

A news feed might mean reading posts, publishing them, or moderating them. These require different permissions, data flows, and failure handling. Confirm the main user journey and two or three constraints before drawing components. Explicitly exclude features you will not cover, such as recommendation algorithms or video uploads.

02Drawing boxes without responsibilities

A diagram containing React, a database, and a CDN says little about how the application works. Give each box a responsibility. The server decides visibility and ranking; the data layer fetches and caches records; the feed controls ordering and pagination; individual cards render posts. Trace one action through these boundaries.

• Identify who owns each fact: a draft belongs to the composer; a published post belongs to the server.
• Keep ordered post IDs separate from reusable records when the same post appears in several views.
• Choose technologies after these responsibilities are clear. A library name does not explain a consistency policy.

03Defining an API that only works once

“Fetch the posts” omits the decisions that shape the UI: page size, ordering, a continuation cursor, permissions, and errors. Define a sample request and response. Explain whether newly inserted posts can cause duplicate or skipped results, and how the client deduplicates records by stable ID.

For writes, describe validation errors and conflicts separately from outages. A timed-out submission may already have succeeded. Agree on an idempotency contract before automatically replaying it; optimistic UI also needs reconciliation or rollback.

04Treating every response as current

In autocomplete, the response for “ca” may arrive after the response for “cat”. Debouncing requests does not solve this race. Cancel superseded work with an AbortController where possible, and check request identity before accepting a result. Include filters, locale, and account scope in the cache identity.

05Promising speed without a bottleneck

“Use memoization everywhere” is not a performance strategy. Describe the slow path, how to measure it, and the smallest useful intervention. A large hero image, repeated network requests, and expensive list rendering need different fixes. Server rendering can help discoverable content, but it does not remove the cost of client-side interaction.

• Reserve image dimensions to prevent layout movement; serve appropriately sized assets.
• Split optional features from the initial route instead of loading every editor or chart immediately.
• Virtualize a large list only when its rendering cost justifies the complexity; preserve focus, scroll restoration, and access to off-screen items.

06Adding accessibility after the design

A clickable suggestion list is incomplete if keyboard users cannot select a result or assistive technology cannot identify the selected option. Start with native controls, then specify roles and keyboard behavior for custom widgets. Plan where focus goes when a panel opens, closes, or disappears.

Also test narrow screens, zoom, long translated labels, and right-to-left layouts. Format dates and currencies for the user's locale. A polished desktop screenshot is only one state of the product.

07Confusing UI restrictions with security

Hiding an Edit button does not prevent an unauthorized request. The server must check access to the specific resource on every operation. Keep private service keys on the server. Render user text safely; if rich HTML is required, sanitize it with a maintained sanitizer rather than bypassing framework protections.

Treat cache and telemetry as part of the privacy design. Do not put account-specific responses in shared caches. Clear account-scoped client data on logout, and avoid collecting message bodies, tokens, or private search terms in diagnostics.

08Designing only the successful request

A user can lose connectivity halfway through an action. Preserve their draft, show what is pending, and offer a safe retry. Offline writes need an explicit conflict and replay policy; a background queue is not proof of delivery. For real-time updates, discuss disconnects, duplicate events, missed events, and reconnect recovery.

• Test slow and out-of-order responses, expired sessions, duplicate submissions, and authorization failures.
• Measure API failures and action completion by route and release; attach a correlation ID without exposing private content.
• Keep a usable fallback when an optional live connection or third-party service fails.

09Losing the thread of the discussion

Explain the main design before spending ten minutes on one widget. When proposing polling, server-sent events, or WebSockets, compare them against the required freshness and interaction direction. Name the extra connection management your choice introduces. Use an unfamiliar term only if you can explain its mechanism and relevance.