Front-End System Design: Functional Requirements

You just spent 45 minutes on a whiteboard meticulously drawing out the React component tree for a new, hypothetical dashboard. You've got your Redux slices defined, your custom hooks laid out, and even penciled in where the memo calls would go. Then the interviewer, bless their cotton socks, says, "Okay, great. Now, what exactly does this dashboard do?" Your heart sinks. You've just fallen into the oldest trap in a frontend system design interview: you designed the solution before fully understanding the problem.

This isn't about some fancy new framework or a clever algorithm; it's about the fundamentals. Before you even think about state management or server-side rendering, you need to nail down the functional requirements. This is where most candidates (and, frankly, many real-world projects) go sideways. You can build the most elegant, performant architecture, but if it doesn't meet the user's core needs, it's garbage. We're talking about the "what," not the "how."

The Silent Killer: Ambiguity

Think of the last time you built something where the requirements were fuzzy. Maybe "make it fast" or "make it user-friendly." These aren't requirements; they're aspirations. In an interview, ambiguity is your enemy. The interviewer is intentionally vague sometimes, waiting to see if you'll push back. They want to see you take control of the conversation, to drive clarity. If you don't ask clarifying questions about what the system does, you're building on quicksand.

Let's say they ask you to design an "e-commerce product page." Sounds simple, right? Wrong. An e-commerce product page for Amazon is vastly different from one for a small, niche artisan shop. Does it need real-time stock updates? Customer reviews with nested replies and image uploads? A "buy now" button that bypasses the cart? What about internationalization? Each of these questions drastically changes your technical approach. If you jump straight to "I'd use Next.js for SSR," you've already failed. You haven't even figured out what needs to be rendered, let alone how.

Eliciting Functional Requirements: Your Interview Superpower

This is where you earn your stripes. Don't wait for the interviewer to spoon-feed you every detail. You need to pull it out of them. Start broad, then narrow down. A good framework to keep in mind is asking "who, what, when, where, why, and how (high-level)" about the user's interaction with the system.

Begin by asking about the core users and their primary goals. For our e-commerce page: "Who are the primary users of this product page?" (Customers, maybe admin to edit product details). "What are their main goals when visiting this page?" (View product info, add to cart, read reviews, see related items).

Then, drill down into specific functionalities. "When a user views the product page, what information must be displayed?" (Product title, description, price, images). "Are there different states for a product, like 'out of stock' or 'pre-order'?" Each answer adds a brick to your foundation.

Prioritization is Key

You'll quickly find yourself with a long list of potential features. You can't build everything in 45 minutes. The interviewer doesn't expect you to. They want to see you identify the minimum viable product (MVP) from a functional standpoint. This shows product sense and an understanding of constraints.

Ask directly: "Given the time constraints, what are the absolute must-have features for the first version of this product page?" Or, "If we had to launch this in two weeks, what would be the core functionality we couldn't live without?" This forces a conversation about priority. You might get a list like:

1. Display product details: Name, description, price, main image.
2. Add to cart functionality: With quantity selection.
3. Basic stock indicator: "In Stock" or "Out of Stock."

Notice what's missing? Reviews, related products, advanced filtering. Those are great, but they're V2. By explicitly prioritizing, you're showing you can think like a product manager and an engineer. You're setting boundaries for your design.

Mapping Requirements to Interactions

Once you have a prioritized list, start thinking about user interactions. For each functional requirement, imagine the user journey.

• Display product details: User loads page -> sees info. Implies data fetching from a backend.
• Add to cart: User clicks "Add to Cart" -> item goes to cart, maybe a mini-cart updates, confirmation message appears. This implies client-side state management, an API call to add the item, and UI feedback.
• Basic stock indicator: User loads page -> sees status. Implies stock data is part of the product details fetched. What if they try to add an out-of-stock item? Error message.

This mapping helps bridge the gap between "what" and "how." You're still not designing the architecture, but you're laying the groundwork for it. You're identifying the key user flows that your system must support. Don't forget about edge cases: "What happens if the product image fails to load?" "What if the user tries to add 1000 items to the cart?" These aren't non-functional requirements yet; they're still about what the system does in specific scenarios.

Common Pitfalls and How to Avoid Them

The biggest trap, as I said, is jumping straight to technical solutions. Another common one is assuming too much. Never assume. If you're unsure if the page needs to be editable by an admin, ask. If you're wondering if users can upload images for reviews, ask. It's far better to ask "dumb" questions than to make incorrect assumptions that derail your entire design.

Also, avoid leading questions. Don't say, "So we'll use GraphQL for data fetching, right?" That's you designing, not eliciting. Instead, ask, "How frequently does product data change, and how critical is it for users to see the absolute latest information?" The answer to that question might lead you to GraphQL, but you didn't force it.

Finally, document your findings. Don't just keep these requirements in your head. Write them down on the whiteboard, ideally in a dedicated section. This shows organizational skills and gives you a reference point. If you later propose a solution, you can point back to a specific requirement it addresses. "My choice of client-side state management here directly supports the need for an immediate update to the cart icon without a page refresh, which we identified as crucial for user experience." See? You've connected the dots.

When to Stop Eliciting

This is a tricky one. You won't have infinite time. You've got maybe 10-15 minutes, tops, for functional requirements in a 45-minute interview. The goal isn't to get every possible requirement, but to get enough clarity to build a reasonable MVP.

You've got enough when:

1. You understand the core user personas and their primary goals.
2. You have a prioritized list of 3-5 absolute must-have features.
3. You've identified a few key user flows for these features.
4. You've clarified at least one or two crucial edge cases for these core features.

At this point, you should feel comfortable transitioning to non-functional requirements (performance, security, accessibility) and then, finally, to the actual technical design. Remember, this initial phase sets the stage for everything else. Get it right, and the rest of the interview becomes significantly easier. Miss it, and you'll spend the next 30 minutes trying to retrofit a solution to an undefined problem. This isn't just about passing an interview; it's about building good software.

Ready to Ace Your Next Interview?

Practice with AI-powered mock interviews tailored to your target role and company. Start Practicing for Free | Explore Interview Prep