Designing for Highly Technical Domains

Ridhima Gupta at UXDX Community: Designing for Agile Domains. Video: https://youtu.be/4FlhfexjGss

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.

Why technical domains feel scary

[00:00:00] I'm Ridhima, and I'm so excited to be speaking for UXDX this morning. The topic for this session is going to be designing for highly technical domains. Before we get started, a little bit about myself and why we are talking about this topic today. I've spent almost the last decade designing various products, working in various technical domains, such as network security at Juniper, data visualization at Tableau, and now machine learning tools at Databricks. Through all these experiences I found that designing for complex domains, although it's a highly rewarding experience as a designer, can often feel very scary and, frankly, almost uncomfortable territory for a lot of designers. Especially when you've just joined a new team and you're working in an entirely new, highly technical domain, and you're expected to start designing experiences for users right away.

[00:01:06] While you're in that mode, you're also constantly being bombarded with terms that you have very little idea about, and you also don't have a good understanding at that point of your product or the ideal workflows of your users. And on top of all of this, you're also trying to build relationships with your stakeholders, who may or may not have worked with designers before. So I think it can certainly feel like a lot for a lot of designers. How can we as designers approach working in highly technical domains and harness the incredibly rewarding experience that it can be? That's the discussion topic for today.

What makes an application complex

[00:01:49] Before we go deeper into how we can be successful as designers working in these complex domains, I want to take a minute to talk about how we even define complexity, and what the parameters are that make something complex. We all know a complex application when we see one: for example, tools like Tableau for visualizing data, or this tool Ableton for music creation, or a tool like Blender for designing in 3D. But what makes something complex? If you think about it, it can be hard to find the vocabulary to define the characteristics that make something complex. So I tried to dig deeper into the definition of that.

[00:02:44] According to Nielsen Norman, complex applications are usually ones that operate in specialized domains or require specialized or technical knowledge, which can often take a while for users to develop. In these cases users are generally doing specialized tasks. What's interesting is that usually you'll find users having very broad goals, with not a single happy path but rather several nonlinear workflows to achieve something. For example, a 3D artist trying to create a 3D model of a house in Blender might want to do tasks in a different order depending on a variety of factors. Compare that to something like a shopping experience at Amazon, where someone is more likely to search for an item, add it to their cart and then go through the checkout process. That is a more linear workflow.

[00:03:41] So the question is, how do you approach designing for complex domains that might be quite unfamiliar and scary as a designer? That's going to be the focus of today's talk. First, I'll share some strategies that I've found work well when you're trying to learn a new domain and work in these complex domains. I've ramped up on several highly technical domains in my career, and I've gathered some strategies that have worked well for me, so I'm going to share those with you. In my experience, the understanding-the-domain piece is probably the biggest roadblock that I've seen designers run into. Unless we as designers cross this hurdle, it can be very hard to do truly impactful work in these organizations and operate at a more strategic level, so we'll spend a good chunk of time on this piece.

[00:04:46] Then we'll also look at some discovery practices that I've found have worked well in my experience working in these organizations, especially when you might have limited access to users. And then lastly we'll deep dive into how you can build trust and strong communication with technical stakeholders, again, some of whom may or may not have worked with designers before. We have a lot of ground to cover, so let's get started.

Learning the domain: common pitfalls

[00:05:15] Let's look into the first aspect, which is learning about the domain that you're designing for. Having reflected on my experiences and observed several other designers working in these domains, I've observed that there are some common pitfalls that a lot of designers fall into. One is that designers sometimes try to learn everything at once. It can be very overwhelming, especially if you're new; there are a lot of resources out there. The other aspect is that a lot of designers probably end up learning a little overview of the domain in the beginning, but they stop that learning there and get stuck at surface-level knowledge, which again is not very good in the long term.

[00:06:15] The other piece, which I think a lot of designers who have worked in this domain might resonate with, is that a lot of designers constantly pressure themselves that they have to be a domain expert to do good work, which I think is absolutely not true, and we'll talk about it later. And then the last piece is waiting for other people to create a learning path for you, which is not the right way to learn here. In reality, you have to design a learning path that works for you and takes into account what you already know, and what strengths and weaknesses you want to focus on.

