In our group project we had to play both architect and builder. First, we wrote a design document for another team to implement. That sounded simple until we realized we couldn’t test our ideas, so every class diagram, API, and edge case had to be crystal clear without code to prove it. Then we switched roles and implemented a different group’s design. That was tough in a new way: student-written specs can be incomplete, ambiguous, or optimistic, and we had to fill gaps, reconcile assumptions, and ask lots of clarifying questions. The experience taught us that good design is more than boxes and arrows. It’s concrete examples, clear contracts, traceable requirements, and empathy for the next team. When in doubt: over-communicate, add test cases, and document decisions.