Brief Considerations on Design Topics: 12. Problem Definition

Working in the Design field is a constant humbling journey. While some professionals in this field may fall under the illusion that they master the practice or understand all of its details, the truth of the fact is, Design as a Discipline is only sensical when complimented by other disciplines. More so, Design is only sensical when it’s ultimately serving a problem that needs to be solved, and creating a solution that needs to be used by someone (a user). All this to say: there is indeed an inherent level of knowledge and skill that Designers need to have in order to be efficient and successful in their endeavors. However the illusion that Design in itself trumps everything else, is a myopic and problematic viewpoint which people and professionals in the field should really eradicate. This type of behavior also applies to professionals in other fields, who courtesy of all the momentum surrounding the democratization of Design Thinking methodologies and processes, married with Human Computer Interaction theories, suddenly firmly believe they have all the necessary skills in order to be Design centric, without actually leveraging professionals of the field, or for that matter, crafting any actual solutions that are indeed Design driven. This type of behavior in itself also reveals a myopic perspective which should also be eradicated, since it largely assumes that Design centric methodologies are driven by formulas where everyone gets to play a reduced part, minimizing the scope of Designers contributions to artifact builders and Developers to code pushers.

The whole goal for Design centric methodologies has been to bring focus into crafting solutions for users in a systematic manner, testing frequently, iterating, considering perspectives such as innovation, usefulness, understandability, honesty (to name but a few Design principles). However the focus on all of these qualities is only sensical if married with a democratic sharing of the process itself, where Designers, Product Ownership, Customer Support, Go to Market, Marketing, Development teams (to name but a few), all get a chance to participate and co-own the process itself. While Designers can and should be the catalysts for this process, reducing these journeys to a single perspective in the end produces warped solutions which eventually have to be reconsidered because they ultimately don’t truly pierce the crux of the problem. The process and typically the journey for problem solving starts with understanding and documenting the Problem Statement itself and unveiling of Opportunities tied with that same problem. I’ve written about this process here, however when it comes to Problem Definition specifically, there’s quite a few things to keep in mind that Designers should always remember when they’re tackling a problem and starting the process itself.

Where do I start — who gets to jumpstart the process is always a source of contention (and sometimes friction). There are multiple sources of information and departments themselves which can jumpstart a problem solving process. There’s scenarios where Product Ownership starts the process, based on information gathered from Business Stakeholders or from Leadership, there’s scenarios where Customer Support documents issues that clients are repeatedly voicing, and that in itself jumpstarts the need for a problem solving exercise. Designers can also jumpstart this process by documenting what they’re gathering, observing and witnessing from their research (from Voice of the Customer engagements for instance, from metrics they’re capturing, from usability testing sessions they perform). All this to say, while the genesis of the process can stem from different sources, it nonetheless should be firstly reviewed against the Organization’s priorities, product focus, resources availability, funding, before even embarking on considering applying a Design centric methodology/process to it.

Whose lane is it — I’ve also written about the topic of cannibalization of functions when it comes to Design centric processes. However when jumpstarting a process is always best for the different stakeholders from Product, Design, Go to Market, Customer Support, Development, Marketing to seek alignment on what the strategy should be (and also outline the timelines in which they hope to have the process worked through). Designers should have a clear, unbiased and shareable view of the structure of how the process will be documented and structured, so that everyone understands what information is needed, and what operational endeavors will be required (and by operational endeavors I actually mean different types of research, workshops, synthesis endeavors). This stepping stone is fundamental since it will also provide insight into internal (and possible external) stakeholders who need to a part of the process, and potential information gaps that need to be solved for, all of which need to be accounted for in the process itself and that are essential for an effective problem statement and definition phase.

Document all the details — In the first article I referred above, there’s an illustration of a format/standard I’ve been using throughout the years, when it comes to going through a Design process (the 4 quadrants process). However even before jumping into the first quadrant, which is all about Problem statement and Opportunity unveiling, there’s always a need to compile information which allows for the participants of the process to have a common ground or common denominator of information which in turn enables them to become well versed enough in the topic (or at least gives them the means to ask the right questions which sets them on the right path for it). Which means, there is indeed tasks to be performed which sustain the process even before the process itself starts. Product Ownership, Design, and all the other departments in the process, should always account for data and information that provides additional context for the creation of the problem statement. The problem statement itself as mentioned in the first point, can come from multiple sources, but the more succinctly documented it turns out to be, the more efficient it will become for all the participants in the process to be onboarded, understand context, and eventually distill the actual problem, while in the process also uncovering business opportunities.

Humanize it — problem statements are only as good as how much they effectively reveal the pain points that are being felt by users. A large component of this problem solving statement is understanding who is at the core of the problem, and who will benefit from its solution (aside from the Organization delivering the solution itself of course). While doing this pre-work which will support the first quadrant of the process, it’s important to start to preemptively outline the characters who will be the target of this endeavor.

When everything is somewhat murky and unclear, it’s always fair to be reminded of the principles of Human Computer interaction: understanding and addressing the core problem, being people centered, using an activity centered systems approach and finally, rapid iterations of prototyping and testing. Understanding and Addressing the Core problem is not only the first chapter in the process, it’s also where the original seed is planted, where the foundational grounds for the process start. As the process continues and further information is unveiled, and the solution is tested, iterated upon, more layers are added to that possible solution, but at its core, what indeed is being solved for, always harks back to chapter 1 and the fundamental core problem that was identified, clarified and documented.

American industrialist Henry J. Kaiser stated:
“Problems are only opportunities in work clothes.”