[00:06:58] As an example, when I first joined the machine learning team at Databricks, I joined with absolutely no experience in machine learning. I remember being super uncomfortable, and feeling like an imposter in almost all the meetings that I went to. I was hearing all these terms, and I was expected to start working on two or three projects right away. And this was just the domain; I also needed to learn about the users and the product.

[00:07:30] So how might you approach this learning? In general, when you are new to a domain and you're exposed to a lot of knowledge initially, I think the biggest step, as a first step, is to try to build a more conceptual, high-level understanding of the key user workflows: to understand what users are actually trying to achieve, and what success looks like. In the case of machine learning, it could be distilled down into the core components of what people do. They do data preparation, they do training of machine learning models, they then put the models into production, and finally they want to monitor these models, and the cycle continues. Having that understanding and clarifying it really helps. On top of that, you can then start tying in the various concepts you're hearing about, and layering them, and it starts making more sense.

[00:08:32] What I found is that this framework really helped me in onboarding. One part was just understanding the concepts of the domain, but then on top of this I could layer user research findings for each part of the process, and any product opportunities or gaps, et cetera, which further helped me deepen my understanding.

Strategies: play with the product

[00:08:55] This is all great, but a common question is: okay, how do I even get there? How do I figure out how these various pieces fit together? Where do I even begin? A lot of people have that question. Again, it seems pretty obvious to start your journey by taking notes, basic Googling, and even asking GPT now, which is being very helpful as well, and noting down all the terms you're hearing and trying to find the definitions. And of course also taking some basic online courses. But where do you go from there? How do you build that intuitive, next-level understanding of your users' workflows and how they're using the product? I found a number of strategies that worked really well for me and helped me onboard faster to a new domain.

[00:09:49] The first strategy I want to point out is playing with the product. I think all of us designers, especially working in these domains, should take it very seriously. For a lot of designers working on consumer products, it's very easy to play with the product, and you are sort of a customer. But in this case, try doing some tasks that your users would do in the product. Of course, some of them can be very technically challenging as well. So what I've usually found works is either sitting with a domain expert in the area and trying to perform that task yourself, or following along with tutorials, or even observing someone doing the task. I think that really helps give a lot more intuitive understanding of the product and how people are using it.

[00:10:41] At Databricks there's this concept of critical user journeys. I think a couple of other companies also use it: new hires go through a particular product feature and then document their process with the team. This is the first machine learning model that I created at Databricks, maybe after one or two months of joining, and I still remember how illuminating that process was. I was immediately able to see so many product opportunities that would otherwise have been easy to miss if I had just spoken to users during interviews, for example. So playing with the product definitely builds a very strong intuitive understanding. And when I documented my journey going through this process and shared it with the rest of the company, even though I was super new to the domain and super new to the company as well, there were several usability suggestions that I gave to the team which were invaluable. Those don't really require you to have domain knowledge at that point, but they help you bring value as a designer right away.

Strategies: discovery calls, SMEs, drawing and sharing

[00:11:59] The next method I'll call out is one-on-one discovery calls with users. I think we all know this, but it's important to call it out, because sometimes we wait to do discovery calls until a couple of months after we've started a new job. I think we need to spend time early, and try to work with your PMs or other stakeholders to have you observe some calls, even if you're not familiar with those topics. Just observe some calls, and you'll start hearing themes that emerge through a lot of these calls. During these calls, see if you can ask a couple of questions towards the end about the nature of their work, their environment, their day-to-day tasks or responsibilities, which will also give you a little bit of understanding of your users' environments and their workflows.

[00:12:57] Another mechanism that I've found has worked very well when you are building that understanding of the domain is building relationships with SMEs in your organization. I can't stress this enough. I found that you need to build your allies with people within the company: SMEs who are passionate about your space and willing to share feedback, be the voice of the customer, and share with you the consolidated nuggets of wisdom about what's working and what's not working for users. Relationships with folks in a couple of areas, like customer success, solution architects or others, go a long way in building your understanding. And you can of course reach out to them and get feedback on any concept you're exploring, or if you have any questions about a particular part of the user workflow or the product.

[00:14:00] Another mechanism, the fourth one: this comes naturally to us designers, but we need to remember to sometimes draw stuff out, in meetings or even when learning. It really helps to clarify your thinking, and it's also quite useful in bringing stakeholders onto the same page. For example, this workflow was of a specific ML training process that I created along with my team, and it probably saved me and my team several days of back and forth, as they were trying to explain the workflow to me and we were trying to get on the same page.

