Madelein Taljaard, Experience Design Director for the Payroll mid-market sector at Sage Global, talks about the challenges and solutions of creating globally diverse software development teams with a human-centred mindset and culture to design and develop tools based on real user data.
Madelein does not manage her team of designers and developers, but rather collaborates with them to execute on projects. She explains how she does this and how the team goes about gathering data and interpreting this to create solutions collaboratively.
Madelein describes how the team conducts research and draws data from this research in a very rapid way. She says it’s important to get stakeholders to understand that research in this context should be quick so that you can rapidly implement changes based on research findings and test again.
In the exploration phase, it’s crucial to involve the people who will be creating the solutions later: to get them to empathise with users and grasp the importance of quality research; to make the data available to anyone in the team, for both current and future projects. Madelein shares some techniques she uses to ensure that the team is always thinking of the user first and that they employ the mindsets of design thinking.
Madelein shares some insight into how the team goes about low-fidelity prototyping and testing within the software development space. She also shares how she had to change her own mindset and thinking around low-fidelity prototyping.
If you are unfamiliar with design thinking, listen to episode 1, where we discuss the methods and mindsets of design thinking and clear up some of the terminology.
Welcome to Great Minds Design Think Alike. Where we investigate design thinking, the challenges, the successes and the problems it solves. If you are unfamiliar with the concept of design thinking, check out episode 1. Be sure to subscribe so you get the newest episode as it’s released. Great minds design think alike is hosted by Stuart McDougall, owner of Tenaka, a leading design thinking consultancy in Johannesburg, South Africa and is proudly brought to you by Mac Media.
The conversation with Madelein:
S: In this episode I’m talking to Madelein Taljaard from Sage. Where we uncover the challenges and solutions to create globally diverse software development teams. We have a human centered mindset and culture resulting in tools designed and developed based on the data from real users.
I’m here today with Madelein Taljaard. And she is the experience director at Sage. That’s Sage international?
M: Yes, that’s right. Specifically for our Payroll mid market section. Also involved in the small business segment. But yes mostly Payroll.
S: Awesome. And as far as I understand is you are managing developers around this product that you are doing for Sage. And what I was interested in chatting to you about today is how do you get your developers to start to empathize? Do you have ways or means of getting developers to empathize with the users? I know it through our discussions that we have had previously and also information that I have read about you and stuff that you have written. You are quite specific to making your team implement according to what the user needs or wants.
M: Yes, that’s right. So I don’t. If I managed developers, then it would have been easy. I would have told them. But you know, at the moment what I’m doing is I collaborate with them so the way we are structured in the organization right now just to make sure that we get a little bit more focus on design. We have actually created a separate design organization at Sage. And we collaborate with engineers. So what we are trying to do is to bring that mindset into the teams. If it was up to simply getting developers to change and to learn that would have been very difficult. But taking a UX designer and dropping them into a team and having them work with the team everyday. That’s a bit of a situation where they create opportunities that developers would have never have thought of. They bring in that mindset. So what we try and do is to make sure that we have representation in all the different scrum teams that we work with. We have got people with that design mindset. They have experience in the processes of exploring different avenues. Because when you work in an organization that was traditionally engineering led. Expecting the same people to just wake up one morning and saying, oh well today I’m going to think differently. It’s not gonna happen. You need people who already think differently and put them in there in mix to show them the value.
S: So those UX designers that you have got integrating into each of the teams. How are they gathering information from the actual user, people you are testing with in order to interpret that into how the execution is gonna come up?
M: So for us it’s really really important to do proper research. And a lot of times when I work with stakeholders and I use the word research. They see this vision of weeks and weeks of gathering data, analyzing data, and presenting data. And that’s not what it’s like at all. Research can be done very rapidly. You don’t have to research with your whole user base. You just need to understand who are the specific people whose opinion you need to solve the problem that you are dealing with. So if you understand who you need to work with, get their input and make sure that you spend a little bit of time. I mean if you look at how google does it. They can do all of that in a week. They can take it from research to prototyping within a week. So it’s not a long process. So we definitely try and identify who will be the right people to get input from. Set up an appointment. And most of the time because of how we are structured at the moment, it’s done remotely. So we use video conferencing tools. We record the videos that we have with the users which is great for transcription afterward. So we are able to then sit down quietly transcript the conversation and then take out the information that we require.
Something that is a challenge though is to make sure that you structure the data that you collect in a way that you could reuse it later on. A lot of times we do a lot of interviews with different users throughout the process of building software at different times. And although we might be looking for a specific solution at a specific point of time, there might be some valuable input that we need down line later. Let’s say six months down the line we can go back to that data and gather that data that we collected before. So it’s not always about having to go through that long process. The secret is to make sure that when you do collect data make sure you structure your result properly. And that you make it accessible. That’s the other challenge. Data isn’t only there for us to use at that point in time. It should be accessible to everyone in the process. So what i like to do is i like to invite engineers to join in the interviews. So i will say to them today we are going to interview a user about a specific problem. Here is the link to the video conference. Why don’t you sit in it? Why don’t you listen to what the user is saying because that also creates empathy? And once they have developed empathy, I mean it just starts the whole process of changing the mindset.
S: Those engineers are they seeing the benefits to that. Are they seeing the results so they get inspired by it?
M: Yes definitely. So sometimes they hear how things are changing and they hear that certain things must happen. So when we started this process they had this term of we have to develop with the user in the room. And some of them take it quite literally. So they will ask, so today we are going to work on this story. Do you think you can organize a user to come sit next to us? So that we can work with them. So I try and explain to them you don’t have to take it that literally it’s an expression. So when you design with the user in the room it means that you need to have an understanding. So you need to understand who is the user that is going to make use of the solution? You need to have some insights. I think the insight is more important, so I think the term having the user next to you having insight, having empathy, understand who you are building the solution for. Understand the problem. That’s one of the key things. that real true problem. What is the true problem that you trying to solve? And understand their needs. In building that solution. So what is the best way that you can fulfill their needs? So what we have done in a workshop once. It was actually quite entertaining. We had a couple of engineers with some of our designers in the room. And one of the guys said, well you know what we are supposed to do this with a user in the room, I don’t see a user here anywhere. So we took a piece of paper and drew a chair of a little old lady we stuck it on to a chair. We said well this is Mrs. Bennet she is our user for today. We will share all the data that we have about her. But she is sitting next to you. There you go. So yes sometimes they expect the user to be right there but they don’t understand it’s not about physically being there. It’s about knowing and having insights.
S: That’s excellent. So often we talk about these mindsets that we need to have to take these projects forward. And what we have experienced in the work that we do with some large organizations is there is this constant reminder to go say don’t forget to go back and be in that frame of mindset. Do you have any techniques to keep the guys constantly pulling back and making sure they using those mindsets? What sort of tactics do you use to do that?
M: So for me the most effective one is asking questions. So a lot of time when you are in a discussion and you are discussing this new requirement or this user story. People have opinions. So people are raising a lot of opinions, suggestions. Developers tend to think about how. How are we going to build this? And that is the key question in their minds is how. So what I try to do is say, instead of asking how are we going to do this, let’s sit back and say how might we? How might we do this? Instead of going right into the how. So let’s explore all the different avenues that we can follow to get to a solution to this problem. It’s like something I say to my kids a lot. To say I have got 2 little girls and they love Math. So they are always busy with some kind of math problem. And I say to them you know what? If the answer you need to get to is 10 the solution isn’t always 5+5. It could be 15-5. It could be 5×2.
Yes the answer might always be 10 but there are different ways to get to it. So why don’t we sit down and ask how might we get to 10? So that’s what I try and do with the engineers in these discussions as well. Stop, don’t just jump and focus on the how. Lets sit back and ask how might we? And another important question I always ask, I think I tend to ask this form my stakeholders a lot is Why? I always ask why are we doing this.
You need to understand the reason why we are going down a specific route. You need to understand why this problem exists and there is this technique of asking the 5 whys. To really get to the root cause. So it’s probably a bit irritating sometimes when I sit in the meeting and I keep asking why why why. But it’s effective because the moment you start asking questions people start to think. When they are in this problem solving mode and they are just going there, how must we do this? And then they are pressed for time. They usually go for the first solution. And that’s not what you want. And I mean when you are designing for humans you want you to make sure that you design the best possible solution for that problem. And also one that’s going to delight them. So questioning to me is probably the most effective tool. And my two key questions: how might I? And why?
S: So with getting to the point of having the data, understanding the user in this software development environment are you guys doing some kind of low fidelity testing as well then to take it to that next step? Just walk us through in the software environment how you utilizing that low fidelity testing.
M: Yes to me that’s very important a lot of times, so I only started this journey about two and a half years ago. So my background is actually product management. So I came from the product management environment. So I was always about viability. Is what we are doing viable for the market? Is it going to increase revenue? So it was very business needs driven mindset. So when I entered the project I’m working on at the moment and I had to change this mindset it was difficult. It wasn’t easy but eventually I got there. But when I first heard about, we have to prototype or we have to create these low fidelity wireframes, we need to put it in front of users. My first thought was, are you mad? You can’t go and show some scratch to a user and expect them to understand what you are trying to build yet. It’s crazy you have to show them the final product. To me it was nuts. How can you do that? It was unprofessional. But eventually, luckily I work with a group of very talented designers and I learnt from them. It was interesting because I was put in the position to lead them. But I actually allowed them to lead me. So I learnt a lot from them. And I can now really see the benefit of taking something that you are able to put together on paper. It doesn’t have to be something digital, it can be on paper and showing that to the user.
Because if you go to the user and have a discussion about how might we solve this problem? And these are our ideas. And you can’t show it to them visually and they can’t physically use it. It’s really difficult to get their true feelings about it. The other thing that is also important, when you have something that you can put in the user’s hands that they can use to solve the problem with, is that you can observe. Because what I have seen is what users tell you and what they do are two different things. So observation is really really powerful. If you can put something down and tell the user ok great the problem was that you want to generate a specific report so why don’t you go and use this and let’s see if you can get it done. By watching them, you can easily identify where they are struggling. But they won’t tell you. Remember people don’t want to admit when they are struggling. So they will think maybe if I use it a couple of times it will work. Or maybe if I had some training it would have been better. So they tend not to say out loud when they are struggling. But you can see when they are struggling with something. So I think that’s the power of having something that’s low fidelity. It doesn’t have to be perfect, it doesn’t have to be beautiful. It must work. So if it’s something that’s functional that a user can use to solve a problem. That you can observe them when they are using and that can give you power for feedback.
S: Well in our experience in that particular case, we found that the higher fidelity you go with your prototype, the less feedback they want to give you because they then sit as the user in the mindset of well this is an almost finished product or its a finished product. So there is not much I can do to improve it. Whereas if you enter with a low fidelity version they feel like if i change something it doesn’t really matter. I am gonna give my feedback and it will be really honest. So that’s been our experience in that area.
M: Yes, that’s true. And I mean if it’s on paper then it’s easy as you get feedback to say maybe let’s swap this around, let’s change something and see if it works better for you. Where if you give them a high fidelity prototype, even a finished product, it takes time for you to go and implement those changes and go back to them. So you lose the retention as well.
S: This project that you are busy working with at the moment, it’s not a complete project as yet as far as I understand. It’s not in the market as yet. Do you have any plans though once it does get into the market in terms of how your iteration process will work after its live and people are really using it? If you can give us some insight into that.
M: So we have been very fortunate that we were able to run what we call a preview process. With a few users for the past 7 months. So we were able to host a version of this software in a private environment and we had users that are willing to participate. And we have given them access to some sample data in our own environment and we gave them login details. And what we did was, we looked at what we build every month. Every month we deliver some value. We would ask ourselves: ok great, which of the items we have delivered do we really need to improve on? So we would go back to this user and say. Great, let’s have a quick conference, let’s have a video call and let’s log into the system. And we would give them a task. We will say so this is what we have delivered this month, we would like you to do XYZ. they would be able to do that using the live product and tell us, mmm you know its not great. The solution I’m using at the moment does it better. Sometimes they would tell us wow. One of the most positive statements we have had was that you have actually reduced a 20 step process to 3 and I get same results.
So we did that on a monthly basis. And we collected all that feedback. And we will go back to our stakeholders and say ok great this is what users are saying about what we have done so far. So the important thing is not only to listen to that feedback but actually then say, now based on what we know today what will the priorities for the next month look like? So that’s really important to then sit back and say, we had a plan, we have learnt something new, it’s time to reprioritize.
Do we maybe need to reiterate to do something differently or should we go down the path that we planned? So it’s important to build that cadence of collecting feedback, bringing it to your stakeholders, having a discussion about it and then saying ok great. Now that we have learnt something new do we need to prioritize? So the key is not to plan too far ahead. Or if you do you need to be able to adjust. So it’s important that when you learn you have to re access your priorities and you have to prioritize ruthlessly. The key is ruthless prioritization. You can’t say ok we have collected feedback we want you to do A B and C anyway so let’s just do this anyway. That’s not possible. You should never do that. You should say we had a plan to do A B and C but this new piece of feedback is really important. So what should we put down the back log, the low priority to do this instead or is it necessary. And that’s the important thing. Being able to work with teams that can do that and that are willing to do that. And that’s why I said earlier that the data that you collect should really be accessible to everyone. So that when your engineers are working in specific areas they can dive into the feedback and they can go and look at what we know about users and their problems. So they can also gather some insight for themselves.
S: You are touching on two things there because agile in this environment the way you referencing how you go about your development is very much the agile methodology. And then obviously the empathizing comes from the human centered design perspective. Have you struggled at any point or was it an easy move for you to get the human centered design methodology to work with the agile methodology? Are there complications there? I know this is something a lot of businesses are trying to do.
M: Yes. That’s really difficult. It’s really difficult to get the two to work hand in hand. And be effective together. It’s not something that happened naturally. I mean when you look at your agile processes, although people don’t want to believe that they are sometimes very structured. Although the word agile means being able to adapt to change, there are some structured processes that teams follow. So that’s why I always say when I speak to people about agile, my definition of agile is in the dictionary. To me it’s not about the processes or the ceremonies, yes they are all great tools to help you to be effective but to me agile really means being adaptive. Being able to learn and make new decisions based on what you have learnt if it’s the right thing to do. So I think that’s where the human centered design approach can link in. It’s that learning process. So if you work with teams you have to be very careful because there will be some true agile enthusiast listening to this. So when you work with teams who have a very much into a specific way of doing agile.
They might be into the scrum methodology or they might be into the canvas methodology or all these different methodologies. It’s very difficult for them to say ok so lets bring human centered design into the process and adapt it to work for us. Because when you look at those processes and methodologies they don’t really fit with what we are trying to do from a design perspective. But that’s why with the learning aspect that’s when human centered design can connect in very well. So if you can create this culture that’s what human centered design is at the end of the day. It’s not a process, it’s not a department, it’s not a person doing things in the corner, It’s a culture. So it’s a culture that you have to create within your team. So the moment that the team has this culture of learning adapting based on what we have learnt , that is when you can marry the two.
S: Yeah , I think you have put it well. That mindset and that culture overlaying the entire agile process means that your engineers and developers are all tapping back into the data. Tapping into what the user said, what the user needs and that’s where that link between the development in the agile environment is linking back to the human centered approach.
M: Definitely, definitely. And that’s why creating a design department or appointing a UX designer in a scrum team is not going to solve all your problems. That might just be the start of creating a different culture and creating a different mindset by just bringing in that person or that department into an organization that’s not going to solve your problem
S: So there is no silver bullets.
M: No It’s not a magic one. You need to allow them to teach people. How people see the value of what they do. Because once people see the value of what they do and you are able to have other people learn from what they do. It creates that chain. So it’s really important that you create that opportunity to have that culture embedded in to the team.
S: So that should be quite a big challenge for you. Knowing that your environment that you operate in is teams that are split across the globe. Are you able to communicate this and kind of keep that mindset fresh and people’s thinking and the culture going through the technology you are using to link everybody up? I mean is it possible?
M: Yes. I think the key is tenacity. You get frustrated sometimes because, let’s be honest if we look at Sage as a business. Where we come from we have been really really successful. In the desktop software, I mean environment. So we have built some really great on premise software in the past. We have been building native cloud solutions for quite some time as well. But as we now move into this new phase of solving problems differently, understanding the real problems of users, making sure that we focus on the customer’s experiences, not necessarily the needs of the business. So changing our mindset to an outside in. instead of having an inside out approach. It’s really difficult to take that same mindset and turn it around and have people think we work differently. And doing that in an environment where people are not all located. Where you have the challenge of them having to work differently, think differently. And now they have to use different tools to do their jobs.
Because you know I have to bring in tools that are collaborating remotely and also different cultures. That’s the big thing. Remember these are people at the end of the day. It’s not just resources, they are people. So you deal with different culture as well. It makes it extremely extremely challenging. So to me that’s why the key is to just tenacity. You can not give up. You have to repeat the same thing over and over again. You have to repeat. And find new ways of showing the value of thinking differently or doing things differently. It’s not a quick process, it really takes time. I mean just building a team in a remote environment is a challenge. One of the key things of building a team is having people relate to each other. So it’s really difficult to get people to relate to each other if they only see each other once or twice a day on a video call. If they have opportunities to have a discussion if they are talking about work. So there is no water cooler conversations. There is no socializing after work. So building those relationships is really really difficult. So it’s difficult to build the team in the first place. And once you have built the team you now want to start changing the culture. And it’s a long process. And it gets frustrating but it’s rewarding.
I mean I have started seeing glimmers of change in the last year. To the point where I had team members with a completely different mindset where they were so focused on technology first and today I can look at the same people and say wow. I can really see how they are now approaching problems with the user first mindset. I think you need to know what you want to achieve. And you need to find ways to show the value of what you are trying to achieve. Because if people don’t find the value, they are not going to buy in or try the new things that you are putting in front of them. So you need to find ways of showing them the value and just keep going on it. I mean I say to my team members all the time because they get frustrated and I say, i know you are preaching to the choir. You need to go out there and preach to the people. They don’t understand what we are trying to do. So yes if people are not open to learning its difficult so you need to first open their minds to being willing to change and learn and then you could start that process.
S: So thanks Madelein, I really appreciate your time and you have given a lot of value specifically in the software environment and how these teams can work and operate at a high level . Are you happy for people to follow you on your social media and see what you write about and what you are experiencing if you could, maybe if you can share the channels that you share content on?
M: Well I predominantly use LinkedIn for that. LinkedIn and Twitter. So yes. So you can find me on LinkedIn, Madelein Taljaart if you just go and search for me. And on Twitter my handle is Madeleinv01.
S: Ok excellent. Thanks Madelein, really appreciate it and best of luck with the project.
M: Thank you so much and thank you for this wonderful opportunity to share some thoughts.
S: You are welcome.
Thank you for listening to great minds design think alike. Give us a call to discuss how you can take design thinking into your organization to make life better for your customers or employees. Visit our website at Tenaka.com. Look out for our next episode where we will uncover more or simply subscribe. If you enjoyed this episode, share it.