Stop Sprinting; Start Designing!

Paul Eisen at UXDX Community: EMEA Series: Design Process. Video: https://youtu.be/CB1OTRRLPlo

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Cutting corners in the spirit of rapid delivery

[00:00:00] The theme of high change is going to come out quite prominently in this talk. I wanted to start by acknowledging that there's been quite a lot of evolution in UX practices in the past couple of decades: the mainstream popularity of design thinking. We have much better integration of our creative and our structural and analytic design disciplines to create holistic user experiences. And we have more powerful and efficient tools, particularly for rapid prototyping and for user feedback, so that we can learn faster.

[00:00:40] Then, most importantly, relative to the topic of rapid change and high change, we've moved into models that [?] super large delivery, and what we're focused on is providing incremental functionality to provide incremental value to end users. All of that's on the bright side. There's going to be a but coming here. As Indira Gandhi cautioned, popularity is not a guarantee of quality.

[00:01:18] Unfortunately, what I've seen in many of the organizations that I've been working with over the past decade in particular is that we're starting to cut corners. In the spirit of rapid deployment of functionality, we are now focused more on incremental delivery, and what I'm noticing is that we're often missing one very critical step in the design process, and that is the high-level design, which establishes the foundations of your design.

An urban planning analogy: London and Toronto

[00:01:56] Before I get into the details of my thoughts around that, I wanted to sidestep to an analogy in the urban planning domain. This is a map of part of London. London epitomizes organic growth. The street architecture has evolved from a cluster of villages and townships. There's actually been little, if any, deliberate macro-level city planning of the street architecture. As a result, this might suit the use case or usage scenario of a tourist wandering aimlessly, looking to come upon surprises and delight. However, for what is typically considered a very important primary usage scenario in navigating cities, efficient transportation of goods and people, London unfortunately fails.

[00:02:54] I'm going to contrast this with the urban grid, or other simple geometric structures such as hub and spoke. We're looking here at a historical map of the city of Toronto. That's my hometown, by the way. It was planned as an urban grid back in the late 19th century. What we're doing here is setting up very simple, understandable and efficient structures for roads and the associated infrastructure of utilities, et cetera, that enable a larger extension of the city to be planned without filling in all the details in the neighborhoods and districts.

[00:03:45] As Toronto has grown over the years, this model could be extended without introducing new conceptual ideas, and so the navigability of the city, notwithstanding the traffic, has been really effective. I'm going to jump now back into the domain of digital products, where we recognize that in addition to finding things, there are all kinds of other sophisticated ways of interacting with digital products, and they too require planning for ease of extendability and effectiveness.

What the popular design process models leave out

[00:04:24] I'm going to talk a little bit about that. I want to look at a sampling of the general design processes that we use to communicate with our clients, to communicate amongst ourselves and with our employers, the various stakeholders who are involved. Design thinking, as we're now recognizing, is becoming more prominent. It's being accepted into many of the organizations in which we work. It really starts with establishing an understanding of the problem space through the empathy and experience research that we conduct, to extract insights that then allow us to formulate a strategy, in the form of design principles or an experience strategy. There are a number of ways we can essentially say: here's what the solution has to do to be effective and to meet the experience outcomes that we understand are important to our end-user community, and the business outcomes.

[00:05:29] I'm going to start walking through some models of this. The point I want to make is that among these models that we use to guide our own design thinking, there is no attention paid to the importance of planning or architecting the design before we step into the details of design. That's caused some bad behaviors. One of the bad behaviors I've seen is that most of our project plans don't include a stage where we actually take the time to create the design architecture, or this high-level design.

[00:06:07] This is the genesis of the Double Diamond. The UK Design Council introduced it as a framework for innovation. I can't say enough about how important this is for introducing human-centered thinking and empathy and so forth. However, we aren't handed any guidance in this particular model about how to go about design in a rigorous way that's going to protect us over time as we release individual features and functionality. You can see some of the items that are communicated here. There's no detail.

[00:06:49] If I get into a slightly more detailed representation of the Double Diamond model, you can see now that we have ideate and prototype. Ideation is always a great thing: opening up the aperture and considering lateral ideas. Prototyping, I have a concern with as guidance. Prototyping, to me, is a technique that can be used across the entire design process. I've seen it used effectively in executing foundational research, as a point of stimulus in order to open up the lens and understand users' needs, and in other parts along the process as well. So we need to be a bit more specific here.

