Design is not just a phase!

One thing I hear quite often is that companies are currently in the “design phase” of their new software project. Yesterday was one of those times. In this stage a company has hired a designer to help them map the user journey, create a service design concept and design the UI for their new product and they’ll ask for a quote when they’re ready to start the development.

This scenario worries me pretty much every time I run into it. Well, for one, I’m probably a bit frustrated they didn’t ask me to do the design work – it’s my bread and butter, after all. But nevertheless, whenever I hear someone working on a “design phase”, I start to worry that the designer of that phase will not be involved in the development process and that the client assumes designs are done after the phase. This sort of thinking assumes that the designer has had all the required knowledge, including technical knowledge to foresee any possible issues that might arise during the development process. And hey, not every service designer even knows what a web UI is supposed to look like. I’ve had to do huge UI overhauls for clients where the designer has not been aware of technical constraits or conventions of the web. Usually this is a result of the client having different expectations from the designer: the designer is working on a concept, while the client is expecting that what they’ve seen is the final design. And don’t get me wrong, I think concept work can be very valuable for exploring ideas, but too often the requirements of a concept vs. a final design are misunderstood when moving on to the development phase.

And this misunderstanding is what worries me. When we have a “design phase” for a software project, where you have a designer working on the problem with the business and the stakeholders, the project team should be aware that the designs made in the “design phase” are not the final product. The initial designs are just a tool to communicate the problem and the hypothesis of the solution to the stakeholders and the development team. The designer’s job doesn’t end with a design phase, because design should be continuous throughout the project as giving the designs a form makes it possible to explore the problem and the solution in a physical space (or, I guess in the case of digital products, in a digital space).

The designer should continue to be involved in the project and keep iterating as the development progresses and new information comes in. This is also why the development team should be involved in the design process as early as possible. As the first version of custom-made software should be made to validate the hypotheses made by the business, and scoped accordingly, the development team’s job is to be efficient in proving that the product is worth the investment as early as possible. If we commit to building the product as it is initially designed, the project will most likely fail, because we are focusing on unproven assumptions. You can’t say “that’s how we designed it” when the product doesn’t work – you redesign it (or kill it).

It always surprises me that while Eric Ries’ Lean Startup gets mentioned a lot, and next week I’m probably gonna hear people talking about his Build-Measure-Learn cycle at Slush (yet again…), the idea of validating the hypothesis and iterating based on feedback is not as common as you’d think. While it warms my heart to see companies investing in design, as it shows some level of maturity in their product development process, there’s still work to be done for companies learning how to utilize design efficiently by integrating it more closely with their software development process and teamwork.