0:00 Hey, everyone. Thank you so much for taking the time to participate in this week's design principle workshops. 0:07 I think it's gonna be really fun. I'm gonna start out with a story about the principles work we did when I was leading design at DigitalOcean. 0:16 Hopefully, this illustrates how this kind of work can affect the product's trajectory over time. 0:23 But if you are short on time or just not super interested in how you design DevTools, 0:29 I've also made the TL;DW version of this loom that basically just skips everything not directly related to Heap. 0:37 I do want to ask that you do watch at least one of these in its entirety, and that you pay pretty close attention 0:45 because it's gonna be a tight workshop this week, and I want to make sure everyone comes in on the same page. 0:51 Cool. So, DigitalOcean. When I started leading the team there, we only had this one product. 0:58 It's called a Droplet. It's a virtual private server. Basically, you just run Linux on it and web server, and you could put whatever you want there. 1:04 They had a backup feature, and you could route a domain to one, but that's pretty much it. That's the entire system. 1:12 We didn't even charge for bandwidth, so super simple, almost inherently so, by just having a single product. 1:20 But we were on the precipice of what I called a complexity bomb. 1:24 Our main use case at that time were test servers and pet projects. 1:29 It's not super sustainable for a business, so we really decided we needed to move upmarket and prove ourselves capable of delivering reliable infrastructure. 1:39 That meant building functionality like team accounts, moving IPs, load balancers, and firewalls, 1:46 or object storage and block storage and monitoring, maybe even products like databases as a service, like Kubernetes. 1:54 As we'd scale, we probably needed CDN and connection pools and maybe a proper image marketplace, and so on and so forth. 2:02 We had to think about all of this while we were still at that square one. 2:08 Otherwise, we might go down the wrong path and then lose that main differentiator on the market, which was simplicity, and that could be catastrophic. 2:17 The main challenge became, how do we maintain DigitalOcean's simplicity as it scales? 2:24 Spoiler, we did this, and actually the first, the number one reason for DigitalOcean's value listed in its IPO filing is its simplicity. 2:35 We did an okay job. 2:38 The project that kicked us all off was called Floating IPs. 2:44 It was our first foray into high availability, and if we didn't build it just right, it could set us down a path towards that complexity. 2:55 The first designs were simple enough, like these were what one of the designers on the team put together, and they followed patterns that we were using at that point for domains, right? 3:06 So almost one-for-one on that page. 3:08 There were some issues that we noticed that felt more important now that we had two things in the system, right? 3:16 For instance, you can't really tell that's a droplet. 3:19 That's fine when everything is a droplet, but now that something is separate from a droplet, it's a bit hard to tell. 3:26 It doesn't feel like a significant object within the system. 3:30 And also, the way that we were going to surface these Floating IPs in different contexts felt really lacking, right? 3:37 So doesn't feel different from a regular IP, which can also appear there. 3:42 If you can assign a domain to either a Floating IP or a droplet, but never both, like why do we need two columns? 3:49 Droplets are surfaced differently on different views, don't feel significant. 3:53 So infrastructure should feel like connecting things rather than a single object's metadata. 3:59 That was our premise there. 4:03 Also that. 4:05 And we knew that a lot of features were coming in the next few years, and I wanted us to be ready for it. 4:10 So this type of exercise is about foresight, it's about vision and strategy. 4:16 And it's similar to the exercise that we're going to do at Heap this week. 4:20 So I workshop the initial list of principles. 4:23 I think they were about 10 and then collaborated with the team to flush them out. 4:28 Some were removed, some new ones were added. 4:31 And then at the end, we whittled it down to a solid list of seven principles that we all felt really good about. 4:37 You don't have to read any of this, just high level. 4:41 I want you to understand what these principles can do for a company. 4:45 So the first principle that I wrote down came directly from that Floating IPs project. 4:50 And this is a verbatim. 4:52 Is it object oriented? 4:55 And in an effort to bring visual and conceptual consistency to the platform, 4:59 we have started thinking of all objects as extensions of the same concept. 5:04 So all objects will be accessed and altered in a uniform, predictable way. 5:09 And so every primitive here should feel like a concrete part of your infrastructure. 5:14 That was our philosophy of approach here. 5:17 And it should be accessed and altered in a uniform, predictable way, as it's written. 5:22 And we spent some time in a room figuring out where to draw the line between object and feature, 5:27 and ended up with something like this, right? 5:30 Different categories of things, whether it's a networking feature, a storage feature, or like a compute feature. 5:37 And here's some examples of how it ended up showing up. 5:40 So things can attach to other things. 5:44 You can select from a list of things that look like things, run monitoring on different objects, or see your object storage. 5:55 And this is what we ended up shipping for that V1 of floating IPs. 5:59 Later on, we would make an object component with icons. 6:03 So it was a clear dropdown that was full of pieces of your infrastructure. 6:08 The floating IPs feel like literally connected to the droplet here. 6:12 And you can edit the droplet object in place to easily shift that floating IP somewhere else, 6:18 which is one of the main benefits of the feature to begin with. 6:22 And this is what it was changed to later. 6:26 On the droplet settings page, the floating IP has also surfaced as an object, as you can see kind of, you know, over here. 6:35 And then on the main list, it also appears as an object rather than a static IP. 6:41 Some more stuff, you know, it's just like you can see everywhere here. 6:45 These things are starting to appear as a visualization of your infrastructure rather than just a list of things, et cetera. 6:55 Right. One of the last things I shift at DO before I left was a change to the create droplet button that now lets you kick start a flow for any primitive in the system. 7:06 And you can see how much the system grew over time, yet all of these were clearly objects within your infrastructure. 7:13 And the pattern that we set up kind of met the needs of the complexity scale. 7:21 All of these are going to be verbatim what I wrote back in 2015. 7:24 Our second one was like, does it show the right thing? 7:27 Basically, like, are you showing the context that is most useful or the information that's most useful for the context? 7:35 And you can see this in things like projects, and where we set up infrastructure. 7:41 Does it support scalable interactions? 7:43 So one of the things we wanted to do was scale to very large companies with a lot of infrastructure and resources. 7:49 How do we make sure that when we get there, we are ready to manage the amount of things that these companies need to manage, right? 7:59 So make it as easy to manage a thousand objects as it is to manage a single one. 8:04 Right. We're going to feel similar things with data governance here at Heap. 8:08 And the enterprise team is working on some of this stuff. 8:11 But how can it be built into every single new feature that we build as one of the things that we're thinking about? 8:19 So here we had like, okay, we're starting to think about this there. 8:23 So how do we make it so you can create multiple droplets at once and do batch actions and stuff like that? 8:30 Does it encourage user collaboration? 8:33 And you'll see like a similar point in our principles in a second. 8:39 But the idea here was how can we make DigitalOcean feel like a place where your team lives and provide the right context for you and foster collaboration in order to make your processes more effective? 8:56 So you can see here, like, this is just a basic audit log, but we kept on iterating on this. 9:03 Does it let you keep your context? 9:05 So, you know, we were just shifting over to a single page app as everyone was around that time. 9:12 And that allowed us to do things like, you know, the sidebars, which I know everyone absolutely loves at Heap. 9:19 But it let you like keep your context and then change things around your infrastructure or, you know, or see things that are connected side by side and things like that. 9:29 And so you can see, like, as we build more patterns, we didn't shift you over to different pages. 9:36 We just kind of let you edit your stuff in line. 9:40 And similar here, right? 9:42 You're in a droplet. 9:43 We don't shift you over to like adding a volume somewhere else. 9:46 We just let you add the volume right there, like the storage volume you attach. 9:51 Our next one was, is this keyboard friendly? 9:56 So, so far, the things have been maybe fairly generic in terms of like you could see how you might apply those to other companies. 10:06 This one was specifically like we have developers. 10:10 We want to maintain and increase that developer love around DigitalOcean, which is a big reason for our growth. 10:17 How do we make this feel like a first class developer experience, right? 10:23 If they're in the terminal using Vim, ideally, we want to match whatever they're expecting on our UI as well. 10:32 So we want them to really easily alter resources, really easily kind of get to what they wanted to. 10:39 In a way, this is a command bar, but a command bar with developers specifically in mind. 10:45 And we ended up shipping something exactly like it. 10:50 So that's what they had when when I put this deck together, I think like three years ago, it looks better now. 10:56 Yeah, very cool. 10:58 Can it make developers better? 11:00 So this is actually an inspiration for one of the bigger principles that we have put together for Heap, and we'll get to that. 11:11 But the idea here is we could create more emotional investment and connection as well as users that adopt more and more advanced features simply by making them better at their job. 11:25 Right. And having Heap be the thing that doesn't just like provide them with answers, provides them with learning and growth. 11:33 And so we did a similar thing at DigitalOcean. 11:37 Our community ended up being like a huge, huge source of growth and of love for the company. 11:46 So you can see us like starting to build in, build in like education materials to all of our pages. 11:56 And by the way, all of this is after I left, like a lot of this stuff is after I left DigitalOcean, which shows like these principles as you, you know, as you define them, they really don't require as much kind of like reminding because it's just part of the muscle. 12:15 People know to care about this stuff and they've aligned on this stuff. And so every new feature, you just naturally get something like this where it's just like, oh, how could we help educate people as part of this, you know, this flow, like create a new droplet. 12:32 Now you create a new droplet and you immediately see how to start installing the stuff that you're interested in. 12:38 So this list of principles was designed to focus our efforts on things that could provide value to both our users and the business. 12:47 And structuring our North Star around the kinds of customers we wanted, you know, could accelerate the rate at which we acquired them, basically. 12:59 And to be effective, they had to remain relevant into the future. Right. The idea was designing with these principles in mind would create better user experiences organically since they're structured around user needs rather than business needs. 13:14 But they also, you know, apply to the business. So the choice of which principles to include was based on the current state of the business and its future goals. 13:23 But they're, you know, the way we phrase them anyway, object oriented made it easier. 13:31 The idea was that designing with these principles in mind would create better user experiences since they're structured around user needs rather than business needs. 13:42 But the choice of which principles to include was based on the current state of the business product and its future goals. 13:50 So object oriented, for instance, made it easier to understand the interface, but it also set up the foundation for building larger and more complicated infrastructure. 14:00 Show the right thing and keep your context are really, you know, pretty obvious heuristics, but they promote growth by making it easier to work with that infrastructure in a holistic manner. 14:12 What else? Scalable interactions and user collaboration. Right. These improve the experiences for organizations with more employees and resources, but they also make digitalization viable for these kinds of customers. 14:27 Keyboard friendly on its surface is kind of a nice to have like quality of life type feature, but turning the interface into a, you know, more native experience for developers. 14:37 We felt that would create an emotional connection, foster love, and increase mind share in the space. And then finally make developers better provides our users with lasting growth, but also creates higher value customers for the business. 14:54 So I think UX is a really powerful tool for accomplishing business goals and framing these goals this way allowed us to cater to user needs while augmenting the business. 15:06 And when business and user needs, I think, can be aligned and I said this too when I was interviewing here, I think really great things can happen. 15:15 And a digital ocean, they did so over in the next two years, we built a lot of new products and having these systems in place helped our team work together to scale our offerings really quickly while maintaining that through line of clarity and evolving the product into what it needed to be to succeed. 15:36 So Heap is in a similar place, right? We're growing from essentially a single product and analytics into a platform, right? This past year alone, we introduced journeys and session replay and heat maps and mobile auto capture and cross platform events, etc. 15:54 And the growth is probably just going to accelerate in the coming years as our teams grow and as we have more surface area and more synergies essentially across the board. 16:04 So we need to put a similar foundation in place to ensure that we keep Heap usable throughout these changes. 16:13 But then that's just the baseline, right? Keep and keep usable. The question is, where do we want to go as a business? 16:19 So let's work back from 2025, right? This is kind of the Amazon press release thing. 16:26 This is one version that I put together where we might be or where we want to be and how we want our customers to think about us. What is this fuzzy vision that we want to go towards? 16:39 And this is the model that I've been using so far. We're going to have time to talk about it and align on it. So don't read too deeply into this. 16:47 So low barrier of entry, new users can very easily pick Heap up. It's plug and play. It doesn't require a lot of heavy lifting to set up. It's capable of really powerful analytics when you need it. 17:00 It helps you see the actual reality via multiple lenses across quant and qual, and you can use these different lenses in different ways to kind of get a full picture. It's fun and seamless to use. 17:13 You don't really want to work at a company that doesn't use it. If you remember, this was like Slack at some point, and they've had huge product-led growth. It's trustworthy. You can trust the data and feel safe when using it. 17:27 It is valuable and usable at any scale of team, company, or usage. And it's the central place that truth-finding work takes place on product teams. 17:40 It's not like, oh, you get something from Heap and you do the thing in a different place. That's where your team works. That's where your team tries to understand what's happening. 17:49 So this is kind of how I think about, all right, two years from now, where do I want to be? What do I want people to think about Heap? And how do I want them to view it? 18:00 And so once we're aligned on a UX vision like this, we can then work back from it and define the design principles that will organically get us there. And they'll help us in a few ways. 18:13 So for one, these principles will help us save time and improve collaboration. So as we scope projects, conversations inherently or inevitably veer into subjective territory. 18:28 And it's tricky to determine whether it's more valuable to make a page faster or to add a quality of life feature. So every decision starts taking longer and being kind of more of a circular conversation. 18:41 And building a shared language and aligning on what's important can really cut through that noise and make it easier to prioritize trade-offs. 18:51 So this shared language can also be really valuable when discussing design proposals. So instead of saying something like, hey, this feels more complicated, this feels weird, we can say things like, hey, this doesn't raise signal from noise if that's one of the principles. 19:07 And that phrase now has a shared meaning and value across EPD. So it really helps align everyone and lead to kind of more productive and quicker conversations. 19:20 These principles also help us stay on track towards a vision. So building towards that like 2025, how do we want people to think about Heap? That's a years-long process. 19:32 Part of it is prioritizing the right stuff on the roadmap at a high level. We want to build session replay. But a lot of this is the hundreds of smaller choices that we make along the way. 19:44 Each one either getting us closer or farther away from our vision. And these choices always add up. 19:51 So design principles help us ensure that our decisions are directionally correct or at least think about being directionally correct. 20:01 And that increases the likelihood that we end up kind of similar to where we want to be, right? Even if the vision alters and changes, then we change the design principles. 20:10 But it makes sure that we are consistently thinking about where is this stuff going to take us. 20:16 And finally, these principles will really help us drive quality and results and maintain the quality that we already have. 20:25 So likely we can make more effective onboarding, higher retention, faster growth, if we put the right principles into place. 20:35 So last year, despite our focus on design, we launched a whole bunch of experiences that we're still not super proud of in terms of look and feel and kind of how the experience flows. 20:47 And whether that's a result of scoping decisions or speed to launch or like imprecise design or communication or whatever else, these individual experiences will in time add up to create a sub-part product. 21:01 And that kind of impression for people looking at Heap. 21:06 And so design principles also serve as a lens through which we can regularly assess the quality of individual projects and the entirety of Heap and its experience quality. 21:18 So they help us strive for more. And through that, they can influence scope and also lead to better overall products and the associate results with better products. 21:29 So like faster onboarding, higher adoption, super powered PLG, right? 21:33 We're just like improving all of these things by improving the experience, which leads to these things. 21:40 So over the past year, the design team has used that rough vision, right? The 2025 vision over many sessions and iterations this past year. 21:51 And the result of this work will serve as our starting point this week in each of the workshops. 21:57 So these are the top three high level design principles that we landed on for Heap. 22:04 They're what we see as the most effective areas of focus to get us to that vision I outlined. 22:10 So one is welcome everyone to us promote flow and three is up level our customers. So not seven, three, easy to remember, easy to use. 22:21 And the entire document looks something like this. And I'll dive into each of these things right now. 22:27 So two notes before we dive in. First, the end goal of this process is to align on a list of principles, right? 22:37 We are all going to align together and we will rank them by value of what they provide to our customers and business and by their relative level of effort. 22:46 So like how easy is it to build one of these things into a given project on average? 22:51 Then EPD teams will use these principles as a tool in conversations about scope and about trade offs. 23:01 And while we're going to strive to achieve these in everything we ship, they are explicitly not a list of requirements. 23:09 You won't have to do all of them in order to launch. The point of them is not to create a new hurdle or gate or to make things harder. 23:18 It's really a decision making framework that we can all align on that helps us decide which aspects of the experience we want to prioritize. 23:27 And second, all of us own Heap's product experience, right? 23:33 While the design team is driving this process initially, these principles are not going to be owned by our team. They're going to be owned by EPD as a group, right? 23:43 They'll represent where all of us together think Heap should be going and what we see as a truly great experience for our users and ones that we should always strive for. 23:54 So the goal of these is to represent a shared vision shared by designers, PMs, engineers, data scientists. 24:03 And their use then is going to be encouraged in project kickoffs, in design crits, in team Slack channels, in any forum really where designs or specs are shared. 24:16 And even folks outside of EPD can use them in conversations around planned launches or product design or anything like that. 24:23 So these are going to be shared. They're not going to be there in order to create roadblocks. They're really there for all of us to try and get more. 24:33 And at the end of the day, I think all of us really want our users to have the best experience they can possibly have. 24:39 And so I want everyone to feel ownership around this and I want everyone to have their voice heard as part of this process, which is why we're doing this week. 24:50 So let's go through each principle. So the first one is welcome everyone. 24:56 And that is Heap is on a mission to democratize data, something that we are uniquely positioned to do. 25:03 We make sure that Heap is clear and approachable to target users. 25:08 So users that we have decided are our use case. Obviously we're not like welcoming random, you know, I don't know. 25:16 I'm not even going to say the thing. But we're not going to optimize this for someone who is not in our target use case. 25:22 That said, we want it to be very approachable and accessible to anyone who fits our target user definition, which could be and should be wide and fairly broad. 25:35 So the first one in here, you'll see like each of these has a list of things. These are things to consider as part of this top level principle. 25:45 The first one here is obvious interfaces. So we make clean and intuitive interfaces that are implicitly understood by new users. 25:54 We don't overwhelm users with information. So the goal here is we can say, hey, is this interface that we're about to ship, is that, you know, obvious? Is that going to overwhelm people? 26:07 Like this is a thing that we can look at every time we put together a design and say, like, is it meeting these standards? 26:14 Sensible defaults. So our tools are effective without further configuration. 26:20 We can look at any ship and say, hey, like, have we really determined the right things to put here? Have we even created defaults? Right? 26:27 There's a lot of stuff that a lot of these things kind of apply to a lot of different types of projects. But all of them, if we think about them and if we prioritize them, are going to result in better experiences. 26:42 Again, not to say we need to prioritize all of this, but these things are really valuable tools. So simple things are simple, complex things are possible. 26:52 Our workflows and interfaces are optimized for the majority of common workflows, but are capable of more. In the past, we've called this escape hatches. 27:02 But the idea is how can we make the interface as obvious as possible while providing with our more advanced or power users, while providing those people with the advanced tooling that they need in a way that is, you know, accessible and findable. 27:19 Speak like a human. So our writing is concise and positive and motivating, free of typos. We strive to meet the brand principles that we've set together as Heap. 27:33 And the idea is someone with zero analytics or technical experience, who still can fall easily within our target user, can still understand the language and the terms that we use, and can still grok the entire interface as a result. 27:48 Another thing is anticipate questions. So we place answers about Heap right where people need them. For instance, if we're giving someone a feature or an analysis module, 28:00 how do we tell them what it should be used for? Right? We know that a lot of people are going to ask this, how do we make sure they have that answer right where they think, right where they'll need it? 28:12 Or is wise and expected option not shown in a given interface, right? If we think that people are going to be thinking this, why don't we just provide that answer in some way? 28:22 And then finally, how can we create psychological safety? Right? It is scary to be in an account with destructive actions that, you know, you might create something that a lot of other people see. 28:35 And we see that a lot of our first time users run into something like that of just like, I don't know what I'm doing, so I'm just not going to do it. 28:43 How do we create a situation where they feel comfortable doing those things and knowing there's not going to be any big consequence or scary consequence? 28:52 So here it says users can predict what will happen and who will see when they perform any action. And we clearly call out destructive actions and make accidental destructions or destructive actions reversible, right? If you delete something, let's provide an undo. 29:10 This is one of those things where, you know, the value of it potentially might be outweighed by the level of effort that would go into something like this in a given project. 29:21 So the idea isn't, hey, we have to do this. The idea is, hey, let's talk about it and see if it's worth doing in this context. 29:29 The second one here is promote flow. So we believe that the process of finding the answer to your questions can be fun. 29:41 Users should be able to lose track of time playing around with their data, and we make sure that he feels seamless and obvious and powerful. 29:51 I'm sure you've heard me talk about, you know, flow like a hundred times so far in all of the visions and every conversation, basically. 30:00 But what this means is a few things that we can focus on to make it feel like truly frictionless and seamless to use heat. 30:07 The first one is no dead ends. So analysis is an inherently exploratory and iterative process. People search for something, they search for another thing, they search for another thing. 30:20 They tweak a query, right? The amount of people who start out and get their answer right away, that's not really what I'm expecting for most users. 30:31 So we empower users to steadily move forward, effortlessly following their curiosity across Heap's broad set of deeply interoperable tools. 30:41 We identify synergies across these tools and enable natural cross-feature workflows. 30:46 So the idea here is when you have like a session replay and when you have a funnel, how do we make sure those things are tied together? 30:55 When you need to define an event while you're running a query, how do we make sure that's really easy for you to do instead of having to stop what you're doing and go somewhere else? 31:05 Right? Again, not the lowest level of effort, but depending on how much value we get from this, we can start having really productive conversations. 31:14 Second one is no wasted work. If a user expects a relevant choice to carry over to a different view, then it does. 31:23 Again, the differences between like level of effort and implementation and value might show up here at Heap, but at the end of the day when a user looks at something and clicks onto like a different query module and suddenly has the same selections but none of them are there, 31:40 that can be really frustrating and they're not thinking about how hard it is to implement. So we can decide for ourselves how important each one of these is. 31:49 Raised signal from noise, we emphasize the most important thing, prioritizing actionable insights over supporting information. Right? 31:58 We've reduced the cognitive load for you to find the specific thing that you're looking for. 32:03 The next click is always obvious. We predict common next steps and then guide users towards them. 32:10 We reduce friction beyond the expected. So we actively see creative opportunities to remove anything that might break our user's flow state. 32:20 So for instance, can we automate a manual action like the Run Query button? Can we optimize a frequent process by just removing a single step? Can we replace a confirmation dialogue that would have stopped someone in their tracks with just a friendly or undo option? 32:37 Right? So we really try and go the extra mile to see, hey, this new feature we're working on, what could be really annoying? What could be really frustrating and cause friction? And is there a way for us to solve that in either a standard or a novel way? 32:52 He feels snappy. So we prioritize app speed and optimize perceived performance. So this you might be looking at this and say, hey, you know, this isn't exactly a design principle. But if you've seen any of my product town halls, you know that everything is UX. 33:10 And especially how good something feels, right? We know that's affected, you know, how fast something feels. Sorry. We know that's affected NPS. We know that affects the experience and the feeling of the quality of the experience, right? 33:26 One of the most important things, even beyond some of the interface stuff, is like, is this thing going to be responsive and can I work as quickly as I'm thinking? 33:36 So that's also going to be graded against the rest of these in terms of like, how important is it? What's the level of effort? 33:44 And finally, Heap feels consistent. Similar actions across workflows look and act the same. So I think following this principle will increase our customers' chances of successful outcomes and improve this end user retention. 34:02 It'll also work to maintain cohesion as our system becomes more complex. So ideally, if everything we do focuses on this thing, organically, we're going to move towards something of value. 34:15 Cool. And finally, uplevel our customers. So you may recognize this from, you know, if you saw the full version of this from the DigitalOcean principles. 34:29 So upleveling our customers means framing analysis and interpreting results is both an art and a science. And it can be fraught with potential pitfalls and lead users astray, right? As we all know. 34:46 So the keep that we want to be improves user outcomes by actively developing their analytical skills and accuracy. 34:55 So what is this? A few things. One is providing helpful context or methods for validation. So we're going to build data trust and help users ensure they've selected the right data points in order for them to build trust both in Heap and in themselves, right? 35:13 And not always question what they're looking at. We're going to proactively address common analytical errors, right? For instance, hey, you're not filtering out internal users. 35:24 Did someone forget your organization's filters if we have something like that for an entire organization? Okay, this is like a double thing. So I'll remove one of these. 35:35 But the idea is, hey, if we know there's a thing that is a common mistake, how can we call it out and make sure people feel confident about themselves and their queries? 35:46 Clarify what something doesn't mean. So bad data can be worse than no data at all. And we actively guide our users towards what we call semantic accuracy. So is the answer they're getting the thing that they think they're getting, or are they going to walk away with a totally incorrect hypothesis? 36:06 So for instance, is someone using an incorrect time scale that changes their results meaning, right? They're using segments and segments don't work exactly the way they think they work. Or are they using an incorrect tool for the answer they're seeking? 36:20 Next, we have convey the gist. So where possible, we summarize and explain important takeaways to save them from having to do that cognitive heavy lifting. 36:31 But we also can call out different parts of the charts and, you know, the results and say, hey, this is why we think that. And this is why you could think that in the future. And these are the patterns you should take away. 36:44 As a company, we are opinionated about best practices, for instance, how to measure UX, whether we think you should avoid vanity metrics. You know, I'm not saying these things are exactly what we're going to say. 36:57 But we're not just, you know, a generic, hey, we're a tool and you can do whatever you want. We do have an idea of what the right way to do things is. 37:07 So we can provide appropriate tips. We can explain why we suggest certain things. And we provide easy access to our help docs integrated right into the flow. 37:19 We encourage collaboration and clarity across teams. We facilitate user collaboration and communication to increase clarity, effectiveness and efficiency. 37:31 For instance, like, do we prompt users to include important context to their colleagues when they create charts or dashboards or events or session replay collections or whatever else, right? 37:43 How do we make sure that at scale data governance doesn't get just so wild and like a million untitled charts and stuff like that? How do we make sure people find it easy to both create and communicate their own analytics work and to easily read other people's analytics work through the behaviors that we encourage as a product? 38:06 And finally, support scale. So we ensure Heap remains usable as organizations grow in size and complexity. And we help users locate relevant and valuable data and information regardless of scale. 38:22 So why do I think this one is important? I think increasing confidence and insights can further differentiate key right by providing that additional values that customers just don't regularly see, right? The other tools are way more like, cool, here's your result. 38:38 Potentially casting fun at insights generated by these other tools. And I think also that helping our users grow can create an emotional connection and a lot of brand loyalty. 38:50 Then considering that collaboration workflow thing and collaboration at scale, I think every feature that we do that has this can build Heap into an inherent part of the product development lifecycle, right? 39:11 And it's greatly going to benefit our larger customers. It's greatly going to contribute to our expand motions if people have their entire teams here. And with that, I'm going to shift over to the Fig Jam that we're going to use and run you through just very quickly what that is going to look like. 39:32 All right, so this is what the Fig Jam that we're going to work in looks like. It starts with some of the stuff that we've really just discussed now. Like, okay, how are design principles helpful? How will they be used? What might a scoping conversation look like? 39:53 So this is just for posterity. And if you want to read through it instead of looking at the slum again. 39:59 The rough process that we're going to be going through is this week, you're watching this loom. 40:06 We are going to do two workshops that include everyone from engineering, product and design leadership. So EMs, PMs, designers and ench leads. 40:18 Plus some experts around Heap and people with very specific viewpoints who can also help us frame these into something that's going to be really useful. 40:28 After that, we're going to have some iteration based on that feedback. And next week, we're going to have a session that's open to everyone around like, okay, if any ICs are interested in having their voice be part of this as well, that's going to be open. 40:43 And more iteration. We're going to put together a core group that reviews these final drafts, iterates on them. And finally, when we're done and when we have the things that we think that the org is aligned on 40:56 and that we think is going to be effective in getting us where we want to be, we'll start operationalizing these things. So building resources, figuring out processes, running them by the entire team. 41:08 And seeing that this stuff can be really valuable to us. So pretty aggressive timeline. We're going to do EPD-wide comms ideally around the end of May. 41:19 And then company-wide comms with the first opportunity. And then the thing we're going to do is we're going to revisit these processes and principles once a quarter and see if they're serving us if they need to be changed, if the vision has changed in some meaningful way. 41:35 So we're not going to set these in stones and then forget about them. This is going to be a somewhat living document that we all work off of. 41:43 So the thing that we're actually going to do in the sessions is we're going to start by reviewing that vision that I talked about earlier. 41:52 And comment on these different things and say, hey, I don't know about plug and play or something, or we should rephrase this. Or adding notes to like, hey, this is like, I think this should change in some way or we should add something here. 42:07 So y'all can add things that you think should be part of the vision or things we should remove. 42:13 This is really important because this is the foundation of all of the principles that we end up using and how we judge them to see if they're actually building towards a vision. 42:25 We can re-review the existing principles. We'll take about 10 minutes for this. And then we'll jump in and start adding feedback. 42:33 So there's explainers here that y'all can use when we're actually in session. But the idea is we go through each one of these. We say, okay, welcome, everyone. 42:45 Here's the description. Here's like each of these line items and things that we need to focus on. 42:51 And then each of us can come in and say like, oh, do we want to like tweak this or keep as is like, I like the description. It's keep as is. 42:59 You can see added your vote down here. Obvious interfaces, I would say, you know, remove this or I could say like, hey, actually like tweak it. 43:09 And and then we focus on value. So up here I have just like these are kind of what they look like. So it's T-shirt sizing. It's the best way I found to do this stuff in Fig Jam. 43:20 But the idea is, okay, when we want to talk about value for a specific thing. So let's say obvious interfaces. You click on this and you say, oh, obvious interfaces like huge value. Obviously, like I want to see. 43:34 I want to see the best interface and it's, you know, it's a no brainer. And then level of effort. I can click on here and just like, oh, well, obvious interfaces. 43:46 You know, they really it's like interface design. Sometimes they might be large. So on average, probably like medium. And it's just a matter of making sure that we design those and keep them up to par and keep doing this for everything. 44:00 Things like, you know, 44:02 or anticipate questions might be a bit harder of a lift. Or if we go down here, we can say like, oh, no wasted work. And that means like we transfer all this data from one one view to another. That could be like actually like a pretty big lift. So we write that here. 44:17 And so all of this is going to feed into a prioritization ranking that we're going to propose for for all of these principles. 44:26 If you say like, hey, we should tweak it. We should change the value, then add your comments in here and write like a bit more about why. Don't read other people's comments until we're done just because I want to avoid bias. 44:40 And then we're going to end each section by saying, hey, this entire design principle is important and valuable to Heap. Right. So welcome everyone. Yeah, pretty important. I'm going to click on here. 44:53 And then when everyone votes, we'll just open this up and you'll see like people kind of appearing in different places here. And that'll give us an idea without biasing kind of where everyone's at. 45:07 So we're going to do this once for each of the principles. 45:10 And then this is we're not going to have time for this part during the actual session. But if anyone is interested afterwards, you can copy this. 45:21 You can paste it somewhere. Right. And you can say, hey, like here's you know, there's my name. 45:28 And I'm going to start just playing around with this. So double click or triple click into one of these things and start changing this or like adding new things or shifting things around. 45:38 So like just a little thing for you to give your own spike on this. And that's it. So super excited to work with all of you. This is not a final thing. This is like the starting point for our work together. 45:52 And I can't wait. All right, everyone. Thanks so much.