Q&A With Anne Njoroge

Anne Njoroge at UXDX Community: Africa. Video: https://youtu.be/s5m3y-a-lWw

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.

Documentation without over-investing

[00:00:00] Host: Welcome, Anne. We're going to talk about your talk, which was about adapting your message and aligning internal stakeholders, which I think is one of those problems that everybody always faces when you're building a product. I'm just going to jump in, and a reminder to everybody out there: if you have any questions, just ping them on the chat or into the Slack channel, and I'll ask your questions to Anne.

[00:00:26] Host: To start off, your three points: reducing the chaos. One of your points was around documentation and the importance of good documentation. But I'm going to give you one of your own counterexamples, which was the Cazoo [?] site. You demonstrated how the look and feel wasn't right for the audience, and by changing the look and feel, it improved. What would have happened if you had over-invested in documentation on that design system for the old Cazoo [?]? How do you balance what you were saying about good documentation without over-investing before you've really got the fit right?

[00:01:13] Anne: I think the most important bit, where it all begins, is being able to articulate what you are addressing. Document that. And then bring in all the stakeholders to be on one page, in the sense that the product owner, the researchers, the UXers and the engineers are on board. Because for that particular project, what actually happened was we were having a shortage of designers at that point in our organization, and the product owner really wanted to launch very fast. Therefore they just worked together with the engineer.

[00:02:01] Anne: So you find there's this gap that was not being addressed that is specific to the situation and the case study that we are currently addressing. But my go-to advice always is to have everything in one place, one source of truth, where each and every person can point to it and say, "Agreed, this is the direction that we are going to move in together."

[00:02:37] Host: Great. Because with all the best intentions, whenever I've been working on a product, we do a lot of documentation up front, and then decisions happen, and things change, and whatever. We go back, somebody new joins, we say, "Look at the documentation," and then actually it's not quite as up to date as it should be. How do you propose teams try to always make sure that their documentation is as good as possible?

[00:03:05] Anne: First and foremost, have everything documented in one location. That is for the engineers and the designers. Secondly, have someone responsible for the documentation: one point person that you can all reach out to in case of anything related to the product. Most of the time in small organizations, it's the designer who's responsible for the end-to-end documentation of any given product. If you are the person, just stay up to date, encourage ownership, and take up ownership if you are the person and your workflows are not clearly defined, because someone has to take ownership and responsibility for any given project. And keep everyone updated.

Stakeholders who won't engage

[00:03:58] Host: I hope all the designers out there aren't cringing at the fact that they're in charge of documentation now. The other point that you had was bring everybody along. Have you ever dealt with, because I have, a stakeholder I just couldn't get? For whatever reason, they just didn't want to talk to me. I could never book time with them, I could never get into their diary, they always brushed me off, and I knew how important they were, and I kept trying to come up with different ways. To your point of bringing everybody along, what strategies do you have when the other party isn't really engaging?

[00:04:37] Anne: One thing I learned from a mentor is never get tired of asking. The reason behind it is people will start feeling guilty at some point, unless, of course, they are absolute douchebags [?]. But never get tired of asking. Just keep hitting that wall until you find a way to make progress in one way or another. At the same time, get to know the people that you're working with, and what's the best approach when you're dealing with this person.

[00:05:11] Anne: I remember there was a time we were having friction with one of the product owners of a project that I was designing. Later on, I came to realize it was a matter of speaking different languages. The moment we started speaking the same language, and, as the designer, I brought my ego a little lower, things started moving and flowing. So I guess there are also ego issues to address.

[00:05:45] Anne: For the designers and the product managers, to a given extent, you have to be the person who never gets tired of keeping that conversation going if you are going to make progress, and create an environment where everyone is feeling heard, everyone is feeling accepted, and there's progress. Because at the same time, people get tired when there's no progress, so it's important that you keep that tempo going. You are the energy; you are the driver of the product. If you have all the resources at hand, just keep ticking. Don't get tired.

Working with developers

[00:06:34] Host: Excellent. So on top of documentation, you're chasing everybody. The next point, going through your three key areas, is stronger relationships. You mentioned the dev and design silos that can happen in a lot of organizations. What are some tips that you would have for people who don't really know the devs on their team? How do you make sure that you're collaborating and on the same page?

[00:07:06] Anne: That's an interesting place to be, and I think it's inevitable when you are working on a huge project, and in most large organizations. I think the most important thing would be to keep channels of communication open, in the sense of having a dedicated Slack channel or group where you keep everyone updated on the progress. Just centralize everything, the key things that need to be communicated, and make sure everyone is in the loop, and there's a central channel where every person can get updates, even if you're in different time zones. Centralize that.

[00:08:01] Host: Great. And I guess in that channel, one of the points you made as well is that people have different languages. Devs will talk about things in a technical way; designers might talk about it from a design perspective. You mentioned that it's important to speak the language. How do you go about learning the dev language? What have you done?

[00:08:26] Anne: So far, I think it's just been befriending the different engineers that we work with. We have a very cordial relationship. Especially when you're working on projects, I always make a point to show up for events. If there's something happening at the office, I show up just to make that connection stronger. Over time, I've come to learn so many things about architecture, and also from working on side projects with them. When I get projects that are outside work, I usually loop in some of the engineers that we work with. Over time, I've gotten to develop that relationship and also broaden my learning curve.

[00:09:16] Host: Excellent. There's a lot on your plate, because it looks like you're the central hub of everything. But that's great, and it was a great example that there are a lot of activities people need to take on beyond exactly what their role on the team is. Thank you very much, Anne, for your time.