Adapt Your Message & Align Internal Stakeholders

Anne Njoroge at UXDX Community: Africa. Video: https://youtu.be/wWUjvMWqkQE

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 stakeholder coordination decides a product's success

[00:00:00] Hello everyone. My name is Anne. I'm part of the design team at Africa's Talking, where I work as a UX researcher and designer. Our overarching goal in the design team is to ensure that we give superior experiences for the products and our customers. That is for the different products that we have in place, which are SMS, USSD, airtime, IoT, voice, and the different ideas that we usually innovate in our incubation lab.

[00:00:43] Today I'm going to talk about how designers can work in a more meaningful and progressive manner as they engage with the different stakeholders in building the products that they are building. The workflow is variable depending on the organization that you're in. You find that in small and medium organizations, designers usually double up as the project managers or product owners. So there's a lot of responsibility in ensuring that the product is developed successfully end to end. That's why you find that the dynamics of the relationship between the different stakeholders involved become a key determinant in the success of a product.

Two case studies: Kazo and Wiqual

[00:01:48] To set us off, I have two case studies that had very interesting first iterations, just because the different stakeholders were not coordinating. The first one is Kazo [?]. Kazo is an idea that was incubated in the Africa's Talking innovation lab. It is a security platform that offers OTP for authentication on mobile and web for fintechs. The first iteration was not communicating the brand as it ought to have. You find that it had a tad more playfulness than it should. Because of that, when it launched we had a hard time getting buy-in from the target market. The second iteration was received in a better manner by the market, and we are glad that we are getting higher conversions and higher expressions of interest in the different markets where we have launched the product.

[00:03:00] The other case study that I have is Wiqual [?]. Wiqual is an e-learning platform where students are mentored by their parents and mentors as they undertake different projects. In the first scenario, because it's the students who are very keen on building, they're super excited to just ship and go to market. This is what we had for the first iteration. Unfortunately, as much as, yes, we did have a product on the ground, we were having a hard time getting conversions. The kids were having a hard time going through the different modules that we had in place, and we had to redo the whole thing.

[00:03:51] That is when we had this designed. This is still under development, but a few pages have already been executed, and we like the flow in the user experience, because the kids are saying right now they're having an easier time going through the different modules that the e-learning platform has to offer. They're also getting the kind of response, and they've managed to secure the attention of the target market that they had intended. That is people in Africa, a few Kenyans, and also in the States.

Reducing chaos

[00:04:31] I'm going to share three strategies that I have seen work and have adopted in my work processes, just to ensure that all the stakeholders are coordinating nicely and are in sync from the get-go. The first one is reducing chaos. The second one is working to better your relationships. And thirdly, learning to speak the language as a product designer or manager.

[00:05:00] In reducing the chaos, I think this is where a lot of work goes in. They say that great design is a product of a lot of intelligence. So this is where you need to bring in everyone and ensure that every person is bringing in their strength. First and foremost, ensure that the strategy is clearly defined, that the problem you are solving is clearly outlined, and that every stakeholder involved, from the product owners, product marketers, the engineers, everyone, can articulate clearly why you're doing what you're doing. Don't jump into building a solution if the problem is not well defined.

[00:05:56] Ensure that everyone is on board. Do your due diligence in getting the persona clearly cut out, and the features as well. What are you building and why are you building it? I remember there's a product we were building to support customer onboarding. It's called Krayem [?]. We had to iterate that product close to four times. It was a huge product, and it took us about six months to just have the first prototype on the ground, and there was a lot of leakage of resources, both on the engineering side and on the design side of things. The reason behind that is because we were not speaking the same language. We had not clearly defined the problem that we were solving and the features that we were going to build to support this.

[00:06:54] The other thing that you need to have in place is great documentation. This one goes a long way, because it ensures that you're communicating the dreams and the purposes of the product to all the stakeholders in a unified manner. So your design system, which can be the style guides, the conceptual models, the component libraries and the various use cases that you have in place: ensure all of them are well written down and placed in a folder somewhere where the designers, the engineers and the product marketers can easily access them.

[00:07:43] This is also important because it goes a long way in securing the future of the products. When you have newbies being onboarded, it becomes very easy for them to come up to speed with the set systems for governance and get to building, as opposed to starting to learn and wasting time looking for resources that could have been easily made accessible if the people who started off had put in effort in ensuring that documentation is well captured and filed.

