Untangling Complexity in Your Design Process

Gabriela Ospina at UXDX Community: Simplifying Design Processes for Team Efficiency. Video: https://youtu.be/9_PFZ3j3cs8

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.

Complexity is not complication

[00:00:00] Hi everyone, thank you for tuning in. I'm Gabriela Ospina, lead product designer and object-oriented UX strategist, currently working at Wolt, which is the international brand of DoorDash. All throughout my career I've had to deal with complexity. Whether in investment banking, human capital management, German insurance, and now working for a commerce platform, I've always found my way to complex domains. As a designer I used to call myself a problem solver, but recently I realized that one of my core skills is actually managing complexity. I'm a complexity manager. I'm still a problem solver, but for me to be able to solve those problems, I first need to understand the complexity that I'm working with.

[00:00:46] And how do I do that, you might ask? I do it by focusing on the pieces that make up the domain, and by asking smart questions that will lead me to the most intuitive and valuable solutions for our users. Before I go any further, there is one thing I want to make sure we have clear: complexity doesn't always mean complicated. When something is complex, it just means it has a lot of components. When something is complicated, it means it has a higher level of difficulty, usually not matching the user's mental model. But let's not use the excuse of complexity to build complicated products. Let's approach complexity with an open and curious mind. Let's ask those smart questions so we can understand it and simplify it for our users.

Nouns before verbs

[00:01:37] When we look at traditional design methods like the Double Diamond, designers have been taught to use these types of methods to help us organize our thoughts. But our thoughts are far from organized. After we have done the research and defined the problem, and we need to move into the solution space, we still have a lot of open questions that we need answers to. And many times, with the pressure of stakeholders wanting to see something, designers resort to the wrong tools trying to get answers to these questions. Many times it looks like this: designers jump straight into sketching and designing screens and interfaces, and at the same time they're designing the content and information architecture and trying to validate the business rules. What they're doing here is multitasking, and we know that multitasking is just doing a lot of things badly at the same time.

[00:02:35] What we should be doing before designing any screen is defining the structure, the system, and validating the business rules. And I'm not saying this should be a designer's sole responsibility, or an engineer's job, or a PM's job. It should be a collaborative effort among all members of the product team.

[00:02:57] Now I want you to think a little bit about your own process. Do you know how you and your team are approaching your domain and trying to understand the complexity that you're working with? Do you think you're trying to understand complexity by focusing on the nouns or the verbs? Let me put it another way: are you trying to understand the complexity by defining the objects, or by creating task flows and user stories?

[00:03:26] Many times teams try to understand the complexity that they're working with by being task oriented, by focusing on the verbs. When we focus on the verbs, we often prioritize the happy path, and we deprioritize the instances where the user goes off path. With this we can easily overlook the opportunities that we have to make natural connections. This also happens when we need to add any feature into the product. Many times designers are left trying to find creative ways to make it fit into a screen, often creating disjointed user experiences. Another pitfall of this approach is that we can easily forget about all the other actions that the objects in our feature offer the users, as we limit ourselves with the constraints that user stories often create.

[00:04:23] When we try to understand complexity by focusing on the nouns, by being object oriented, what we do is first try to understand all the pieces that the problem is made of. Then we try to understand all the pieces that the possible solutions could be made of, and find the relationships between them, to then create our user stories. We first need to understand what it is that we're working with before we decide what to do with it. This way we can keep our interactions as simple and straightforward as possible.

Object-oriented UX and the ORCA process

[00:05:01] The concept of object oriented is not new. It has been around since the 1950s; engineers use it for their programming languages. In the early 2000s, Dave Collins wrote a book called Designing Object-Oriented User Interfaces. A couple of years after, eil yane [?] wrote an article called Object-Focused Versus Task-Focused Design. And most recently Sophia Prater, one of my mentors, coined the term object-oriented UX. Object-oriented UX is a philosophy of product design that respects the fact that humans think in objects, and therefore the objects in our system must be clear, connected and recognizable. With object-oriented UX and the ORCA process, I have the tools to be able to translate research and requirements into a structured design solution.

[00:06:01] Now you might be wondering, what is ORCA? Like the whale? Well, orca is a whale, but that's not what we're talking about here. ORCA is an object-oriented UX process designed by Sophia Prater that focuses on the four main questions we should be asking before designing any screen. What are the objects that make up the user's mental model? What are the relationships between those objects? What are the calls to action that the objects offer the users? And what are the attributes that make up those objects? ORCA is not a new UX process; it's a new piece of your existing process.

Objects

[00:06:42] So let's take a look at the first question of the ORCA process: what are the objects that make up the user's mental model? We focus on objects because they are the valuable things that the users and the business care about. They're the people, places and things that the users are going into your app for. Not to be confused with components: users are not going into the app for a calendar picker. They're going into the app for a specific person, a place or a thing. To ensure that the objects we're working with are actual objects and not just means to an end, objects should have structure, can be instantiated, and should provide a real purpose for the users and the business.

