The Software Development Lifecycle (SDLC) is often presented linearly: Idea, Strategy, Plan, Development, Launch, Enhance and Sunset. But we know that sequence is a grand over-simplification. In his talk, Frishberg describes a more nuanced approach to the SDLC in which Product, UX and Technology participate iteratively and in ways that may just as likely move "backward" in the SDLC as forward. Frishberg applies Design Thinking frameworks to illustrate a Product/UX game plan that his team uses at The Home Depot Quote Center. In presenting the SDLC through the lens of four "Mega-plays" you will see how to drive robust engagements with your teams, your stakeholders and your customers to discover, define, design and deliver solutions that matter.

1

Thank you all for coming in tonight. One minor correction: I’m still technically Sr Mgr of UX at QuoteCenter, but in name only. My position was eliminated in early October. As of now, I’m open to new opportunities.

2

Soon after I started at QuoteCenter, the Sr Mgr of Product Management and I were puzzled by a lack of alignment by our teams. PM complained that UX took too long to complete its research. Devs complained that PM’s provided solutions, not problems. Devs and PMs were concerned about a lack of consistency from UX. As a result, we discussed putting a playbook together that would help everyone understand what each discipline could expect from the other. In the past couple of months my team had a breakthrough in building the UX playbook, which I hope you’ll appreciate, as I have, as an interesting and provocative approach.

3

Raise your hand if you disagree with the statement Okay – so we’re all agreed that PM must be attuned to multiple disciplines to be successful. But there’s a fundamental problem here. The frameworks and models PM uses to drive a product from requirements definition to launch are fundamentally different from those used by engineering and UX. In brief, the very things PM needs to get done are not framed the same way as dev and UX frame their things. This has been a struggle for me as a UX leader. How can we all collaborate when we’re not striving for the same objectives or metrics. In the past few months, however, my team has had a breakthrough, and I hope you’ll appreciate it as much as I and our stakeholders have. My hope is that by the end of this presentation, you’ll benefit from thinking about how to PM, Dev and UX can collaborate together better, ultimately leading to improved outcomes for your company. We’ll start with a quick review of the fundamental frameworks used by Product, Dev and UX.

4

Hopefully many of you are familiar with Pragmatic Marketing’s framework. The bright green center illustrates a linear progression from market research through post-delivery support.

5

Whether represented as a stack, a circle or an infinite cycle, the SDLC is generally represented as a similar progression, from Planning through post-release “Maintenance.”

6

In the Design Thinking model from Nielsen Norman Group shown here, something different is going on. Empathize, Ideate--and while it appears to be linear, things are going backwards! And looping!

7

Or in this rendition of IDEO’s Design Thinking framework Inspiration. Ideation. With notions of “divergence” and “convergence” – with lots of introspection. It’s a roller coaster!

8

The LUMA model illustrates movement among the phases of Looking/Learning, Understanding and Making And while time is laid out horizontally, moving from left to right, the work actually being done moves up and down, shifting as the circumstances require

9

In the UK Design Council’s Double-Diamond Diagram, there appears to be a linear progression – perhaps there’s a way to line this one up with the Pragmatic Institute’s framework, but here again, the diagram is describing the divergence / convergence cycle as much as it is moving “forward.”

10

And here, the Owen/Kumar/Sato circular diagram from the ID-IIT. Once again, words like “Discover, Define, Design, Deliver” with ideas of “knowing” and “reflecting” Designers move through this cycle as frequently as once per hour – it’s how designers work and think.

11

It’s pretty difficult to map these wildly different models. Not only do the activities and outcomes differ dramatically, but there are (as I like to say) structural differences between what the design thinking models are describing and what PM/Dev are trying to do operationally. UX relies on Design Thinking frameworks because they are a good fit. Designers think like….well, designers. But more importantly, design thinking generates results that are remarkably different from approaches that are more incremental. In brief, the process of switching between divergent and convergent modes actually generates better outcomes regardless of the scale or type of problem.

12

13

The design thinking crowd have been struggling with this problem for a few years. Consider Dan Nessler’s version of the UK Design Council’s Double Diamond Diagram to illustrate the “structural” problem I’m concerned about. Okay. It’s an eye chart.. But look at the little diamond in the front of the two larger diamonds. What’s going on there?

