Reading :: Design Thinking in Technical Communication

Design Thinking in Technical Communication: Solving Problems through Making and Collaborating

By Jason Tham

I’ve been aware of Jason Tham’s work for some time — he publishes on the Design Thinking (DT) methodology in technical communication (TC) journals, and I spoke with him briefly at a conference last summer. Seems like a great guy. And part of what makes him a great guy is that he is deeply interested in solving human problems, which is what this book is about: using DT to improve people’s lives.

The book is relatively slim, at 130pp. plus end matter. And its aim is — well, to me, the aim is a little unclear. The brief description at the beginning (and on Amazon) says it’s “essential reading for instructors, students, and practitioners of technical communication, and can be used as a supplemental text for graduate and undergraduate courses in usability and user-centered design and research.” At the end of each chapter are learning activities, suitable for classrooms, demonstrating ways to take up chapter principles. But the chapters themselves don’t seem oriented to enacting principles; they largely describe principles from an academic standpoint (with lots of citations) and give example cases (which tend to be big-picture rather than granular). For instance, by the end of Chapter 3, “Social Innovation,” I had a good idea of why empathy mapping and journey mapping were a good idea, but I didn’t have any concrete visual examples of either one, nor did I know what steps I should take to create these. My impression is that it would indeed have to serve as a “supplemental text” in a class, one that bridges more concrete DT materials with the concerns of technical communication.

Still, I wanted more connective tissue. For instance, Chapter 2 delves into makerspaces, surveying three makerspaces within TC programs. But makerspaces are not necessarily connected with DT: you can certainly do DT in a makerspace, but you can also use different design approaches or no formal approach whatsoever. I wanted a bit more guidance so that I could understand how the two relate. Here, and throughout the book, I had the sense that for Tham, the connections were obvious — perhaps he easily describes the connections when teaching this material to his classes. But those connections are only hinted at here.

Pulling back, the book as a whole attempts to provide a grand vision of what DT can do for TC. To be clear, I am on board with the broad sweep of this vision: Technical communicators need to both understand the working lives of the people we serve and work with those people to codesign support. That support can’t just be descriptive or instructional: it must account for individuals’ and groups’ workflow, objectives, and values if it is to be used and useful. To understand how information is taken up in a social system such as a workplace, we’ve got to develop it to account for social dynamics and to keep it flexible enough that it can adapt as these social systems change. I think that this is a big part of Tham’s vision.

However, sometimes the line between elucidating current DT practice and advocating for a DT direction is blurry. In one example, on p.71, Tham portrays DT in a Venn diagram, as the overlap between social innovation and social justice. Yes, DT can certainly be deployed that way — and Tham is welcome to advocate for that deployment. But DT does not inherently map onto social justice! When IDEO pulled together DT principles, they indeed characterized themselves as addressing user needs, but in the context of selling products that would work successfully. There’s no inherent DT orientation to social justice per se — one could easily use DT principles to redesign the interface for the Truth Social app, an app whose users would likely scoff at the idea of social justice! 

Another example that jumped out at me is how Tham characterizes early Scandinavian participatory design work: “this participatory design approach aims to be non-selective and invites anyone who are interested in co-designing products and services to participate in the design process” (p.7). No: Scandinavian PD made a point of co-designing with union representatives, who functioned explicitly as political representatives for the users in their union. It wasn’t until PD jumped to the US, with its generally weak unions, that practitioners turned to functional representatives (i.e., everyday, average users). That is, he’s reading later US-based PD orientation back into the history of earlier Scandinavian PD. 

I bring these up, not because I like to nitpick, but because I think it’s really important to understand the different political interests involved in developing methods and methodologies. Absolutely one can advocate for DT being deployed in service of social justice — but to make that happen, one has to think through whose interests have been embedded in current methods and how to redeploy those methods for different interests when necessary. For instance, when you construct an empathy map or a journey map for a user, you’re being compelled to have empathy for them or envision the journey they (want to) take, so you can build a product for those needs. DT doesn’t have an embedded step in which you take stock of those needs and understand how or whether they align with your own values or a broader social justice agenda. It doesn’t stop you from designing an interface for Truth Social or the Proud Boys. To make that social justice work happen, one would have to modify DT further and figure out how to keep realigning to those external standards. It’s not going to just emerge by following the process.

Still, with that caveat, this book does a good job of elaborating on a vision for DT for TC, and I can see using it for a classroom or working team, in concert with more detailed how-to materials. If you’re interested in DT, or design more generally, definitely check it out.