[00:07:31] To give you a better idea of what these objects are in terms of an application, I'm using the Wolt DoorDash delivery app to give you this example. Some of the objects that we find in the consumer application are profile, courier, support, restaurant, store, venue, menu, menu item and order. As you can see, all of those are nouns and fit into the people, places and things category.

[00:08:01] As we're defining our objects, a lot of those questions that we had at the beginning are going to naturally start to come up. Are X and Y the same thing? Is a restaurant and a store the same thing? Is a store and a venue the same thing? If not, how are they different? What are some examples of something? You want to start creating a mental image of what this thing represents. What would you call a group of X? Can you define X for me? Is this thing an X? If you or no one from your team is able to answer all of these questions, it is a good sign that you might want to go back into research and get a clear understanding of what it is that you need. Because the last thing that we want is to go all the way to development and figure out that we have designed something that we don't need. So let's avoid designing a square peg that doesn't fit into the round hole.

Relationships

[00:08:55] The second question of the ORCA process talks about relationships: what are the relationships between the objects? Defining the relationships of objects helps us define the object in the context of the product that we're working with. It's not enough to just have an overall definition of an object, as the purpose and the mechanics of the objects can differ between our products. Defining the relationships of objects also helps us improve navigation by adding context or cross-linking items. It also helps to ensure that we are not creating extra work for content creators. When we understand when a piece of information repeats, we can surface that information without having to ask the user to input the same data over and over again.

[00:09:52] As I mentioned earlier, engineers are using object orientation for some of their programming languages, and they also need to visualize these relationships. The way they do it is through system modeling diagrams, UML for example, and even though this is a simple one, for me it is very complicated to understand. The way that ORCA practitioners do it is through a nested object matrix. The way it works is that we take our objects across the x-axis, and then we list out the nested objects and their cardinality to create a column. The way to read this would be: a venue could have zero to many orders. A venue must have at least one active menu. A menu could have one to many menu items. Again, this is in the context of the consumer app; it might be different for other products within the domain.

[00:10:56] More of those questions that we had at the beginning are going to continue to come up in a natural manner. What is the relationship between X and Y? Can X have many Ys, or just one, or will it sometimes have zero? This way we can already start planning whether we're going to need any empty state screens or not. As we define relationships, we're really untangling connections early, and it is OK to change our mind, because the cost of change is still low.

Calls to action

[00:11:27] The third question of the ORCA process talks about calls to action: what are the calls to action that the objects offer the users? It is important that we orient our CTAs around the objects to be able to have more intuitive and relatable actions. The last thing that we want is to have the light switch for the bathroom outside in the hallway.

[00:11:53] To visualize the CTAs that we need for our product, we use another matrix, a CTA matrix. What we do here is take our objects across the x-axis, then we list out our different user roles and start calling out the different actions. The way to read this would be: a venue can be rated by a consumer. A venue can be created or edited by a merchant. And a venue can be created, edited or deleted by a support associate, and so on.

[00:12:29] The important questions that we want to ask at this stage are why and when. We really want to understand the motivation of our users, not just on the surface level, but really go deep into the users' desires. When discussing the when, we want to understand the micro-moments that trigger the users to take certain actions. As we clarify the context and setting of interactions, we can create user stories with clear user motivations.

Attributes and the object map

[00:13:03] The last but not least question in the ORCA process talks about attributes: what are the attributes that make up the objects? By defining the attributes, we're able to figure out what goes on the page before designing the page. Attributes are broken down into two aspects: core content and metadata. Core content is any piece of information that is going to be unique for every instance of your object, so think about name, image, description, things like that. And metadata, to simplify, is anything that you want your users to be able to group, filter or sort by.

[00:13:50] As we define our attributes and add them into our object list, we're creating what's called an object map. An object map is the holy grail of object-oriented UX. It's how I started learning about this process. And if you have not caught on yet, the colors are actually very important. What ORCA practitioners would love to do one day is to be able to read any object map in the world and understand it right away. So please keep your objects in blue, core content in yellow, metadata in a red-pink color, and calls to action in green.

[00:14:29] To demonstrate a little better how the object map works, we take our nested object matrix, with our main objects on the top and nested objects under them, and we start listing out our attributes, core content and metadata. More questions, of course, are going to continue to come up as we do this exercise, and it might look like this. What information do we need to show about X? What are the options for this attribute, the values? We want to continue adding to this mental image of what this object represents. How might we want to sort, filter or group by? This is what's going to define the metadata attributes.

[00:15:10] Another thing that I like to do with the object map is to start prioritizing, not just in terms of development, which we can do from left to right, but also prioritizing the pieces of information that we want our users to be able to see in those smaller views, the card views. If we put those at the top, then we know those are the things that we want to have visible right away, and everything else can be one click away. This way we'll be able to design our screens with more confidence. A lot of the back and forth that was probably happening before is going to be significantly reduced, and now design can really focus on the craft.

From object map to screens

