Iterating And Refining - Learning Module

Loading content...

0/246

Feedback Incorporation

The Catalyst for Design Evolution

If iteration is the engine of design improvement, feedback is the fuel. Without external input, your iterations are powered only by your own perspective—a perspective that, no matter how experienced, has blind spots.

The best designers actively seek feedback from multiple sources, evaluate it systematically, and incorporate it thoughtfully. They understand that feedback isn't criticism to defend against but information that accelerates learning and improves outcomes.

This page explores the art and science of feedback incorporation—a skill that distinguishes good designers from great ones.

What You Will Learn

By the end of this page, you will understand where valuable feedback comes from, how to evaluate feedback without emotional reaction, and how to incorporate feedback systematically into your design process. You'll learn to treat feedback as a design accelerant rather than a threat.

Sources of Design Feedback

Design feedback comes from multiple sources, each offering different perspectives and value. Understanding these sources helps you proactively seek the right kind of feedback at the right time.

The Feedback Ecosystem:

Think of design feedback as coming from concentric circles, each with distinct characteristics:

Sources of Design Feedback
Source	What They See	Value They Provide	When to Seek
Yourself (Self-Review)	Internal consistency, completeness, obvious issues	First-pass quality control, catches obvious mistakes	Immediately after drafting, before showing others
Peers / Fellow Engineers	Technical details, implementation concerns, code-level issues	Practical feasibility, pattern recognition, alternative approaches	After self-review, during early design phase
Senior Engineers / Architects	Strategic fit, system-wide implications, non-obvious trade-offs	Experience-based insights, organizational context, long-term vision	After peer feedback, when design is taking shape
Product / Domain Experts	Business logic accuracy, use case coverage, domain subtleties	Requirements validation, edge case identification, priority guidance	Throughout design, especially for domain model validation
The Requirements Themselves	Gaps in understanding, ambiguities, missing constraints	Clarity on scope, boundary conditions, success criteria	Continuously—requirements are a dialogue, not a document
Future Maintainers (Imagined)	Clarity, documentation, cognitive load, onboarding difficulty	Simplicity pressure, documentation needs, team scalability	During documentation phase, when evaluating complexity

Self-Review: The First Feedback Loop

Before seeking external feedback, conduct a thorough self-review. This isn't just about catching typos—it's about engaging critically with your own work.

Effective self-review questions:

Self-Review Checklist

•"If I came back to this in 6 months, would I understand why each decision was made?"
•"Can I trace every class and method back to a specific requirement?"
•"What would break if I tried to add a likely future feature?"
•"Where am I hardcoding assumptions that might change?"
•"If I had to explain this to a junior developer, where would I struggle?"
•"What question would a skeptical senior engineer ask about this design?"

The Time Gap Technique

If time permits, let your design sit for a day before self-reviewing. Fresh eyes—even your own—catch issues that urgency blinds you to. This 'time gap' is one of the most effective self-review techniques available.

Peer Feedback: The Engineering Lens

Peer engineers provide a technical perspective that's invaluable for catching implementation concerns and identifying alternative approaches. They see your design through the lens of "how would I build this?"

What peers are good at catching:

Algorithm choices that have better alternatives
Data structure selections that don't match access patterns
Missing error handling or edge cases from engineering experience
Patterns they've seen work (or fail) in similar contexts
Testing concerns—"How would I unit test this class?"

What peers might miss:

Strategic or organizational fit
Business domain subtleties
Requirements that were never explicitly stated
Historical context for why things are done certain ways

Senior/Architect Feedback: The Strategic Lens

Senior engineers and architects bring experience that's hard to replicate. They've seen patterns succeed and fail across multiple projects and understand how local design decisions impact system-wide properties.

What senior engineers and architects are good at catching:

Designs that contradict established system patterns
Trade-offs that seem good locally but cause problems at scale
Missing non-functional requirements (security, observability, operability)
Over-engineering that adds cost without proportional benefit
Historical context—why something was tried before and failed

How to approach them:

Prepare a concise summary of your design and the key decisions you made
Explicitly ask about trade-offs: "What am I not seeing?"
Be open to the possibility that your approach is fundamentally misguided
Don't take directional feedback as personal criticism

Different Perspectives, Different Value

Each feedback source has strengths and blind spots. A peer might catch a testing issue that a senior architect wouldn't notice. A domain expert might identify a business logic flaw that no engineer would catch. Seek diverse feedback, not just convenient feedback.

Creating a Feedback-Friendly Environment

Getting valuable feedback isn't just about asking for it—it's about creating conditions where honest, useful feedback can emerge. This requires deliberate effort on your part.

The Feedback Paradox:

People are naturally reluctant to give negative feedback. They worry about hurting relationships, being wrong, or the effort of a potential conflict. As a result, the default feedback you receive will often be too positive—not because your design is perfect, but because people are being polite.

To get genuinely useful feedback, you need to actively work against this tendency.

Techniques for eliciting honest feedback:

Encouraging Genuine Feedback

•State your uncertainty first — "I'm not sure if this abstraction is right. What do you think?" Acknowledging your own doubts gives others permission to share theirs.
•Ask specific questions — "How would you add push notifications to this design?" is better than "What do you think?" Specific questions invite concrete answers.
•Explicitly invite criticism — "I want you to poke holes in this. Where would you attack this design?" This reframes criticism as helpful rather than adversarial.
•Thank them for challenges — When someone raises a concern, express genuine gratitude: "That's exactly the kind of issue I needed to hear." This trains them to be more forthcoming.
•Avoid defensiveness — If your first response to feedback is to explain why your design is right, people will stop giving feedback. Listen first, respond later.
•Present alternatives — "I'm considering approach A or approach B. What are the trade-offs you see?" This makes critique feel like collaboration rather than attack.

The Anti-Patterns of Seeking Feedback:

Just as there are good techniques, there are practices that shut down useful feedback:

Feedback Anti-Patterns
Anti-Pattern	Why It Fails	Better Approach
Presenting design as final	Implies feedback isn't welcome; decisions already made	Present as draft; emphasize you're seeking input
Getting defensive immediately	Punishes honest feedback; trains people to be vague	Thank them first; engage with the substance later
Asking only sympathetic reviewers	Creates echo chamber; misses critical issues	Seek out skeptics and people with different perspectives
Ignoring feedback visibly	Discourages future input; wastes reviewer's time	Acknowledge all feedback; explain what you adopted and why
Asking when too finished	Too late to change; feedback becomes frustrating	Seek feedback early, when changes are still easy
Overwhelming with detail	Reviewer can't identify what's important	Summarize key decisions; let them drill down if interested

Feedback Timing Matters

The earlier you seek feedback, the more valuable it is. Feedback on a sketch is easy to incorporate; feedback on a detailed design requires more rework. Don't polish before sharing—share early and often.

Evaluating Feedback Systematically

Not all feedback is created equal. Some is insightful and actionable; some is based on misunderstanding; some reflects personal preferences rather than objective quality. The skill lies in evaluating feedback systematically rather than reacting emotionally.

The Feedback Evaluation Framework:

When receiving feedback, process it through a structured filter:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// For each piece of feedback, evaluate across these dimensions:
 
interface FeedbackEvaluation {
    // 1. UNDERSTANDING
    // Does the reviewer understand the context correctly?
    correctContextualUnderstanding: boolean;
    clarificationNeeded: string[];
    
    // 2. VALIDITY
    // Is the concern technically valid?
    technicallyValid: boolean;
    evidenceProvided: string[];
    
    // 3. RELEVANCE
    // Does the concern apply to our constraints?
    relevantToOurContext: boolean;
    assumptionsMade: string[];
    
    // 4. SEVERITY
    // How important is this issue?
    severity: 'critical' | 'major' | 'minor' | 'nitpick';
    impactIfIgnored: string;
    
    // 5. ACTIONABILITY
    // Can we do something about it?
    actionable: boolean;
    suggestedAction: string;
    costToAddress: 'low' | 'medium' | 'high';
    
    // 6. DECISION
    decision: 'implement' | 'defer' | 'discuss further' | 'acknowledge but decline';
    rationale: string;
}