Working to better your relationships

[00:08:25] Lastly, make an effort to bring everyone on board. We are here to collaborate, and it's never too early to start working on that relationship. A superpower that all designers claim to have, or claim to be working on over and over, is being empathetic. So I would implore you to use that superpower as you are relating with the different stakeholders that you are working with. We're humans first. So put effort into getting to understand the different personalities that you are working with.

[00:09:10] With most engineers, you find that they're more analytical, logical thinkers compared to an average designer, and that is well expected. So learn to empathize with where they're coming from: the different personality styles that you have in place, the phlegmatic, melancholic, sanguine, and the thinking processes. As you're interacting with the different multidisciplinary teams that you find yourself in, put an effort into learning the people, just to avoid unnecessary friction. It will also help you to draw the best out of your teammates, which is what you want.

[00:09:58] You want to build an atmosphere where people can hear one another, because as a leader, you don't want to be surrounded by people who do not speak because no one is listening. At the same time, you want to build trust and an atmosphere where everyone feels valued and cared for, which will make your dreams and your work process as a designer very easy and smooth. So if there's a lunch to be attended, or evening parties, make a point of showing up to whatever it is, and nurture that relationship with the various stakeholders that you are working with.

[00:10:42] At the same time, make a point of getting comfortable with conflict and disagreements: knowing when to push back, when to give a listening ear, when to be the mediator. It goes a long way if you can put in a little bit more effort in knowing how you can resolve conflicts of various natures, or argue in a constructive manner with the engineers, without coming across as aggressive or someone who doesn't care about others.

[00:11:20] A consideration you can work on as you're building the relationships in your team is ensuring that you have smaller teams for the different projects that you are working on. This will help in making communication more efficient and reducing the communication feedback loop. When we started out building Elarian, we began somewhere in Q2 of 2021. The whole design team and the engineering team were spread out, and this was taking a toll on all the engineers and the designers. You find that the development process was slowing down.

[00:12:10] It got to a point where our management decided to divide the teams. We had a team that was fully dedicated to Elarian and another team fully dedicated to Africa's Talking. When that was done, the development process sped up, and by the end of the year we were able to launch Elarian, which is a new product by Africa's Talking. We still have dedicated teams for the different products. It helps in hastening the process of building and making communication more efficient across the board.

[00:12:54] Also, as you're working to build and establish that relationship, ensure that you have a working rhythm. Having a working rhythm means establishing how you're going to manage the various expectations on the ground. You have design work: when and how do you expect it to be shared? What design decisions need to be made fast? You need to understand what's reversible and what's not reversible. And also have it on paper how often you want to review the milestones that you have in place.

[00:13:35] As a designer working with engineers, you need to communicate effectively the different designs that you have in place. So if the engineers want user flows, if they want prototypes, the different interaction patterns that are required, ensure that is well communicated and agreed upon. That also depends on the software that you're working with, because if you're working with Figma or Adobe, you'll need to have different platforms and different channels of communicating that and also storing that. So that needs to be agreed early on. And then get to know how the handover is going to be done from one team to another.

Learning to speak the language

[00:14:35] Lastly is learning to speak the language. I come from a background of chemistry and biology, before I came into tech three years back. So I really had a steep learning curve, but I had to put in effort, because I realized it does go a long way if you put in effort to understand the craft, the technical requirements and the jargon in place. As you're designing, you need to have a deep understanding of the different features that you are suggesting or building on the front end and on the back end. What is the estimation? How many resources are required to build what you are proposing? What are the technical constraints in place?

[00:15:31] That understanding is very pivotal, because it helps you manage expectations across the different stakeholders that you're working with, the product owners and also the engineering team, so there's very little friction as you're working. At Africa's Talking, we work with sprints for the different projects and products that we are working on. For the design team, we usually have a weekly catch-up. Then for the different products or projects that each designer is assigned, you find that they usually have weekly catch-up sessions and bi-weekly catch-up sessions, just to ensure everyone is in sync and there's progress as we're working together.

[00:16:31] So from the three things that I have mentioned today, reducing chaos, working to better your relationship with the various stakeholders, and speaking the language, the tech language in your respective industry, I hope there's one that you can pick and apply right away to upgrade your relationship with the various stakeholders and engage in a more progressive manner. Thank you.