[00:07:29] This is another more detailed view of the design thinking process that was posted by Dan Nessler, and it talks about test and analyze as well. Again, ideate, prototype: this is the general guidance around how we arrive at effective designs. I'm going to turn attention now from the Double Diamond model to the five-step linear process that was introduced by the Stanford design school. Again we have ideate, prototype and test. There is some guidance around idea generation, about brainstorming and so forth, and there's some guidance around the tools and philosophy of prototyping. Again, there's really no attention paid to the importance of establishing a foundation of design before you get into the details.

[00:08:13] This is another globally recognized thought leader in the interaction design and experience design space, the Interaction Design Foundation. Here the model talks about tests to create new ideas and about prototypes sparking a new idea. I feel like we're trivializing what has to happen in this design space, and I don't think it does us a service, and I don't think it does a service to our clients. As I'm talking to you, I know I'm preaching to the converted in this conversation. It's really a call to action: it behooves us to be a bit more deliberate in defining what actually has to happen to get this right.

[00:08:55] This is the Nielsen Norman model, another globally respected organization in the user experience space. Here the guidance for ideation is to generate a range of crazy, creative ideas, and then in prototyping we build real, tactile representations for a range of ideas. Again, I worry that this is a bit misleading and doesn't respect the rigor of the design process. Imagine urban planners if that was their brief: "We just need you to create a range of crazy, creative ideas for this city." There would probably be a great range of circuses and symphonies, but are we really going to identify the structure of the city that is going to be able to support the key use cases?

[00:09:50] This is the roller coaster model, based on IDEO. Different model, same conclusion. And another model, looking at how we integrate agile and experience design, in this Lead Us [?] model, and again there's no specific guidance here. So I think I can effectively say that none of these models differentiates a foundational level of design.

Designing for change with a North Star design

[00:10:20] As a result, what are we doing? We're doing what feels right, what's worked in the past. We go where our skills, knowledge and talents inspire us. And in the spirit of rapid deployment and sprint-based execution, we're often accommodating the push for delivery and sacrificing the importance of stopping and creating this design foundation. I've referred to this as high-level design; that's how it's broadly described. We think of it in other terms as well: conceptual design, experience architecture. At Blink we refer to this as a North Star design, or a design vision. Whatever you call it, this is a call to action that we need to pay more attention to it.

[00:11:06] Why is it important? Reiterating: we're in a world of delivering software products and platforms in increments. Incremental functionality is released to provide incremental value, and in that world change is a necessity. We are designing change, and therefore we need to design for change. I propose that the way to design for change, to ensure that it's graceful change rather than disruptive change, is to start with a North Star design.

[00:11:38] The overall goal of this North Star design is to create the conditions where you're minimizing the impact of change, at least the negative impact, on all of our stakeholders. Let's start with our colleagues: our business and product owners, the development team and the design team. For us to be able to manage change and minimize churn, we would like to have a stable and robust platform and foundation, as makes sense, to the extent that we're able to project into the future and understand the usage of the platform and the product.

[00:12:13] Now let's go, of course, to the most important player in the game, which is the end users. We talk about the psychology of change aversion, and we have to recognize that people aren't necessarily averse to change. They're averse to destruction and disruption that they don't understand the value of. Here again I feel the importance of the foundational design, in robustness and minimizing disruption. Jared Spool of User Interface Engineering has a great term for this from the user perspective: he refers to it as embraceable change. He's got a great article up on his site, interesting [?] to read.

[00:12:58] To summarize, the purpose of the North Star design is to minimize the impact of change on all stakeholders. As I see it, a North Star design, a foundational or high-level design, has to have the following attributes to do a good job of this. One is scalability. We need to anticipate into the future so that our architecture doesn't get disrupted. This is of course what our technical architects are doing as well. They're looking at various aspects of the technology stack, from data management and application management and all the integrations, and various other aspects of the platform from a technology perspective. These are not decisions that are being made as functionality is being released during our sprints. These are decisions that are being made prior to, or up to, sprint zero, and we need to be doing the same thing.

[00:13:56] Optimization is another key here. All of the guidance that we've seen so far is about coming up with a bunch of crazy ideas and then trying some out: picking the ones that, based on our experience, we think are most promising, trying them out, getting some feedback. I'm going to make an analogy, and I don't want to make this disparaging, but it reminds me of the infinite monkey theorem. That's when theoretical mathematicians postulated that, given enough time, a thousand monkeys on typewriters could reproduce the entire works of William Shakespeare.

