Design Thinking for Software Quality Consultants

Software quality consultants tend to focus on the later phases of the software development pipeline. In particular, high-level and low-level design stages often have little input from quality assurance stakeholders. We are making some progress in the right direction, given the continued growth of Agile methodologies throughout the software industry. Nevertheless, heavy QA participation in system design is more the exception than the rule. As a result, QA consultants may have little exposure to design methodologies that could improve the results of QA initiatives. One such methodology is Design Thinking.

Stanford University is responsible for much of the development of Design Thinking. The methodology fits squarely within the larger trend of iterative/incremental business processes. However, the process is unique, in part due to its heavy focus on user empathy. In fact, “Empathize” is the first step of the Design Thinking process. Subsequent steps include “Define”, “Ideate”, “Prototype”, and “Test”. The methodology does not dictate a single linear pass through the stages. Rather, incremental, iterative, and parallel execution of the stages is often recommended. Knowledge of Design Thinking is useful for QA consultants, and consultants in general, because of its utility in effectively dealing with a project’s “soft factors” and implicit needs. QA consultants enjoy the fact that work often revolves around a concrete foundation of quantitative data. However, the qualitative factors, stakeholder management, and “soft” user needs cannot be ignored.

Quality systems always have an end customer, and a large list of stakeholders. The first step in any quality systems initiative is to understand who the customers and stakeholders are. Methodologies like Design Thinking can be employed to understand the true needs, preferences, and even quirks, of those those customers and stakeholders. The best technical implementation will provide no value if it fails to address real user needs.

One of the greatest barriers for realizing greater quality assurance value in organizations, in my opinion, is the lack of “ideation” in quality assurance system design. Take the example of a system for automated system testing of a software product. There are industry standards around the framework, structure, style, and supporting infrastructure for these systems. It may be all too tempting to copy existing precedent (a logical approach). However, given the diversity of end customers for quality systems, some iterative Ideation and Design Thinking can deliver great value. For example, some organizations may have a strong need for software accessibility feedback. When baked into the core of an automated testing system, this feature could provide tremendous value. Another example might be structuring the automated testing system around internationalization and localization concerns. In any case, you won’t know the path to maximize organizational value without a deep understanding of user needs. Design Thinking is one tool, of many, to effectively and efficiently determine these user needs.