How to say IDK (I don't know) in a technical product space!

Soundarya Soundararajan at UXDX Community: Open-Source Health and Being Vulnerable. Video: https://youtu.be/ZNCmliyU3lA

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.

Introduction: when everyone sounds like they're speaking English but they're not

[00:00:00] Super excited to be here chatting with everybody and talking through my experiences. If that picture was not big enough, I have another one here that's even bigger. For my introduction, apart from being a product designer, I'd also like to add a couple of other things, which is my soft skills. I love singing songs in languages I don't know, and I also love attempting handstands. I'm really bad at both of those things, but the one thing that I can confidently say that I'm good at is product design, and I absolutely love working in this field and learning from everybody. I'm very excited to be here to be able to share my experiences.

[00:00:41] So today we're really looking at how do we bridge the gap to build better products faster. One of the big things that I've had to face is about how I don't know something, but I'm working within a product team that's moving really fast and there are all these technical things that I need to onboard to very quickly. One of the ways I would say that you identify that you're in this situation is when everyone around you sounds like they're speaking English but they're really not.

[00:01:13] I can talk a little bit more about this. What I mean is that when people are talking around you and you understand all the words but they don't really make sense unless you're part of that product team, then that's a very good indicator that you're in a space that's very, very technical. For example, there's a product that we worked on that was called T-Vault, and the way we described the product was that it was to simplify the process of secrets management. Now I'm sure all of you know all of the words on this page, but what does it really mean?

[00:01:49] There was an explanation for it. They said T-Vault simplifies the access management of secrets by hiding all the integrity details. All the functionality available via the web UI is exposed via APIs, and documentation is available from within the UI. Again, we know all of the words but none of this makes sense. Maybe it might make sense to the people who this is targeted towards, but most likely this definition only serves the product team that's working on it and building it. What happens is it perpetuates this ambiguity around the product, which goes all the way down to the user, which is something we want to break down. That's what I want to talk about today. Here are some of the ways that I've helped break that down.

Break down the buzzwords

[00:02:33] The first thing I do is try to break down the buzzwords. This would include things like secrets. What do they actually mean? When they say secrets they mean credentials, and they mean this is a service that manages credentials. But what does credentials also mean in this context? They were talking about certificates and API keys and things like that. But asking those questions basically triggered a line of questions which helped us understand the product a lot more.

[00:03:04] Sometimes you might feel like, oh, this seems like a very basic question, I can't go to the product owner and ask him, hey, what does that mean, what does the secret manager mean? That is the most basic definition of the project. But I think what it does is it really helps get alignment for everybody in the room, and it also helps clarify things and solidifies your understanding of what you're working on.

[00:03:33] Another example that was used in this project was called CRUD. CRUD stands for create, read, update and delete. Now this is an industry-wide term for developers and so it was fairly universal, I would say. But I think as your organization becomes bigger there tend to be acronyms and abbreviations that apply only within those companies, and that's when it gets trickier, and you would only have it if you have historical product knowledge. So when you're coming in new, I think it's a great time for you to step in and just say, hey, I would like more clarity on it, and get that clarification.

Map it to the real world

[00:04:17] The second thing that I do is try to map it to the real world. For example, with Vault, Vault simplifies the process of secrets management. Cloud application developers use it to find credentials from that service to integrate it back into their code. But this is very hard to wrap your head around, and if I'm going to be designing it for people, I need to be able to understand it.

[00:04:40] So how do developers really use it? They basically go into this website and they'll search for keys out here and they'll click on it and they'll check if it's the right key, and then they'll copy it and put it back into their code. Now this was taking a lot of effort, because we noticed that there are a lot of issues with this. There are a lot of UI and UX issues within this, but data was also telling us that developers were finding it thrice as hard to find something. So if they were looking for a key they had to look for it at least two or three times before they found the right key.

[00:05:18] One really easy way that I found to map this logic back was using an example. Think of a messy drawer in your house, and you're trying to find a mailbox key, and when you're opening the drawer there are so many keys in there that it's going to take you at least a few times before you find the right one. That's kind of what was happening with the developers. Reframing it to this type of an analogy really helped simplify it and make it more consistent across all of the team to use it. So when we were talking about things and explaining even our solutions, it became way easier to socialize our thinking.

Build an "I don't know" doc, and find a BFF

[00:06:05] The third one is to build an "I don't know" doc. This is really building an FAQ for yourself, and this you can do when you have more time. Basically what I do is I maintain a document where I write down my understanding of the big questions that I might have. The reason why this was helpful for me was when I found new parts of the project that related back to the old project, or was based on the logic of older projects, it helped me make the connection between the two. It also helped me recognize when I was making mistakes. If I saw something that was documented earlier on and I realized, oh, my understanding of it was not right, I was able to go back and pinpoint where I was making a mistake and where the logic was breaking.

[00:06:54] The fourth one is to find a BFF. I would say if you're working in a super technical space and if you're in the tech industry, find a dev or find someone who's a technical person, because once they're your friend you can ask them all of the silliest questions and you can keep asking them questions again and again. I've realized that this helps you really build a relationship with them, and also over time I think it also helps build trust, and it shows your technical partners that you're more invested in understanding how these systems work and building solutions for them, rather than just thinking about it from an end experience point of view.

Channel your inner Bob Ross

[00:07:36] The last one is channeling your inner Bob Ross. I think one of the things that's very unique that we bring to the table as designers is usually our visualization skills, and a lot of times I feel like we have this power to really bring alignment to the team with just one document. For example, with T-Vault, one of the things that we wanted to show was around the site architecture and how it was causing confusion for the users. We talked about the keys and we talked about how it was very hard for them to find them, because they're looking for the keys in one drawer, multiple drawers.

[00:08:15] All the elements on the left are color coded, so each of those belong to the same units. All the safes are green, the service accounts are purple, but you can see they're in different places, and even the way this is organized really doesn't have a lot of structure to it, which helped show just how much confusion was being caused just by this site architecture. And so our proposal was to basically clean it up and make it very, very straightforward. This really helps cement how we thought about the product, and what we were pitching were not just UI solutions but really experience solutions.

[00:08:58] So these are the high level summary of all of the things that I covered so far. I'm happy to take any questions, but before that, after this is basically how we redesigned it. What we did was, from the before, we changed everything to long form text because we realized that a lot of the users were looking at the end notes to see which was the right key. And then we also changed the layout to a panel on the left instead of having it all up top, so that we can create more space, and then we also prioritized the search.

Q&A: asking basic questions when you feel like an imposter

[00:09:50] Host: Great. Is that literally a...

[00:09:53] Soundarya: I can go back.

[00:09:56] Host: No, no, I just want to hear anything specific in other spots. One question that I did have just going through it, and I thought some really, really good advice there about there being those acronyms that you just know when you've been somewhere, but the first time you hear them it's always kind of daunting. At that same time, when you're first hearing them, that's when people most likely have what people call imposter syndrome, so you're trying as best you can to look as competent as you can. So what advice do you give for people with, how do you overcome that fear of saying "I don't know" when you're also battling your fear of being an imposter?

[00:10:41] Soundarya: Yeah, I think one of the things that was very interesting for me to hear of late has been, I think when I was younger in my career I was really nervous about that too, because you're trying very hard to seem like you know what's going on and to not come across as like you're very new to the field, so that's kind of where it stems from. And I realized when I was talking to somebody last month, just that there are so many things where you might not know what the words mean but you know your process and you know how to be a good designer, and the foundation is there. You might not know something that's relevant to this project but you definitely have the skill set to apply the base foundation to it, and I think remembering that is very crucial.

[00:11:32] Soundarya: It's definitely very unnerving to be in a room full of experts and to be the person that's asking all the silly basic questions, but oftentimes I think it really helps bring about clarity not just for you but for other people in the room. Because most likely, if you don't know something, there is a high chance that someone else in the room also doesn't know it but they're just kind of afraid to ask those questions. So I think you should just own the moment and go for it and ask it, and you're going to be a better designer for it, or a better product person for it.

Q&A: publishing the "I don't know" doc as a cheat sheet

[00:12:11] Host: Excellent. And just talking about, did you call it a log or a diary, your "I don't know" log? Do you remember, because I've worked on a project where somebody came in and they took that initiative and we thought this is fantastic, so we actually published that on a kind of project wiki. The other people, whether it was a new person joining our team or other people who would just every so often interact with our teams, they found it a hugely valuable kind of cheat sheet. Have you ever done something like that?

[00:12:46] Soundarya: Yeah, there's actually a picture of it from the doc, but I guess it didn't show up in my deck and I'm not sure if you can see it right now on the screen.

[00:13:01] Host: Is it still showing? Yep, yep, I'm showing it now.

[00:13:04] Soundarya: Yeah, so this was basically the doc I built, but there are other docs that I built for each project. And you're right, ultimately I think that's what we end up using it as, as cheat sheets when people onboard to the project or they're onboarding to the company. They've often found it very easy to read from someone else's point of view, and not just something that's written as a help article, because we have access to those. But I think it goes back to just taking a human approach to describing these things, and I think when we write it to break it down for ourselves it often helps other people. It also, I think there's a lot of value and it's very powerful when you write something down, because it forces you to think about the logic of things and it forces you to capture those gaps that might be missing when your brain is just jumping in like 10 times the speed.

[00:14:02] Host: If anybody out there is just joining a team, I'd highly recommend doing something like this and then publishing it for everybody else to see as well. But yeah, the product looks great, because I know from my personal experience key management is a nightmare. I absolutely hate it, and I often do the worst practice of checking my keys into my code, which is a very bad practice, but they're private repositories, I don't share them. But hopefully, it is an area, I know AWS key management is a nightmare for me, so hopefully somebody can improve it.

[00:14:42] Soundarya: Yeah, definitely. Key management, yeah, that project was super fun to work on because it sounded so simple but it was so complex. Until we removed all the buzzwords from it and all the acronyms from it, and we were like, oh, this makes so much sense, this I can solve as a problem. But when we talk about getting keys and copying those over and creating new keys and finding certificates and all the privacy around it, when it's shrouded in so much mystery it just becomes overwhelming to solve. So I think part of the effort was breaking it down so it just feels easy to solve.

Q&A: zero knowledge, LastPass and who can see the keys

[00:15:29] Host: Actually that's a great point that you brought up there, and that I didn't touch on earlier. So this is probably quite a technical product and there are a lot of technical elements. What I mean by that is, and I'm going to reference the recent LastPass troubles, and if you're not familiar, they're a kind of password management service that got hacked recently and all of the customer passwords, encrypted passwords, were leaked. So when you were learning and designing about this, was that back-end zero knowledge concept, was that being discussed about how much access the developers themselves had, and how did you tackle that as a designer?

[00:16:13] Soundarya: Yeah, we actually looked at that too. We did a case study on what the different password managers did, and the ones that we looked at were the original HashiCorp, which is what T-Vault was based on, we looked at AWS, and we looked at LastPass. But we only looked at it from very much an experience point of view. So we looked at it from how are developers using this in their natural state, how fast do they want to use it and things like that. Because for example LastPass is consumer facing, but HashiCorp and T-Vault are very much technical user focused, and so they're not really spending a lot of time in there, because we want to preserve that time to write code, not to actually spend it looking for the keys. So we looked at LastPass for maybe the ease of use, but not so much from a technical point of view.

[00:17:11] Host: And did that pose, as a designer, because I'm assuming that with password management there's a big thing about the developers working on the code shouldn't even be able to see the password, so there should be zero knowledge of customer passwords. Did that level of complexity from a technical side ever become a challenge for you as a designer, or did that impact you at all?

[00:17:42] Soundarya: So there's a slight variation there, because LastPass is for, let's say, people like you and me to save passwords for multiple services that we're using, whereas T-Vault is pretty much for people who are writing code and they need to get passwords for the databases, so credentials for the databases. And so I don't think there's this, so much so, because it's not a consumer facing product, there isn't that much privacy and security concern, just because again these are all kind of being copied into the code itself. The other thing is also the users are not really looking at the keys themselves, they're just going to copy them, so they don't stand to really gain anything from those keys as well, or certificates. It's mostly to write code, and it's for software development basically, as opposed to LastPass which is more like maintaining passwords for services or logins specifically.

[00:18:56] Host: Okay, great. I was just wondering whether that was something that came up. But thanks very much for the presentation and the Q&A, really appreciated it. So yeah, thanks once again.

[00:19:11] Soundarya: Thank you for giving me the time.