[00:14:27] Again, it's a bit of an extreme analogy, but the point is what we're saying our process needs to be: come up with some great ideas, throw them at the wall and see which ones stick, and that's the iterative user feedback we'll get on it. I'm proposing that we never have enough time. The monkeys might have infinite time, but we are always under time constraints, and within those time constraints we need to choose our areas of focus very wisely. So not only am I saying we need to focus on those aspects of the high-level design that ensure scalability and graceful change, but we also need to not sweat the details. We need to know what we can defer until later.

[00:15:13] The last point here is that we end up getting early buy-in, so that again we avoid the churn of introducing something structural or really foundational that ends up disrupting our own internal development process.

Where the North Star design fits in the process

[00:15:31] So I've talked about why I think it's important and how it is not so well represented right now. The question is, where does this happen, and what does it include? I believe we need to modify this five-step process. First of all, we talk about test as a step at the end, and I think all of us have mature processes where we know we're not going to wait until the end to test. What we're going to do is iterate, test and revise as we move along. That's one adjustment that I propose to this five-step model.

[00:16:15] The next adjustment is that we're not prototyping per se. We are creating a North Star design, or a high-level design. After the ideation, and all of the opportunity for lateral thinking has flowed through whoever is able to come up with creative ideas, the design team needs to establish the foundations of the design, and that needs to happen prior to the detailed design. Here's how I then map this onto our agile process: just like the technical design, this North Star design needs to happen in sprint zero, validated through end-user feedback. This is how the approach would appear in the Double Diamond model.

Interaction model and high-level information architecture

[00:16:58] So I've talked about where it happens. Now, what is it? This is not the right answer per se. This is what I have learned through my experience in my career are the most important facets to focus on to ensure that we have stability in the foundation of the design over the long term, to minimize the negative impact of change. Let's start with the interaction model. All of these are going to be familiar. It's not that I'm exposing new concepts; it's more about how we use them and how we promote them. But I want to be clear about what I'm thinking about these elements.

[00:17:38] The interaction model addresses the nature of the solution. What interaction style does it drive? What themes and metaphors? What sense and image does it convey? This is foundational to setting expectations on the end user's part of how they're going to interact with this product or platform. Here are some examples, and I'll pull out a couple. You can differentiate a traditional page-based website, as one interaction model, from a portal website that has modules of portlets, which have their own behavior, can be placed in various locations and can be maximized to page level. These all set expectations for interaction.

[00:18:22] There are these models: the interview style that was popularized through TurboTax. Then there are some of these metaphors, like the paper document, which our word processing applications are still relying on for good reasons. Again, it's another interaction model. In a sovereign application, like a word processing document or the spreadsheet that you see above it, we have a model of interacting with actions through ribbons and menus, as opposed to navigating through a website, where you don't typically see those things. And you don't typically see a lot of links in our application models.

[00:19:02] And browsing shelves: we're still in Blockbuster, browsing shelves, on almost every streaming video service that I have seen. I'm looking forward to an evolution from that. However, again, it sets an expectation, and people understand it. I've said enough about the interaction model.

[00:19:20] The second element here is the high-level information architecture. We've moved from a point where we had these very large static brochureware pages online, and we were executing hierarchical representations of every one of these pages down to the small branches and fine leaves. The point that needs to be focused on here is the high-level structure. This can apply to any one of those interaction models, with different representations, but it's just about the high level. It's about the primary organizing concepts for how to interact with the content and functionality in the platform. It's about supporting navigation mechanisms that enable that interaction.

[00:20:11] This is right out of the polar bear series from Lou Rosenfeld and Peter Morville on information architecture for the World Wide Web. This is the high-level blueprint. Again, this isn't getting down to all the tiny leaves and branches. This is just establishing the concepts that ensure that we're able to understand and interact with the content and functionality of the solution.

[00:20:36] Here's an example. These are just small excerpts from quite a large representation of the information architecture that we had at Blink in the consolidation of over 3,000 web assets from NASA into a single unified experience. Again, decisions are made: each of these types of menus has a conceptual purpose, so those need to be conceptualized, and then navigation mechanisms designed to achieve them.

Global components, key design patterns and primary layouts