[00:14:38] This is a diagram from another colleague of mine at Databricks, who ended up mapping the entire information architecture of the product, and I used that to map out the key user journeys of different users. It was a great tool for anyone else joining the team, for their onboarding, but it also helped people understand how various parts of the product relate to each other. So it helped bring to the surface a lot of redundancies in the product that could be simplified further as well.

[00:15:11] The last technique that I would definitely like to call out is that one of the best ways to learn something is to share your learnings with others. It's a forcing function for you to make sure your basics are correct, and it helps you identify gaps in your knowledge as well. Even though you might not be an expert in the area, that's totally fine; there will still be people who find your knowledge useful. The more you share what you're learning, either through blogs, guides or talks, the more cross-pollination of ideas and knowledge occurs, and you'll build more opportunities for collaboration with other designers and PMs who might not even be in your immediate teams. As an example, about three months after joining the ML team at Databricks, I, along with two other designers, gave this intro-to-ML presentation to the entire design team. This got the entire design team thinking about ML and interested in that part of the product, which they were previously shy to deep dive into.

[00:16:16] To summarize this first section: even though you spend time learning about the domain and you're putting in your efforts, there will always be something that you don't know, which will tend to make you uncomfortable and bring a state of discomfort. But you need to remember that you don't need to be a domain expert in order to excel as a designer. Instead, you need to focus on your superpowers in being the voice of the user, and spend a lot of time gaining a solid understanding of your users, their motivations and their challenges. Again, bring your superpowers: help your teams visualize your users' problems and their potential solutions. And focus on learning in the long term. It's a long game when you're working in a particular domain, so don't be very hard on yourself as you're working towards this.

Discovery with limited access to users

[00:17:15] Now that we've spent a little bit of time on how to build a solid foundation in the domain, what kind of discovery practices can you use to strengthen your understanding of users? I think it's important to discuss these discovery practices, because again, one of the big challenges that designers face in these domains is that getting access to users can be hard. Users might be strapped for time, or people might not be buying the product directly but rather going through elaborate sales cycles.

[00:17:50] Another aspect to this is that you will also notice your product has different types of users. There'll be the power users, who are the expert users, the evangelists for your product, who use your product heavily. They're the most likely to provide you feedback, and usually these people tend to be more on the positive side as well, because they already love your product. The other user type would be the professionals, who might use your product for their day-to-day work but can be a little bit hard to get access to. And then there are the novice users, who might still be domain experts but have limited knowledge of your platform and need help onboarding. So it's also important to figure out the mix of users your platform supports, and the unique challenges that each group faces. When you're talking to users, try to talk to a mix of these different user types, so you get a broader perspective of the various users.

[00:18:56] So how do you have these customer conversations, and how do you get in touch with users? One of the first things is leveraging the relationships that you've built with some of the SMEs, with professional services or solution architects or sales engineers in your organization. Usually I've found the best way to find these people, at least at Databricks, has been through Slack channels, where you share, hey, I'm looking for feedback on a particular issue. Usually these people will be the first to respond, and that helps start building that initial relationship with them.

[00:19:41] Another area, apart from the regular research activities that you will probably be doing as a designer, such as usability testing or more generative research activities: I found that the single most illuminating research activity for me has been observing someone do a task. Giving them a prompt, and really just observing how they go about finishing the task. It could be either a user, or an SME if getting access to a user is hard. I found this works really well because a lot of times, when you're doing generative research, a lot of the nuances get lost, and it's hard for you as a designer to really understand how a user goes about their workflow. This is more grounded in reality rather than hypothetical scenarios, and I think it really helps build that intuitive understanding of your users and their workflows. But one downside is that it can take a lot of time as well, so you'll have to balance how many of these activities you do versus using other research methods.

[00:20:58] Again, because we're working within the constraint that getting access to users can be hard, I think you have to be resourceful as a designer in these domains as well, trying to get a more rounded perspective of your users: looking at previous Jira tickets or bugs, or previous research studies, or public reviews. Also, playing with competitor products and having an understanding of their offerings really helps, because it gives you an understanding of what's out there and how other people have been solving the same or similar problems. That's super helpful. And of course, through all of this process, it's important to work closely with your cross-functional partners to stack rank these issues and help with prioritization, et cetera. That's a given: you're working closely with your cross-functional partners during these discovery exercises.

