How Design Thinking saves software development cash
How we use Design Thinking at Capicua to make better software, faster
As a software development agency with both software and design teams, our process has always been naturally design centric. One of our biggest assets is that we are not just software developers but also experts in UI/UX design. But there’s a difference between being design orientated and using Design Thinking, and recently we’ve been moving toward the latter.
What’s the benefit to this?
We’ve discovered that adapting Design Thinking to our process can save our clients and ourselves a lot of money.
Let’s look at how budgeting problems typically arise in a project. The traditional process for software development goes like this:
Client has idea • client/software company draws up wireframes and works out details of features • company provides estimates • design is made • client approves design • product gets made • product is tested • product is released for users
At some point in this process the client or company will discover that a feature hasn’t been properly thought through or that something is missing. An inexperienced team will almost always make this mistake, but it can still happen with experienced teams and seemingly clear-cut projects. Worse yet, the software company could deliver a product that doesn’t meet the expectations of the client or the users.
Resolving such oversights involves stressful back-and-forth between the client and the company, and unfortunately someone ends up eating the cost.
Design Thinking is a concept that has been in use since the 60s but has recently been promoted by ODEO, a design and consultancy firm, and at the Stanford d.school as a formal line of study. Many big brand names, from IBM to Airbnb, have hired designers trained in Design Thinking to help make new products.
Design thinking is essentially a user-first approach that focuses on rapid prototyping and feedback. The steps are:
1) Empathize with users in order to find out what they need
2) Define specific problems that the product will resolve
3) Ideate (which is a fancy word for brainstorming) to come up with possible solutions
4) Prototype the solution
5) Test the solution with users
Then this process is repeated until users feel the product solves their problem.
Design Thinking sometimes catches flack because it is rather theoretical and has a buzzword sheen that can turn people off. And not every company has resources like IBM that can be spent on a room full of experts dreaming up the next big thing.
Making Design Thinking Agile
We had been aware about Design Thinking but didn’t think about how to incorporate it into our process until we came across Jake Knapp’s book, Sprint. The book provides a method for Design Sprints, a process that can be easily adapted to companies of any size. One of the key features that differentiates Design Sprints from Design Thinking is that it puts a time limit of five days on the process. In emphasizes getting a prototype rolled out quickly over, say, creating detailed user stories.
Remember the traditional development process we looked at before? This is how the Design Sprint is envisioned in contrast:
The idea of a Design Sprint is to create a feedback loop at the start of the development process. While some time needs to be invested in this process, the point of it is to circumvent problems that can arise down the road from poorly developed ideas.
To take a real life example: Mandala is a new cryptocurrency exchange that contracted us to design and build the frontend of their platform. We started with the design of their dashboard, which would not only feature the complex data needed for an exchange, but would also include trading tools. An exchange with these tools doesn’t exist on the market so we didn’t have a clear example for how to design the dashboard. Following the traditional development model could have lead us down a complicated path.
Taking inspiration from Design Sprints, we decided to do a design sprint of less than a week to nail down the features and look of the dashboard. This entailed creating a series of designs that would be presented to the client. We started with a very rough version and presented it to the client, which got the discussion started about what was working and what was missing. The versions increased in definition until we had fully defined the functionalities of the dashboard.
Conclusion
This initial feedback loop acts as a discovery period for a product. It allows us to focus on what will be needed by users and not just the client’s initial assumptions. Also, seeing the product presents problems the client might not have considered, before the product starts being built.
Most importantly, this process decreases risk. With the clearest idea possible about the product, we can provide an estimate to our client that is accurate and fair.
Capicua is a full-cycle UX design and software development agency. Visit us to find out how we make software better.
Originally published at www.wearecapicua.com on December 21, 2018.