Anybody that is working on software engineering, software development and/or agile methodologies, will be very interested in the ideas from the Design Driven Development (D3) website.
The premise they start with is that the design of any system is an accident that kicks in at conception. Hence, maximizing the opportunities to make that accidents happen is the key for (product) innovation.
Thereto, the author(s) define procedures and practices on how to integrate design in your iterative product life cycle. D3 makes the clear distinction between the management, engineering and design aspects of product development. Most current agile practices focus on the former aspects, whereas D3 introduces the latter by integrating design games into the project iteration, nl. at the start of the sprints, where the design games can provide input to the product backlogs.
D3 turns the design practices into set of games, which brings different sets of people, skills and experiences together to make design decisions in a collaborative way. D3 describes 11 different design games, which are grouped into five different categories: Startup, Understand, Question, Design and Experience.
But first and foremost, D3 is about focusing on the solution and not the problem. D3 can be as simple as the hilarious example laid out in their blog.
D3 defines 4 fundamental elements of good design:
- Innovation is larger level breakthrough in solving the indented problem
- Interaction is about how software or products behave with the users
- Information is how you arrange the different elements on the screen
- Intelligence focus on little things which can change the usability of an application.
In this way, D3 tries to bring design to the higher level of the solution space, whereas design used to remain at the product’s code and/or architecture level. The solution is the boundary where the product ends and thus where you as a solution builder can have impact. The higher levels of business and life on the other hand need to be impacted by other means.
D3 also recognizes that no process can guarantee a better design. Creating the right environment with the right set of people is the only way to bring innovation and design. Guidelines to this are laid out in the Design Cube, which defines the people, culture and environment aspects which can greatly contribute to build an innovative organization.
The ideas laid out in the D3 approach seem to be very viable. However, they have to be tested into practice to prove if they do bring enough value to the solution development in the form of product innovation. Most certainly, more practical guidelines, best practices, procedures and tools will have to be defined.
I do have some projects on my radar that might be helped by incorporating the ideas of D3. But in the mean time, does anyone have any practical experience with the D3 or other principles on entailing product innovation in solution development?