Right-Sized Framework™

Chapter 7 · Design

Design the Solution — From Concepts to CDR

Turn intent into schematics, code, and confidence — fast, modular, and documented.

Step InsideTake the AssessmentJump to ReferencesRSF Framers Community
Engineering design phase — concepts becoming structured schematics and buildable specifications.

Step Inside

Design is where intent turns into schematics, code, and confidence.

Design is where intent turns into schematics, code, and confidence. Lean on the three allies: Speed (decide, test, learn), Interaction (people and interfaces), and Documentation (capture decisions) — momentum without sacrificing rigor.

Let simplicity lead. The cautionary tale that opens this chapter contrasts Washington's Springfield "mixing bowl" — a $676M monument to over-engineering — with Atlanta's coherent five-level stack that untangled the same problem for a fraction of the cost. Newton's line holds: truth is found in simplicity, not in the multiplicity of things.

Lock interfaces early and evolve behind them. Sony's Walkman turned a stable core into a platform: 150 million units sold, a new model every ~7 weeks. The secret wasn't constant reinvention — it was a protected core with narrow, explicit interfaces that let teams move fast without stepping on each other.

Prototype to reduce risk and build momentum. Dropbox's 2007 demo video took its waitlist from 5,000 to 75,000 overnight — without shipping a line of production code. The prototype proved the concept and created pull. Build the version that answers the hardest question first.

Keep a living document tree and decision log so learning compounds and decisions stay traceable. Run disciplined PDR/CDR — scheduled early, with entry and exit criteria, not as a last-minute scramble. Favor off-the-shelf first: if you can buy it, do so. And remember: you'll never feel ready. Schedule the review anyway.

"Many decisions are reversible, so go fast… being slow is fatal." — Jeff Bezos

Action Plan

Design with Intent and Purpose

Four steps to get started

  1. Get Agile.
    If you haven't yet, adopt an Agile rhythm for your team. Invest in training, skilled coaching, and visible tracking tools. Agile isn't just trendy; it's essential for a high-performing knowledge workforce. Check out resources at the RSF Framers Community.
  2. Schedule your next PDR or CDR today.
    Put it on the calendar with clear ownership. Download presentation templates at the RSF Framers Community and circulate early drafts for input. You'll get more feedback than you expect — that's a good thing!
  3. Request an N² and document tree.
    Ask your Chief Engineer for a current N² (interface matrix) and a visual document tree that indicates each document's status: undocumented, partial, or complete. Review progress weekly; accountability sharpens execution.
  4. Celebrate wins, learn from stumbles.
    Design phases are hard work. After each major milestone or review, pause to celebrate as a team. Hold a quick retrospective: what went well, what can be improved. Then carry that learning forward. Extra credit: call out weekly wins at the start of your staff meeting. Watch what happens — it's magic.
Design action plan — structured steps moving from concept through PDR and CDR to a buildable solution.
Modularity and standard interfaces make rapid iteration possible
The little black dress — a timeless example of simplicity and sophistication in design.
The little black dress — the ultimate in simplicity and sophistication. Strive for the same in your designs.

Directed Tools and Templates

Design smarter, not harder.

The design phase runs on three hubs. Agile Hub keeps the team in a productive rhythm. SE Hub holds your PDR/CDR templates, N² matrix, and document tree. Design Hub covers modularity, prototyping checklists, and interface control.

Self-Assessment

Design-Phase Health Check

The design phase is where intent becomes a buildable product — or where risk quietly gets postponed to the build. This scores the six disciplines of a right-sized design phase separately, so you can see which is carrying the work and which is putting it at risk. Answer honestly; it's a mirror, not a report card.

1 = Never true · 2 = Rarely · 3 = Sometimes · 4 = Often · 5 = Consistently — answer honestly. This is a mirror, not a report card.

Design Velocity & Decisiveness Total possible: 20

1. We move fast on reversible decisions instead of waiting for perfect information (act on ~70% and correct quickly).

2. We keep discovery alive during design — learning from customers, suppliers, and competitors every week.

3. Design choices loop back to test discovery assumptions, and fresh insights flow forward into execution.

4. We refuse to let decisions linger; indecision isn't allowed to erode momentum or invite scope drift.

Modularity & Interface Control Total possible: 20

5. We lock the contracts and vary the implementations — narrow, explicit interfaces with modules evolving behind them.

6. Our ICDs define data formats, power, protocols, and physical connections, versioned against BOM/software releases.

7. We provide conformance tests and fixtures for every interface.

8. We map component interactions (e.g., an N² matrix) so integration is planned, not a firefight.

Prototyping & Simulation Total possible: 20

9. We build rapid prototypes (3D print, CNC, or software spikes) to test form, fit, and function early.

10. We run modeling and simulation in parallel to cut the number of physical iterations.

11. We use proof-of-concept tests as milestones to validate core functions.

12. We use prototypes to build momentum — making progress visible inside and generating excitement outside.

Knowledge Management & Configuration Control Total possible: 20

13. We keep source-of-truth records — design reports, decision logs, SOPs — in a searchable knowledge base.

14. We maintain a document tree showing each document's status (complete / in review / in progress).

15. We treat documentation as routine hygiene (e.g., a half-day every two weeks), not an end-loaded pre-review dump.

16. We enforce configuration control: managed baselines, version history, and role-based access.

Design Reviews: PDR & CDR Total possible: 20

17. We schedule PDR and CDR early — weeks or months out — with clear ownership.

18. Every review has explicit entry and exit criteria, shared from the start.

19. We run mini check-ins and pre-briefs so the big review is an expected evolution, not an ambush.

20. Review insights are captured, tracked, and fed back into the evolving design.

Agile Execution Total possible: 20

21. We work in short sprints that each produce tangible progress (a module, prototype, or clarified interface).

22. We hold short daily standups and keep a clear, prioritized backlog.

23. We break big work into manageable user stories and keep work visible for critique.

24. We make PDR/CDR deliverables visible in the sprint backlog, and we invest in real Agile coaching.

References & Further Study

Go Deeper

  • book
    The Toyota Product Development System

    Morgan & Liker

  • book
    Product Design for Manufacture and Assembly

    Boothroyd, Dewhurst & Knight

  • book
    Accelerate

    Forsgren, Humble & Kim

  • article
    NASA Systems Engineering Handbook
  • article
    McKinsey — How Agile can help in hardware and software development
  • article
    MIT OpenCourseWare — Design for Manufacture
  • video
    Manufacturing Happy Hour (podcast)
  • video
    Hardware to Save a Planet (Synapse podcast)