View the original post
Being self aware, typically includes the ability to look to our past experiences, independently of their outcomes, and learn valuable lessons from them. Design Processes, with all its different milestones, moving parts (and participants) and stepping stones, is no different. Design Processes when systematically adopted in an Organization tend to mature, refine themselves, and become more efficient. That of course, comes only at the expense of understanding where the process worked out, where it failed, and where improvements can occur. This prophylactic mechanism of diagnosing and taking measures to prevent fallacies and inaccuracies is something that Designers and their teams should get into the cadence of doing, typically alongside their partners in the process. Retrospectives are far more familiar and well known with Development cycles, since it allows for Development teams to understand where their focus was, how efficient their execution rates were, and so on. Design Retrospectives should be just as equally insightful, thorough and focused on identifying venues by which the Design Process itself can improve, becoming more inclusive, diverse, sustainable and scalable. Hopefully this article provides some good topics to reflect upon.
Crafting, Running, Documenting and Affecting Directions. Wikipedia defines Retrospective the following way: “A retrospective (from Latin retrospectare, “look back”), generally, is a look back at events that took place, or works that were produced, in the past.” In case you want to read about Agile Sprint Retrospectives, Atlassian has an interesting article on the topic, which can be read here. Design Retrospectives are in many ways, quite similar, in the sense that it contemplates different chapters that are part of the Design Process, while also identifying and diagnosing what was successful and less successful. Of course, and much like Sprint Retrospectives, there are actionable items to address, in order to further inform the process itself. Keeping these items in mind, here is a possible structure for how a Design Retrospective can be established, and also some operational considerations to keep in mind when tackling such initiatives.
Documenting and Preparing the Retrospective: there are quite a few software applications which have templates for Design Sprints, which can be tailored for Retrospectives (or the templates skewing heavily towards Development Sprint Retrospectives, can also be easily repurposed). Much like I described in one of my previous articles, specifically the one focused on remote Design Sessions, using applications such as Miro or Invision’s Freehand, is quite suitable for what is going to be documented in these sessions. In the illustration which supports this article, is a structure for what the Retrospective should encompass, and how to capture feedback from all the attendees. When it comes to attendees, the Design team who is shepherding the process should include the plethora and variety of co-pilots who are part of the project itself. This typically includes representatives from Product, Development, Customer Support, Sales, Marketing, and Stakeholders from different branches and levels of seniority. It’s fundamental that the audience crosses multiple teams and expertise levels, since the retrospective isn’t solely focused on the outputs of the process, but also on the quality of the process itself. Whatever information is gathered can and should impact how Design Processes are indeed tackled and finessed.
Running the Retrospective: the retrospective itself should always be run by a minimum of two people, from an operational and documentation standpoint. Having a two person team allows for the division of work to be more effective and for the documentation aspect of the session to be far more successful. Therefore, you should have a host who communicates, guides and provides clarification on any of the many aspects that comprises the retrospective, and someone who documents, organizes the materials that the attendees are crafting, while also supporting any questions that may appear during the session. This both works for in person and remote environments. Having a team of two Designers shepherding sessions such as these, enables data to be captured more efficiently, while also makes sure that none of the attendees feels ignored or just as concerning, unheard. Retrospectives are all about communication, unfiltered and focused on the project and process at hand.
As far as the structure of the retrospective itself is concerned, and as the illustration indicates, the board (or whatever support/media is used), should always have a brief instruction on how to use it, and should always be fairly simple and intuitive for any user. The goal is never to intimidate attendees from participating or making the process too complex. The structure of session, from a time management perspective, can be segmented in the following sequence: introduction, which essentially summarizes the intent of the session, educates how the session will work, illustrates who the participants are, and finally gives perspective on next steps (this should take no longer than 10 minutes). Voting, capturing data, which should be the following 50 minutes of the session. Per each chapter that is contemplated, and correspondingly voted and discussed/commented, allow for the attendees to provide whatever feedback they want to share, without interrupting or justifying anything. While the temptation to provide justifications may be there, refrain from doing so when people are providing feedback. Taking notes of what is discussed is fundamental, so that when the epilogue of the session is at bay, specifically when it comes to actionable items, that same feedback can be factored in. Actionable items, forward actions, which pertains to assessing the feedback provided, understanding where the room for improvement lies, and what are the effective actions to take in order to finesse the process and its outcomes.
The chapters which comprise the retrospective include Design, Implementation and Release phases. This will encapsulate most of the product journey, but it’s quite malleable to include any other phase that may be deemed relevant. Design includes topics such as Research, Workshops, Testing, Iterations and Definition, again all with the intent of capturing all the tasks, artifacts, iterations to name but a few items, that comprise this part of the process. As the illustration indicates, this can be quite granular, but it can also be fairly high level, depending on the scrutiny the team wants and is willing to go to. Implementation phase includes topics such as Handoffs and Q&A, which is meant to capture how the relationship with the development cycle is effectively implemented (or not). Finally the Release phase is all about how users and clients are relating to the solution, in terms of adoption, but also in terms of understanding possible friction, expectations, and continuous usage. Once all the votes and observations from all these phases are accounted for, and this is the time where the team members running the session can work collaboratively to synthesize everything that can be made into actionable items. This is the component that is documented in the final chapter illustrated in the board.
Actionable Dividends from the Retrospective: this is the component which can take many different shapes and forms of action. The retrospective may surface the need to integrate earlier validation points of contact with users, or may surface issues with metrics and analytics that are not as substantial as they should be. Independently of what the feedback is, the organizing team should categorize and label the outputs into topics that are sensical. These topics may influence the process is implemented the for next features or new products, but it’s nonetheless something that should be actionable. Once all these action items are understood by all, it’s important that this information is disseminated between the teams, making sure that the synthesizing of the retrospective is compiled in a document that is parsable and easy to digest (which can come in the format of a Keynote or an Invision Board). The retrospective documentation is just as important to the process, as all the phases for the buildout of the solution were. It’s a time for reflection, but also an opportunity to understand possible gaps that occurred and where those can be minimized going forward.
Influencing the Design Process. I’ve written quite a few articles on the Design Process itself. Some focused on Workshops, others focused on Empathy and the process itself, others more focused on Discoverability, but one common denominator to all these articles, is the essential fact that the process is what Design Teams make of it. There are of course fundamental pillars that should be observed, if indeed the solutions that are being crafted aim to pierce through the needs and expectations of users, but for the most part, Design Processes should be flexible and adjust according to feedback, teams integration and assessment/understanding of the culture of the organization. One of the most interesting challenges a Designer and his team can be faced with, is not only to implement a process from the ground up in a somewhat barren terrain, but just as importantly, how to keep that process alive and thriving as products and features go through iterations, cycles and teams experience their own ebbs and flows.
Reality check. Not all organizations and teams have a habit of crafting Design Retrospectives. It’s an initiative that much like anything, requires time and organization, not only from the Design team, but also from the attendees who participate in the session. It is however, an initiative that forces people to reflect on what has happened, hopefully inviting them all to voice their aspirations and concerns in a forum specifically crafted to do so. It’s an opportunity for the teams to collectively have a moment of growth, and understand how they can better function as a whole, as opposed to an assembly of many individuals with varying skills. Hopefully it’s also a way to qualm frustrations, and actually enhance empathy and solidify relationships between teams.
I’ll conclude this article with a quote on the topic of self-reflection from Carl Jung:
“Knowing your own darkness is the best method for dealing with the darkness of other people.”