Creating Better Software Through Design Thinking
Desgin isn't just for the starving UI designers anymore. Work with your testing and development teams to create apps that empathize with the user.
Join the DZone community and get the full member experience.Join For Free
If you haven’t heard of design thinking yet, odds are you will soon. Where business is concerned, design thinking is no longer something done just by the creatives of an organization, and it does not simply mean "build pixel-perfect wireframes." Design thinking is a holistic product design approach where every product touch point is an opportunity to delight and benefit our users.
For most of us, the word "design" serves up thoughts of iconic classics. The appeal of an architectural style (think: Craftsman) or the draw of a beautiful automobile (insert ride of choice!) While a car or home might be well designed from an aesthetic standpoint, they may not be well suited for the job they are built to do. Enter, design thinking.
Design thinking is a product design approach where thinking like a user is the methodology, and user satisfaction is the goal. Part of the broader human-centered design approach, design thinking is more than cross-functional; it is an interdisciplinary and empathetic understanding of our user’s needs. Design thinking sits right up there with Agile software development, business process management, and customer relationship management. It’s a real business term and a practice that supports innovation and successful product development.
To really employ a design thinking approach you must practice radical empathy. Let’s take the example of automobile design. If you were asked to design a mid-sized sedan what features would you put in it? Does it need to have a V8 engine if its primary function is to tote kids to soccer practice or would we be better served making sure the backseat is roomy and the seats fold down easily? If we ask ourselves similar questions in software testing, we can see how design thinking will focus on the needs of the user, rather than the requirements of the project.
A Brief History of Design Thinking
Design Thinking is a methodology made famous by David Kelley, founder of global design company IDEO and Stanford University’s School of Design. Design thinking applies a hands-on, user-centered approach to solving a "problem" through a 5-step process: Empathize, Define, Ideate, Iterate, Test.
The design thinking ideology asserts this user-centered approach to problem-solving can lead to innovation, and innovation can lead to differentiation and a competitive advantage. Design thinking has elevated some very well-known companies to iconic success, like Apple. In 1980, this fast-growing start-up was one of Kelley’s initial clients. The result? A device called a "mouse" that we can use to interface with our PC. Kelley applied the 5-step process to understanding user needs (a better way to navigate) to innovate a solution that revolutionized computing.
Design Thinking in Quality Assurance
Earlier I wrote that design thinking is an interdisciplinary methodology. Design thinking is a collaborative process for all stakeholders, not just the creatives. One way to maximize this ideology is by integrating your test team early in the product design process. After all, these are the people who spend countless hours in a variety of software environments. If anyone can feel a user’s pain, a tester can!
1. Empathize With the User
Who are my users, and what are they trying to do? What limitations, expectations, and hopes do they have for my product? Asking the right questions helps your team solve the right problems. Here, utilize your testers knowledge to think ahead to where possible user pain points will occur.
2. Define User Needs
Use discoveries from the Empathize stage to define user needs. Then, go one step further and think about how these needs will be addressed in the problem to be solved. This is a great place to utilize a test team’s expertise. They know where problems usually arise and can provide key insights during product development.
Consider alternative solutions. A lot of them! This is the "widening" stage where the field of possible solutions is increased. Hold a design studio where each stakeholder draws their solution to the problem, then share and discuss. It’s a fast, collaborative way to generate innovative solutions!
In traditional software testing, changing the design in response to feedback usually carries the negative label of “reworking.” Design thinking tosses this idea, and instead focuses on combining and iterating the best ideas that came from ideation. This paradigm shift enables your testers to engage to their full potential as software experts, rather than simply "bug reporters."
Recreate the scenario in which your users are most likely to be interfacing with your product. This allows you to learn more about interactions or disruptions between the user, the prototype, and the environment, as well as how problems might arise because of that interaction. Remember, you’re testing the product, not the interface. Resist the urge to correct your user if they misinterpret how to use your product. Instead, ask “Why?” and “How did this make you feel?” User feedback is a valuable learning experience.
Failing Forward – Design Thinking in Software Testing
In software testing, the design thinking approach views the traditional quality assurance discovery of failures as part of a larger creative effort and reduces defensive mental blocks. No longer is iteration seen as negative "rework," but rather broad ideation and creative investigation of user feedback leads to innovative solutions. Instead of development and QA being at odds with one another, they are players on the same team, working towards creating the best possible product for the end user. Every defect found is a chance to make the software better and to further delight the user.
As with everything digital, customer empathy generates business value. Use the design thinking guidelines above to put yourself in your user’s shoes and create truly useful software.
Published at DZone with permission of Sarah Koch. See the original article here.
Opinions expressed by DZone contributors are their own.