[00:15:53] To show you how this would work, let's say we want to design for our venue object. We take our frame and start listing out the attributes that we have defined. We have an image, name, delivery cost and average meal price. And let's say during the discussion we have decided that opening hours and address are not that important, and they could just be one click away. We also have a nested object, which is the menu, so we can also highlight that there. You might have another team focusing on the menu screen, and you might just want to wait for them to define that view. If it is you designing the menu object as well, then you bring in the menu object, see what the attributes are that make it up, and start listing them out, just as we did with the venue. We have language and categories as our metadata, and then we have nested menu items.

[00:16:59] We can do the same thing with the menu item if we want to also visualize what the main elements are that we want to surface there. It would be image, name and price, for example. This way we're able to collaborate and create a common understanding with the entire team earlier in the process. We'll reduce the guesswork, we'll speed up development by speaking the same language, and we'll create valuable outcomes for the business and the users. With ORCA and object-oriented UX, you have the tools to be able to bridge the gap between research and discovery and design in a structured manner. Thank you all for your time. I highly recommend going to ooux.com to learn more, but I'm happy to answer any questions now or later.

Q&A

[00:17:50] Host: A few questions here for you. That was really, really fantastic, thank you so much. The first one was: what tools do you use to help with this on a day-to-day basis, or with your planning?

[00:18:05] Gabriela: You can use whatever. Actually, the way that I learned it was with sticky notes, with Post-it notes, back in the day when we had to go to the office. That's the way that I used to do it. But now it's really any tool that you're working with at the company, so either Miro, or Notion if you really want to get fancy, but I even use Figma. Anything that the team is used to, you can use.

[00:18:29] Host: Amazing, great. And could you share what your team structure looks like that works on projects like this?

[00:18:38] Gabriela: It depends. I've used this all throughout my career, and I've worked in startups, scale-ups, all types of team sizes, and it really depends on where we're at in the process. As with any design framework, it's flexible enough to just use a little piece of whatever it is that we need at the point that we're at in our project. Usually the main point is to include as many people as possible, from of course product managers and engineers to content designers and researchers and data analysts as well. At Wolt I was able to involve data analysts as well.

[00:19:18] Host: And that's an interesting point. How early do you, or should you, involve the engineers in that?

[00:19:23] Gabriela: Oh, early, as early as possible, because they're doing this at the end of the day. When designers are handing over their screens, they need to do this, and this is the way that they think. So when you have a question, they're mostly who you go to, because they will know, and they already understand how this thing works.

[00:19:42] Host: Fantastic. And oh, I like this one: how do you understand the motivations of the users as a small business? You went into motivations and micro-interactions. So somebody who might not have the resources of the team that you have.

[00:19:59] Gabriela: Well, definitely this is going into the why. If you don't have answers to those questions, or any of the questions that I listed, it is a good sign that you might want to go back into research and try to understand that. So depending on the type of research opportunities that you have, any type of research that you can do is what's going to help you understand what those motivations are. If you don't have them at this time, you need to go back into research and try to find what those are.

[00:20:24] Host: Yeah, fantastic. And how do you define micro-interactions?

[00:20:32] Gabriela: Micro-interactions. I believe I used micro-moments. This is what we really want to get to on the why: trying to understand what the micro-moments are, and the desires of the users. What are they trying to achieve?

[00:20:49] Host: OK, great. And should the calls to action be for the users or the business? How do you do both? That's an interesting angle.

[00:21:05] Gabriela: It should be for the product that you're designing for. Your user will be part of that call-to-action matrix. If maybe it is an internal tool, and you want to understand how the business is going to manage those objects, then you list them as a separate role. But you do have the option to list out the different roles and ensure that each of those actions is related to the object. So the main thing is to list out the actions, or connect the actions to the objects, and then specify which of those roles those actions can be done by.

[00:21:48] Host: Amazing. And I'll ask one last question here. What has traditionally been the biggest blocker, across all the organizations, with regard to trying to implement this flow?

[00:22:04] Gabriela: Time. All tough questions. It depends on the time, and also how much knowledge each team has. A lot of times we're working with assumptions, with things that we don't know, or legacy projects. Especially when things get really complex is when we're working with legacy projects. But even if you can just do the object map, or understand what the objects are that you're working with. ORCA is actually a 15-step process divided into four phases, but I honestly also don't do all of them. It depends on what question I'm trying to answer. So I might break down this entire thing into just the CTA matrix, or just the object map, or just understanding, "I'm working on this screen, what are the objects that are actually impacted by this screen?" and just focus on that. So it is very flexible, but I do recommend that whatever time you have, you do something.

[00:23:08] Host: Love it. Thank you so much, Gabriela, that was really, really interesting. I think people are going to rewatch your talk and also start googling a lot into the area. Really, really appreciate it. For those who are tuning in live, Gabriela's talk will be live next week on Gabriela's profile. So thank you so much, and I'll talk to you soon.

[00:23:32] Gabriela: Thank you.