Let's walk through each dimension:

1. Understanding

First, check whether the reviewer understood the context correctly. Feedback based on misunderstanding isn't invalid—it indicates a communication problem—but the solution might be clarification rather than design change.

Example: "You should use a queue here instead of calling directly."

Check: Does the reviewer know about the latency requirements that make async processing unsuitable? If not, the feedback indicates you need to document your constraints better, not necessarily change the design.

2. Validity

Assume the reviewer understood correctly. Is the concern technically valid? Would the issue they describe actually occur?

This requires separating the technical claim from the suggested solution. A reviewer might correctly identify a problem but suggest an impractical solution. The problem identification is valid even if the solution isn't.

3. Relevance

Valid concerns might not be relevant to your specific context. A concern about handling 10 million users might not apply to an internal tool with 50 users. A concern about database deadlocks might not apply if your operations are read-only.

Be honest here—don't dismiss valid concerns as irrelevant just because addressing them is inconvenient.

4. Severity

For relevant, valid concerns, assess impact:

Critical: Would cause system failure, data corruption, or security vulnerability
Major: Would cause significant maintainability, performance, or correctness issues
Minor: Would cause small problems but is workable
Nitpick: Stylistic preference; reasonable people could disagree

5. Actionability

Can you actually address this concern given your constraints? Consider:

Time available for design
Scope boundaries you've been given
Technical feasibility
Whether addressing creates bigger problems

Some valid concerns are best documented as "known limitations" rather than addressed, especially when addressing them would introduce disproportionate complexity.

6. Decision

Based on your evaluation, decide:

Implement: The feedback is important enough to address now
Defer: Valid but not critical; document for future consideration
Discuss further: Need more information or stakeholder input
Acknowledge but decline: Understood but accepting the risk or trade-off

Document Your Rationale

For any feedback you don't implement, document why. This isn't defensiveness—it's creating a record of considered trade-offs. Six months from now, when someone raises the same concern, you can point to the documented reasoning rather than re-evaluating from scratch.

Responding to Feedback Professionally

How you respond to feedback affects both the current design process and your reputation as a collaborator. Professional response to feedback is a skill that compounds over time.

The First Response:

Whatever your internal reaction to feedback, your visible first response should be positive:

"Thanks for catching that." — Acknowledges effort and value
"I hadn't considered that angle." — Shows intellectual humility
"Let me dig into that concern." — Shows you take it seriously

Even if you ultimately disagree with the feedback, this initial response creates space for productive discussion.

The Middle: Engaging with Substance

After acknowledging the feedback, engage with its substance:

Engaging with Feedback Substance

•Ask clarifying questions — "When you say 'this won't scale,' what specific bottleneck are you concerned about?"
•Explore the concern — "Help me understand the scenario where this would fail."
•Share your reasoning — "I chose this approach because... does that change your assessment?"
•Propose alternatives — "What if we addressed that concern by doing X instead of your suggestion Y?"
•Acknowledge trade-offs — "You're right that this has limitation A, but I think it's worth accepting for benefit B."

The Closing: Confirming Resolution

Feedback discussions should have clear endings:

If implementing: "I'll update the design to address that. Thanks again for catching it."
If deferring: "I've documented this as a known limitation for now. Let's revisit if requirements change."
If declining: "I understand the concern. For this context, I'm accepting that trade-off because... Do you have further concerns?"

Handling Feedback You Disagree With:

Disagreement is healthy, but how you handle it matters:

Poor Responses

•"That's not how we do things here."
•"You don't understand the requirements."
•"That would take too long to change."
•"We've already decided on this approach."
•Silence / ignoring the feedback

Professional Responses

•"Our convention here is X because of Y context."
•"I may not have explained the requirements clearly. Let me clarify..."
•"Given time constraints, I'm accepting that risk. Here's why..."
•"I hear your concern. Can we document it as a future consideration?"
•Explicit acknowledgment even if not implementing

Your Reputation Compounds