[00:21:10] So, interaction model and high-level IA. Now global components come into play. These are the landmarks of your solution. They help you stay oriented, they set expectations for their usage, and they ensure a level of consistency. Thinking about all of the functionality that you were able to envision for your product or platform, you're using these tools to ensure that you have the flexibility and the extensibility that you will need, as far as you can anticipate.

[00:21:47] Some examples of these: window management, window handling, panels, overlays, secondary windows, et cetera. I'll call out, as an example here, a maybe non-conventional global utility element, which is this third one, the site-wide filter. In this particular case, for a website that was predominantly informational, the user could self-identify and get a specific view and perspective on the content, and this is a utility that pervasively follows you around the site. Messaging architecture I mentioned, again, as one of those components that's important. These are just examples. Of course, there may be others that are more suitable to your applications.

[00:22:34] Then we focus on key design patterns, and here's where we start to blur the lines a little bit with detailed design. For certain aspects of your design that address the moments that matter, you need to really figure out whether this stuff is going to deliver against the value that users are expecting. I think we refer to these as signature experiences. These are the elements of your solution that make your solution unique and effective and stand out. They form the core of your interactive concept, and if we don't get that right up front, then again we're going to have problems as we start to evolve.

[00:23:12] Here's an example in a travel application, Kayak, and I've highlighted a couple of areas where design patterns have to be thought of and established. This is maybe a little bit rudimentary, because it doesn't necessarily change and have that level of sophistication. However, they're seeding a search and they're seeing search results. Certain attributes of each of those parts of a use case need to be designed in a way which is effective. These are so core to the essence of this application that we need to get those things right, and then you can layer on top of that: we need to sort, we need to filter, and how are we going to present those aspects? You can start sweating the details later, in terms of which are the primary filters, which are the secondary filters, what's the sequence of sort and so forth. Those things can happen later, but in terms of establishing this framework, these are key.

[00:24:08] Here's another example of key design patterns. This is for a client who's focused on creating training simulations, and then real tools, to manage disasters. This is a simulation of a disaster response for a hurricane. This is an overview, essentially a dashboard, that at a glance provides a sense of status across a bunch of different jurisdictions. It's a signature pattern that we felt was so foundational to the effectiveness of the design that we wanted to look at it early.

[00:24:47] Those are the four elements. The last one here is the primary layouts, and again this is bread and butter for our design discipline: establishing form factors, the layouts of the primary pages, templates and views, and responsive behaviors. We've seen this and we use this. We establish grids, and we establish layouts on top of those grids. Here's an example from e-commerce: facets on the left, for example, and you've got hero images and other aspects of your listings in this case.

[00:25:24] Together, what we've got are five elements of a North Star design. My appeal to this design community is: ensure the project plan includes a high-level design phase, or a North Star design phase. Get it into your plans, and make sure everybody understands why it's there. Get these things that we've talked about right first, get your buy-in, and then it's time to start sprinting. Thank you very much.

Q&A

[00:25:54] Host: Excellent, thank you very much, Paul. One thing that came up in there, and I love the concept: you made the parallel that there's an equivalent architecture taking place on the technical side. One thing I've seen is that people are pushing back against that architecture on the technical side, because there's the risk that you're going to over-engineer the solution. So what advice do you give to people that, if they argue for it and they win and they get this phase into their projects, how do you ensure that they don't fall into that trap of over-engineering?

[00:26:39] Paul: I'd interpret over-engineering from two perspectives. One is that you're actually generating a solution which is going to exceed the boundaries of what's actually needed, or what provides value for your end users. We've established our priorities in the problem space, and then we've said, "Yeah, but we've got all this ability to go beyond that." To me, that's over-engineering. The other aspect might be that we're not in sync with the technology platform, so there's a misalignment there. To that end, I'd say that just the same way we play with our technology and development tiers in the sprint releases, we should be playing in the same sandbox. In an ideal world, we have the opportunity to establish the underpinnings of the experience design and the architecture well before we've finished making the decisions about our technology stack.

[00:27:44] Host: Great. So that's a great point: more collaboration, and hopefully that will be able to solve the problem. I do think it's a good point that there are two, if not even a third one, that we might be making assumptions that the customers want something when it's not in fact true. I'd love to keep asking you lots of questions, because I have loads, and if anybody does, we can share them in the Slack channel and we'll ask Paul to answer them there. But unfortunately we're out of time for Paul's session. Thank you very much, Paul.

[00:28:18] Paul: Absolutely, thank you. We appreciate everybody's attention.