Design Thinking on Software Development
One of our most important roles is to help clients define and validate their ideas. We believe that Design Thinking’s short feedback loops help us to reach better products faster, while also saving money to our clients.
One of our biggest assets is that we are not just software developers, but also experts in UI/UX design. We have a naturally design-centric process since our beginning. But, there’s a difference between being design-orientated and Design Thinking, and recently, we’re moving toward the latter. What’s the benefit to this?
Adapting Design Thinking to our processes can save our clients and ourselves a lot of money.
The Old Model
Let’s look at how budgeting problems typically arise in a project. The traditional process goes like this:
Client has an idea → client/company draws up wireframes and works out features → company provides estimates → company makes design → client approves design → company makes product → tests run on product → company launches product for users.
At some point, the client or company may discover that a feature is far from original plans, or that something is missing. An inexperienced team will almost always make this mistake: but it can happen with experienced teams, and clear-cut projects. Worse yet, the company could deliver a product that doesn’t meet the expectations of the client, or the users.
Resolving these oversights comes with sometimes stressful back and forth talk, and unfortunately, someone ends up eating the cost.
So, what is Design Thinking?
Design Thinking is a concept in use since the 60s, promoted recently by ODEO, a design and consultancy firm. It’s also a formal line of study at Stanford University. Many big brand names, from IBM to Airbnb, have designers trained in Design Thinking to help them make new products.
Essentially, is a user-first approach with focus on rapid prototyping and feedback.
The steps are:
- Empathize with users in order to find out what they need.
- Define specific problems that the product will resolve.
- Ideate (just is a fancy word for brainstorming) to come up with possible solutions.
- Prototype the solution.
- Test the solution with users.
This process gets repetitions, until users feel the product solves their problem. However, it sometimes catches flack, because it’s rather theoretical and has a buzzword sheen that can turn people off. Not every company has the resources for a room full of experts, dreaming up the next big thing.
Making Design Thinking Agile
While we have known Design Thinking from a long time ago, we incorporate it into our processes after reading Sprint. This book, by Jake Knapp, provides a method for Design Sprints, easily adaptable to all companies. One of the keys between Design Sprints from Design Thinking, is putting a time limit of five days on the process. It emphasizes getting a prototype rolled out quickly over, and creating detailed user stories.
The idea of a design sprint is to create a feedback loop at the start of the development process. While you sometimes need to invest in this process, the point of it is to circumvent problems that can arise down the road from poorly developed ideas.
For example: Mandala, a new cryptocurrency exchange, hires us to design and build their platform frontend. We started by designing its dashboard, which not only features the complex data needed for exchanges, but also trading tools. An exchange with these tools doesn’t currently exist: so there’s no clear example on how to start. The traditional development model could have immersed ourselves into a complicated path.
We assemble a design sprint of less than a week, to nail down features and the look and feel of the dashboard. This lets us create a series of designs to be presented to the client. The first version is always rough, but has the potential to discuss what is working and what is missing. With every increase in definition, we fully define the functionalities of the dashboard.
This initial feedback loop acts as a discovery period for a product. It allows us to focus on users, and not just the client’s initial assumptions. Also, it lets us discover if the product presents problems that the client might not have considered, before the product building starts. 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.