How you handle feedback today affects what feedback you receive tomorrow. Engineers who respond professionally to criticism build reputations as collaborative designers—and receive more (and better) feedback. Those who respond defensively find their requests for review politely declined or answered with superficial praise.

Incorporating Feedback into Design

Once you've evaluated and accepted feedback, you need to incorporate it effectively into your design. This requires technique, especially when feedback suggests fundamental changes.

Levels of Feedback Incorporation:

Feedback can require changes at different levels of the design. Recognizing the level helps you scope the work:

Levels of Design Change
Level	Examples	Scope of Change	Approach
Surface	Naming, documentation, diagram clarity	Minimal, cosmetic	Quick fixes, no architectural impact
Local	Method signature, class responsibility detail	Single class or small cluster	Evaluate impact on immediate collaborators
Pattern	Strategy vs Template Method, Observer vs Callbacks	Multiple classes, relationship changes	Re-evaluate pattern applicability; may require restructuring
Structural	Entity model, core abstractions	Design-wide impact	May require significant rework; consider if scope allows
Foundational	Core assumptions about the problem	Complete redesign	Step back; question requirements understanding; restart if needed

Technique: Incremental Integration

When feedback requires substantial change, don't try to address it all at once. Use incremental integration:

Identify the minimum change that addresses the core concern
Apply that change and verify the design remains coherent
Assess whether additional changes are needed now that the first is in place
Repeat until the feedback is fully addressed

This approach prevents the common failure of over-reaching changes that introduce new problems while solving old ones.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
// Feedback: "Your OrderProcessor has too many responsibilities. 
// It handles validation, pricing, inventory, and notifications."
 
// WRONG: Try to fix everything at once
// This leads to rushed abstractions and new bugs
 
// RIGHT: Incremental integration
 
// Iteration 1: Extract validation (the clearest concern)
class OrderValidator {
    validate(order: Order): ValidationResult { /* ... */ }
}
 
class OrderProcessor {
    constructor(private validator: OrderValidator) {}
    
    process(order: Order): void {
        const validation = this.validator.validate(order);
        // ... rest stays the same for now
    }
}
 
// Iteration 2: Extract pricing (next clearest)
class PricingCalculator {
    calculate(items: OrderItem[], discounts: Discount[]): Price { /* ... */ }
}
 
// Iteration 3: Extract inventory
class InventoryReserver {
    reserve(items: OrderItem[]): ReservationResult { /* ... */ }
}
 
// Iteration 4: Extract notifications
class OrderNotifier {
    notifyOrderPlaced(order: Order): void { /* ... */ }
}
 
// Final: OrderProcessor orchestrates
class OrderProcessor {
    constructor(
        private validator: OrderValidator,
        private pricer: PricingCalculator,
        private inventory: InventoryReserver,
        private notifier: OrderNotifier
    ) {}
    
    process(order: Order): ProcessingResult {
        const validation = this.validator.validate(order);
        if (!validation.isValid) return ProcessingResult.failed(validation);
        
        const reservation = this.inventory.reserve(order.items);
        if (!reservation.success) return ProcessingResult.failed(reservation);
        
        const price = this.pricer.calculate(order.items, order.discounts);
        order.setFinalPrice(price);
        
        this.notifier.notifyOrderPlaced(order);
        return ProcessingResult.success(order);
    }
}

Tracking Feedback Incorporation:

For designs that receive substantial feedback, maintain a simple tracking document:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Design Feedback Log: Order Processing System
 
## Reviewed by: Sarah Chen (Senior Engineer) - 2024-01-15
 
| # | Feedback | Severity | Decision | Status | Notes |
|---|----------|----------|----------|--------|-------|
| 1 | OrderProcessor has too many responsibilities | Major | Implement | Done | Extracted 4 classes |
| 2 | Consider async for notifications | Minor | Defer | Documented | V2 if latency becomes issue |
| 3 | Missing retry logic for inventory | Major | Implement | Done | Added RetryableReserver |
| 4 | Naming: 'process' is too vague | Minor | Implement | Done | Renamed to 'submitOrder' |
 
## Reviewed by: Product Owner - 2024-01-16
 