14

Here’s a simpler version – and almost every design thinking UXer wants to do this. Diamonds within diamonds. What does this actually mean? It means, that even as we’re trying to diverge, think creatively, find alternative points of view (left side of larger diamonds), we may need to do some pruning, testing, hypothesizing/testing, simply to continue moving divergently. And vice versa, when we’re just trying to converge on a specific idea, we may need to do micro-divergences in the form of workshops, brainstorming and the like. So, the Design Thinking models aren’t very good at describing what we really do –in the design thinking discipline we know the actual work is far more fluid than any of the diagrams can describe. Yet we also know that DT truly does lead to better product outcomes. How can we put all of the different ways of working together so we have a fighting chance of leveraging the best from each discipline?

15

Here’s our attempt at resolving the mapping problem. It starts out with the Double Diamond diagram. We think that best describes a linear flow through the SDLC while still accounting for divergent and convergent thinking. The left diamond is where strategy is identified – are we addressing the right problem? The right side is execution – are we building the solution in the right way?

16

We added a flow-chart into the diamond. This begins to look like a game – and that’s our intention – it’s UX’s proposed game plan. Here’s a game board. Now, it looks like a diamond in a diamond diagram, mostly because we used a flow chart symbol (the black diamond) to represent a branch or decision node. Still, the choice was intentional. Who says diagrams can’t be ironic? If every decision is answered with “yes” then the teams move through the game from idea to execution. Hurray! This is the SDLC and the Pragmatic framework – a nice linear, step-wise process through the diamonds.

17

But what if the answers are “No?” This is the breakthrough my team came up with. Rather than trying to put diamonds inside diamonds and so forth, they propose that if we can’t move through the decision branch, we drop out of the larger double diamond into one of four possible “Mega-plays.” Each Mega-play constitutes a separate design thinking cycle in and of itself. Here we can go backwards, try stuff out, diverge/converge – all the design thinking things, without impacting the overall game board.

18

And, once we exit a Mega-play we re-enter the gameboard and proceed. It combines three different models into a coherent system that address all stakeholder concerns: Product concerns – identifying pervasive, potentially profitable problems to solve Dev concerns – receiving decomposed rationalized epics, stories and acceptance criteria UX concerns – converting validated problems into desirable experiences It keeps a linear progression (time moves from left to right) as the idea first appears, the problem is validated, the concept is crafted and then subsequently decomposed into chunks (epics) and user stories and deliverables. It allows for retrograde motion (the dotted line arrows that go backwards) only when the key questions being asked are answered “no.” It allows the product definition/delivery process to proceed, even as it allows for embedded design thinking cycles to occur. Let me give you a quick example of how we address the “Problem Validation” Mega-play Let’s say you’ve tripped over a problem – it’s come to your attention, you see it in the data, your competitor has revealed a weakness in your strategy. However you encountered the problem, it’s yours to deal with. You hit the first black diamond: is it clearly defined? We have a lot of questions that need to be answered to qualify a problem as clearly defined. If the problem fails to pass those tests, you drop out of the main sequence into the Problem Validation Mega-Play

19

Here’s one way the UX team at HDQC might approach the Problem Validation Mega-play. We’ve illustrated the design thinking model as a variant of the LUMA swimlanes – Discover, Define, Design and Deliver represented as the horizontal lines Across the top are mini-milestones in the project plan – Initial problem statement, Data review, Final Problem statement and so forth Each of the saturated squares represents a UX “micro-play” specific tools we use to address the milestone. In this example, we started with a Gap Analysis – what do we already know about the targeted users so that we can identify what additional research we may need to do. Presumptive Design is an interesting micro-play we use frequently. In this example, we illustrate that Presumptive Design requires many supporting engagements, some of which go into other swimlanes – for example, while PrD is very much a Discover activity, to get it done requires activities in Define and Design. This way of illustrating the Mega-play resolves the confusion around diamonds within diamonds – the team is allowed to work both divergently (Discover / Design) activities and convergently (Define) even though we’re firmly in the context of the left side of the left-hand diamond (ostensibly a divergent activity).

20

21

22

23

24

25

26