The people in the portrait (a few caveats)
The portrait of the design and development process that I am painting in this book depicts the design (the product, system, service, component, upgrade etc. you are creating) in the middle of the process, not the user. Instead, the user along with many different roles, other users, inputs and influences surround the design. User-centered design is simply meant to ensure that users’ needs and feedback are incorporated iteratively throughout the process because presumably users are who the product must serve well to justify its existence. However, users don’t necessarily need to be placed in the center of a process diagram.
I suppose one could describe this portrait as “product-centric”, visually speaking, but the portrait of the Design UnProcess takes the form of a “wheel” only as a useful metaphor of a dynamic that is really about people more than product. My take on the term “product-centric” design is that it can have the potential risk of circumventing the needs of users and de-emphasizing real benefits for shipping more product, creating new versions, more sales… No matter what you call your process, prioritizing things, or money, over people doesn’t seem like a great idea. So, to be clear, this book is NOT about “product-centric” thinking, it is about how people make the process, and how they are connected.
As depicted, all of the roles we play are all on equal footing around the wheel. In the chaos and idiosyncrasies that can occur during development, the common ground we all share is “the design”. I could just as easily rename that hub called “the design” with something more ephemeral, like “the Outcomes”, “the Experience”, “the Quality”, “the Greater Good”, less dramatically, “the thing we’re all doing together right now.” The design focuses the connections between people, including end users, and serves as a vessel that grows, evolves, and takes form based on the mixture of needs and inputs from all those people. The fact that one or two roles might hold greater weight at any given point doesn’t necessarily equate to a value judgment in terms of the overall goal; big machines can break down because of small parts; the difference between a great dish and a good dish can be a small amount of an ingredient. Perhaps any of us involved in product development could benefit from thinking of all stakeholders as being on equal footing, in the sense that all are required (and dare I say, at all times) to succeed.
Let’s take an activity that should be inherently collaborative, like developing requirements. In the best cases, the requirements the designers and engineers will be working toward should not be created in a vacuum, nor will they be entirely static. Often requirements are a negotiation between stakeholders. Early user researchers or marketing might cite evidence for certain functionality, while developers might cite evidence that the engineering required to meet such a standard would create a product that users will find too expensive or complicated. Good requirements, like any other decision, require strong evidence that can clarify the impact a particular requirement will have. It stands to reason that the more evidence we collect, at the very least, the more confident we can be that, at the very least, we have exhausted all possible sources of insight to de-risk our decisions. Our teammates and the work they conduct provide that evidence.
Throughout the process, the dynamic between different roles and responsibilities will shift back and forth from those who are asking and those being asked; for their feedback, assistance, and insights. Those seeking information and insights will benefit from asking others and communicating more regularly, whereas those being asked might feel a greater sense of responsibility and commitment to the project. Generally, phase reviews will include sign off from major stakeholders, which implies important perspectives are not being ignored throughout the process. However, we can be lulled into only tapping those various stakeholders in a more or less serial fashion; getting certain people involved at certain parts of the process to employ their value. For example, it makes sense that engineer-time will represent more relative effort during the “engineering” phase of a device. But, if we extend this logic too far, perhaps in the pursuit of optimal efficiency, we might create a compartmentalization that eliminates the possibility for roles within the development process to not only interact regularly as checks and balances against one-sided assumptions, but also the possibility for roles to interact idiosyncratically and unpredictably. Would this be a bad thing? Yes, I believe it would. Over and over again I have witnessed unplanned insights and iterations that not only happen, but prove critical to the design direction, because communication and inclusion were leveraged (either by accident, or by planning opportunities for interaction). And, yes this can actually save time and money in the end too. In fact, why not assume by default that it could be beneficial to question the current status of any development effort at any time, from the perspective of any stakeholder? A “surprise” check-in by matter of course, rather than chance.
As mentioned in the preface to Part II, the roles and my take on them are not exhaustive or frankly objective. They are deliberately not meant to be user profiles or personas – you’re only ever one search or prompt away from such aggregated content anyway. They are meant to provide a clear marker, my stake in the ground based on my experience. You might find you plant your flag closer or further from it. Yes, “the design” is shown in the center, but the primary goal of the chapters in Part II is simple: to remind us that there is a common good in which so many valuable people are engaged. Seek them out, learn from them, work with them, understand the connections they have to you and the design and vice versa.
I’ve tried to do it, I’ll keep trying.