Background

This company develops enterprise insurance software, and had an existing suite of highly successful on-premise hosted admin and web applications, both internal and consumer-facing. With this project, the company wanted to develop a next-generation SaaS product aimed at providing cutting-edge digital experiences, enabling new capabilities for insurers and new possibilities for the consumer. I was the design lead for the first journeys to be built - quote-and-buy, account management and claims. Though this section is purely about the Design Planning efforts for this project, I also worked on the Service Design, research and front-end design.

Following the initial Service Design piece, where strategy was formulated based on initial research and some "big design up front", as Design Lead I wanted to make sure that the good start we had made in user-centered design wouldn't be squandered. My fear would be that all of the good work done would be at best used at the start, then quickly forgotten, or at worst shelved straight away as priorities shifted. I needed to make sure that design had a voice. I needed to make sure that the case was made for continued research and design activities, not just UI work. I needed to make the case in language that Product Management understood. Most importantly, I needed to underline the value that these activities would bring.

What I Did

As the initial research and Service Design piece drew to a close, I began work on writing a document that aimed at codifying the design practice for this SaaS product on an ongoing basis. The audience was to be management initially (for buy-in), then the greater Product Management team, design and development community at large. My intention was that it would not only be a primer and ongoing reference for designers, but also for product managers and developers, so they could understand the overarching design ethos and how its design activities mapped to delivery, all the way from product planning down to individual sprints.

In writing this design planning document I looked at the standard product management processes/phases in the company and in an effort to make design more understandable, mapped design activities and artifacts to them. By doing this, and by describing the value of each artifact at every phase, I was able to cogently explain the importance of design, making it more tangible to people who were coming from more of an engineering background.

In a separate section of the document I descibed how my thinking on design could be encorporated into "nuts-and-bolts" development and delivery in Scrum sprint cycles. There are many existing schools of thought as to how this is best done, however these are mainly predicated on "author's own" experience in a specific context. Lean UX comes closest to describing a modern end-to-end approach to design in an agile delivery model. Unfortunately, it assumes a "well-oiled machine" in terms of cadence. As we were a brand-new team, working on a brand-new product, on a brand-new tech stack, with a brand-new design-led approach, we couldn't exactly descibe ourselves as seasoned. My recommended approach to design leaned towards Desirée Sy's Agile User-Centered Design model, with some aspects of Lean UX taken and adapted for our own needs.

What Were The Outcomes?

The document and models described within it were received very well. Some of the engineering folk were initially "surprised" at the scope, as it covered aspects of development delivery models, but nonetheless were supportive of the ideas and glad that something had been produced that was tailored to the project.

The design planning document ultimately became "canon" for design in project delivery. Some of my colleagues and peers even suggested that I should expand on the themes and publish a book(!); see "author's own" comment above...