The right approach for your project depends on your goals and constraints.
Explore
When I start a new project, I explore its domain with both a user focus and a market focus. What are the problems and processes that define your product? What trends are shaping the boundaries of its domain? My primary goal during this phase is to discover questions that cut through assumptions, expose and analyze risk, and most importantly, reveal your project’s actual requirements and constraints.
Design
Content and data are fundamental to my design process. Before pixels hit the screen, the concepts, systems and processes that underlie the project need to be captured and translated into user stories and design problems. Copy needs to be written. Data dependencies need to be documented. Tradeoffs need to be discovered and prioritized.
After all that, I’ll sketch out ideas within a design system, progressing from an abstract catalog of base elements towards concrete layouts, components and features.
Build
Designs and specifications aren’t infallible. They frequently require changes during the course development. Identifying all functional and nonfunctional requirements before development begins is nearly impossible. Because of this, my approach to building software products is adaptive.
Starting with a narrow slice of the specification, I build a working application that satisfies that subset of requirements. As the product is built, its requirements are extended and changed as needed, adapting to unforeseen constraints and opportunities.
Iterate
Software is never finished, but projects end. They’re measured against business goals and user expectations. Deliverables, dates and budgets. The tail end of a project is an ideal time to empirically validate any assumptions we’ve made about your product and its place in the world. Experience gained during the design and development phases of the project, and insights gleaned from customers in the field, should inform future efforts.
See the world as it is, and ask a smarter question.