I explain Design as the act of defining a solution. First, I plan how a product or system will look. Then, I plan how it will function. Next, I plan how it will be structured. In software projects, I separate creative work from technical work. Creative work shapes look and feel. Technical work, or software design, shapes internal structure and architecture.
I use the twin peaks model to guide me. First, I capture general requirements for the complete system. Then, I define a preliminary system architecture that satisfies those requirements. After that, I refine the architecture. Meanwhile, I update requirements for subsystems. Thus, I balance problem view and solution view. Therefore, I iterate between requirements and design until I reach a stable solution.
I make design decisions at several points. For example, I select a style of architecture. Moreover, I set constraints such as platform limits and performance targets. Consequently, I ensure that each decision meets the constraints. In addition, I check how choices affect requirements. For instance, I might change subsystem requirements after I choose an architecture.
I classify design work across system levels. First, I consider the total system. Next, I decompose into subsystems. Then, I specify software requirements on a lower level. Accordingly, I refine the initial system design into detailed designs. Meanwhile, I keep the overall goals in mind. Thus, I ensure consistency across levels.
I apply different methods depending on the goal. For creative work, I use user research, sketches, and prototypes; for technical work, I use architecture patterns, interface definitions, and detailed models; and for example, I use Design Thinking to explore alternative solutions early. Furthermore, I run workshops to gather user insights. As a result, I generate ideas that can become requirements or product features.
I pay close attention to constraints. First, I document constraints that affect the design. Then, I evaluate trade-offs. Also, I involve stakeholders early and often. Therefore, I reduce risks and clarify priorities. In addition, I record design rationale. Thus, I justify decisions for future reviews.
I link design models with requirements models. First, I map requirement items to solution elements. Then, I refine both models in parallel. Moreover, I verify that these models satisfy requirements. If not, I change the solution or the requirements. Accordingly, I maintain traceability between requirements and design artifacts.
I focus on clarity. For that reason, I write short and concrete specifications. Also, I use diagrams to show structure and interaction. Next, I create prototypes to validate ideas. Finally, I test the design with users and developers. Consequently, I learn quickly and improve the solution.
In short, I view Design as a structured, iterative activity. First, I shape the problem. Then, I craft the solution. Moreover, I balance creative and technical aspects. Therefore, I ensure that the final product meets requirements, fits constraints, and delivers value.