| # | Feedback | Severity | Decision | Status | Notes |
|---|----------|----------|----------|--------|-------|
| 5 | Need to support partial orders | Major | Discuss | Pending | Clarifying with stakeholders |
| 6 | Gift orders need different flow | Major | Implement | In Progress | Adding OrderType abstraction |

This Log Becomes Documentation

Your feedback log is valuable design documentation. It shows future maintainers that the design was reviewed, what concerns were raised, and how they were addressed. This builds confidence in the design and prevents relitigating settled decisions.

Feedback in Interview Context

In LLD interviews, the interviewer's questions and comments are feedback. How you receive and incorporate that feedback is a major part of what's being evaluated.

Interview Feedback Patterns:

Interviewers provide feedback in various forms, each requiring a different response:

Types of Interview Feedback

•Direct improvement suggestions — "Have you considered using a Strategy pattern here?" Acknowledge, evaluate openly, and if it's a good idea, incorporate it visibly.
•Probing questions — "What happens if two users try to book the same slot?" This implies a gap in your design. Acknowledge the scenario and show how you'd handle it.
•Changing requirements — "Now let's say we need to support group bookings." This tests your design's flexibility. Walk through how you'd extend it.
•Playing devil's advocate — "Why wouldn't you just use a simple array here?" They may not actually disagree; they're testing whether you can defend your decisions.
•Silence or neutral responses — If the interviewer says little, don't assume approval. Ask: "Does that approach address your concern, or should I elaborate?"

Demonstrating Feedback Receptiveness:

Good candidate behavior:

Pauses to genuinely consider suggestions before responding
Says "That's a good point, let me revise..." and actually revises
Asks clarifying questions when feedback is ambiguous
Visibly updates diagrams or notes when incorporating changes
Thanks the interviewer for helpful suggestions

Concerning candidate behavior:

Immediately explains why their original approach is right
Gets defensive or argumentative when challenged
Ignores suggestions and continues with original plan
Agrees superficially but doesn't actually change anything
Shows frustration when asked to revise

They're Testing Collaboration

Interviewers are simulating what it would be like to work with you. If you're defensive about feedback in a 45-minute interview, they'll assume you're defensive in day-to-day work. Being coachable is often as important as being correct.

When You Disagree with Interview Feedback:

Sometimes an interviewer's suggestion isn't actually better. You can respectfully disagree, but how you do it matters:

Acknowledge the merit: "I see why that approach is attractive because..."
Explain your concern: "My hesitation is that in our context, it would..."
Propose a compromise if possible: "What if we did a hybrid where...?"
Accept guidance if they insist: "I can see the reasoning. Let me revise to incorporate that."

Remember: the interviewer might be testing whether you can disagree professionally, or they might be testing whether you can follow guidance. Either way, being collaborative is correct.

Summary: Feedback as Design Fuel

Feedback incorporation is a skill that amplifies your design abilities. Let's consolidate the key insights:

Key Takeaways

•Multiple feedback sources provide different perspectives — Self-review, peers, seniors, and domain experts each see different aspects of your design.
•Create conditions for honest feedback — Ask specific questions, invite criticism explicitly, and thank people for challenges rather than getting defensive.
•Evaluate feedback systematically — Check understanding, validity, relevance, severity, and actionability before deciding how to respond.
•Respond professionally regardless of agreement — Your visible reaction affects both the current discussion and future willingness to give feedback.
•Incorporate changes incrementally — Large changes are best applied step by step to maintain design coherence.
•Track and document feedback — A feedback log becomes valuable design documentation.
•In interviews, feedback is the test — How you receive and incorporate interviewer input is as important as your initial design.

What's Next:

With iteration and feedback covered, we now turn to one of the most nuanced skills in design: making trade-off decisions. Every non-trivial design involves trade-offs between competing concerns. The next page explores how to recognize, evaluate, and decide on trade-offs with confidence.

Page Complete

You now understand how to gather, evaluate, and incorporate feedback systematically. This skill accelerates your growth as a designer by leveraging the perspectives of others. In the next page, we'll tackle the art of making explicit trade-off decisions.