Working with technical stakeholders

[00:22:00] That brings me to the last part, which is about managing stakeholders. A lot of designers run into unique challenges with managing and working with stakeholders in these domains. One of them is that a lot of designers working in these domains are working with technical stakeholders who may or may not have had the experience of involving designers in the product development process. It may or may not be the case for you, but depending on that, you might have to approach working with them differently. Another challenge that I've seen designers run into is that it can be hard to push back when you are early in your learning process. But I've found some strategies that help when you're just learning, so we'll dive into that as well.

[00:23:07] I think it's also a harder road to build influence on the team, especially if the team is used to working without a designer. All of this can be a little bit disheartening, and it can be hard and tiring to try to prove your value on the team. It can be challenging for sure, but I think it's important to remember the purpose of your work, to stay close to your users, and to keep working towards making their lives easier. I stole this from Nielsen Norman, from one of their presentations about working in technical domains. They said that it's important to remember that everything you do is making users' lives so much better. And I think it's important to keep a positive mindset and focus on the things that you can control.

[00:24:05] Strategy number one, I would say, is that the big goal for you as a designer with stakeholders is to build trust with them and show value as soon as you can. Be intentional with showing value and building trust. For example, make sure that you share out broadly any customer interviews that you've done, insights you've gathered, prototypes you've created, via Loom videos or whatever, and not just with the internal teams that you work with, but also your broader orgs. Share resources on design with the teams, to help elevate their understanding of how design can be useful for the product. One thing that I've tried to do: we have a quarterly all-hands, and sometimes I try to share some of the design work that we are doing there. It helps more people become aware of the incredible work that you do as a designer and the value you bring to the team. And I think the more value you show, the more trust it builds with the teams as well.

[00:25:21] The other piece, and it goes without saying, is that you have to understand the business as well. In these complex domains, if you want to operate at a more strategic level, understanding the domain is one piece, but you also have to learn about the business. Where does the money come from? Which are the whale customers, or quote-unquote the big customers? What are their biggest asks, and what are the biggest gaps and opportunities on the platform that they are asking for? It's important to be aware of them and keep an ear open for that. Having an understanding of the business will help you connect with higher-ups much more easily, when you're able to understand the business and speak to it on top of your domain as well.

[00:26:23] And I think the biggest advantage for designers is that we can help teams and individuals see the product more horizontally, and we can be the connective tissue that connects various teams and products together. This is another mechanism to show value to the team, and really help the teams simplify a lot of the workflows that they might be thinking about or designing. For example, at Databricks, one of the things we observe is that sometimes various teams are building similar functionality, and they might not be aware that they're doing that. As designers, we sometimes get to know about that early, through our design shares and some of the in-progress design work that we share with each other. A lot of times I've seen designers end up setting up calls between various teams and having them talk about, hey, how can we simplify these use cases a little bit more, so maybe we don't duplicate the user experience in the product. I think that can really help, and being the connective tissue also helps in building more reusable patterns in the team. That's where designers can also really help in these domains.

[00:27:49] The last thing I would say about this is that a lot of these teams want to involve designers, and often hear from other companies that involving designers is important, but some stakeholders might not know what that even looks like in practice. So depending on the maturity of the organization, and the maturity of your relationship with that stakeholder, you might want to share some artifacts that designers produce, or how best to involve them. Educate them as to how you would like to work with them and what the ideal working process is, and you would probably be surprised by how transformative these activities can turn out to be for the team. I would also say spend time doing retros occasionally, and keep giving them feedback. Let them know the best way to make the relationship work better, and be open to feedback from them as well.

Summary

[00:28:55] I know I talked a lot today, and I hope this was useful. Just to summarize what we learned today: complex applications usually operate in specialized domains, where users probably have broad and nonlinear workflows. As a designer working in these domains, you need to spend a lot of time on three aspects: one is the domain, the second is the users, and the third is your product. You have to be intentional in creating a learning path for all three of these areas. The other piece is that, as a designer working in these domains, it's a myth that you need to be a domain expert. It can be very scary, trying to become a domain expert in a very short amount of time; it's just not possible. But you need to focus on your superpowers: to be the voice of the user and help the team visualize concepts. And lastly, you need to build trust, understand the business, and again focus on your superpowers to be the connective tissue in the organization as well. So yeah, that's it for me, and thank you very much.