Nazli Ceren Binyildirim, Fatma Urek Uludag
Transcript
Hello everyone, my name is Nazli Bin Yildirim and I'm working as an experience designer at ThoughtWorks in Berlin, Germany. And my invisible co-speaker Fatma works for ThoughtWorks Germany as well and she's a business analyst. Today she's not here with us and please accept her apologies. Unfortunately, because of a medical emergency, she had to stay home. And please bear with me because I'm not a business analyst, but I had to learn her part as well so that I would be able to talk to you. So there will be some reading from here.
I'm trying to find a way not to block this. Okay. So today I will be talking about user-centered analysis and design in Agile. And I think that you all are already using cutting-edge technology to create your products and services because it's already a requirement to stay in competition, but it doesn't necessarily give you a competitive edge because all of your users already expecting you to be using them. So it just lets you not fall out of the competition. So when you ask then what makes us successful, why people are using our products, how can we be leaders in the competition, the answer to this is user centricity and that's why I will be talking about it today.
The agenda goes as what are experience design, user-centered design, design thinking, what are BA and XD roles, how they fit in
Agile, BA and XD collaboration, the tools we use, why you should be adopting it in your organization, and if you have any questions at the end, we will have the Q&A. I have two definitions for you for experience design. The one at the bottom is from Don Norman, who is the guy who coined the term user experience. And with Jacob Nielsen, they have this organization and they know very well about the kitchen and behind the scenes of user experience design. And here his definition talks about your end users interaction with your company products and services. Here he adds customer experience to the definition as well because Don Norman knows very well that whatever you create as a product is not the only thing that you are offering an experience with. The entire ecosystem you are offering around this product is equally as important because, for example, your after sales or how your user finds out about your product is so important that if you happen to fail in one of those, your entire product fails and that impacts
the way your user sees your brand or company heavily. And recovering from that is not really possible if you are to come up with new products and services.
The second one is a Wikipedia definition. I'm actually highly surprised that Wikipedia has a very decent definition for that. And they are talking about processes, services, products, events, omni-channel journeys, environments. And they are also talking about cultural relevance here when it comes to user experience. So the most important thing that we see here is that as a user experience designer, I don't only get to design digital products, but I can go and design a new school system for a country, or I can go design the new check-in, check-out system of a hospital, or... Design the discoverability or how you see and experience a newly curated exhibition in a museum. Cultural relevance is equally important because what you design for a country is not going to work in another because all cultures and societies have their own traditions and habits and they process everything differently.
User-centered design, what is it and how is it any different than user experience design? I'm going to start with the definition of it. Jesse James Garrett is a very famous UX designer and according to him it means understanding what our users need and what they think, how they behave when they interact. With the things that we are designing with them and with everyday objects. So what we are doing basically is trying to understand what people need, why they need them, and what happens if those needs are not met and how their lives are impacted, and how can I create something that would change this entire situation. And how this is different than user experience design is user-centered design is not a job function. You won't see anyone saying, oh, I'm a user-centered designer because there is no such thing. It's just a mindset. It's a skill that you adapt to your user experience design or whatever design job that you have.
Design thinking is one of those buzzwords you were probably hearing in the past few years because people love to throw it here and there around all the time. But it's actually the most important thing that we are using as a tool when we We adapt user experience design to agile because it's highly iterative and highly collaborative and it's based on testing and learning from your mistakes and failing fast and gracefully so that you can recover from your mistakes as fast as possible. And the easiest way to explain it is actually using this quote from Einstein, which is, we cannot solve our problems with the same thinking we used when we created them. Design thinking mainly gives you this holistic perspective that lets you take a step back and realize that you are actually having a problem. And to identify the bottlenecks and why you are having these problems and how you can solve them.
This is one of the most famous process visuals that you will find about design thinking, I guess. There are gazillions of it. Most of them are pretty accurate. So whatever you want to choose to use, you are very welcome to. There is only one step that is missing that I will explain later as well. But what we do at ThoughtWorks to implement design thinking to our process is we start with empathizing and we spend the majority of our time empathizing and trying to understand who our users are so that we can create things that will solve their real world problems, hopefully. And to do so, we are using different research methodologies. We do interviews, contextual inquiry, participatory and non-participatory observation. We use diaries and so on. And during this phase, we don't do anything to define their problems. We are just trying to record everything that we can get from them. And during the define step, we are trying to analyze this data to see what these problems are so that we can identify their pain points. And here we are using Powers of 10, which is a methodology by Charles and Ray Eames. They are both industrial designers, but that's a great methodology. We use what did stand out to create. patterns and to be able to cluster the pain points so that we can create our features based on them. And we use other things like empathy maps and user journeys. In ID8, we use our research and insights and findings to be able to come up as many options as possible. We are not trying to find one perfect idea. Instead, we are trying to get as many people as possible so that we can brainstorm and have lots of hypotheses. Because during the prototyping phase, we will try to create designs or solutions for as many of those solutions as possible that make more sense to us. And for prototyping, we use different levels. Well, the basic ones, low and high fidelity prototyping. We use low fidelity prototyping when we first start working on a feature when things are still fresh, so that testing the layout, visual hierarchy, and the basics is cheaper, and that the more we learn about it, we start working on high fidelity prototypes. Then we go to testing. I believe everyone here is already doing agile, so I guess I don't need to explain testing to you. Am I right? Okay. And the last step, which is not here, is retiring. If we get enough feedback to see that Also, data analysis shows us that people are not using certain features anymore. It's time to retire them so that they don't get more expensive than they should be. And the main reason that we are using design thinking is, to be honest, not only to adapt user experience to Agile, because there's this very famous belief that designers cannot do Agile, that we love waterfall, which is such a lie, because even user experience in its... Basics is iterative and it works perfectly well with Agile. But the main reason is the thing that happens very often is your CEO, CTO, one of the executives come into a meeting and say, oh my god, I have this terrific idea about this new future and it came to me while I was in the shower. So we try not to do this, we don't believe in this because your executives generally when they do that, they don't know if this idea is actually going to work. You need to test your idea, you need to create solid hypotheses and then to actually test them in real life to see if people actually really need them or if you are doing something very expensive and useless, which is mainly a luxury.
Here I'm going to talk about how we work together with business analysts as designers because we look like two different functions which is not very much true because our functions overlap very often. BA book which means business analysis body of knowledge has different definitions for it well different versions for the definition of business analysis. The second one says that it is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies and operations of an organization and to recommend solutions that enable the organization to achieve its goals. So here it sounds mostly related to business itself and not to many other things. It says stakeholders once there, but when you see the rest of the definition, you can say that there is no flexibility. It doesn't necessarily look agile. It doesn't sound like teamwork. It's just focused on the goals of the business itself. When BA Box realized that the time is changing and the user requirements are changing and doing what we have been doing for so long is not working anymore, they started even changing definitions of our
job titles and what is expected from us. So the third one says, it's the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. This already sounds like collaboration with design. This already involves a little bit user centricity than it used to. And it says it enables an enterprise to articulate needs and the rationale for change and to design described solutions that can deliver value. It's talking about value and users.
So here how we are working together in Agile. This is drastically different than how we used to work in Waterfall because in Waterfall they used to finish their work, hand it over to us, then we finished it, hand it over to developers and no one really knew what the other one was doing. It was a lot of paperwork, a lot of documentation. Here as designers we get to analyze business requirements, user requirements and technical requirements as well because we need to do what the rest of the team is doing and what they will be able to do so that we create relevant designs for everyone and that there is no communication gap between different functions and we don't work as design team, delivery team, development team, whatever, but we have one team which is the delivery team with multiple functions. And here also business analysts get to have a bigger picture of design because they can help us with research for the first time they get to understand their users and walk in their shoes and then they can come up with more relevant business requirements and we get to write the stories together so they get more empathetic about the situation as well. will be able to do so that we create relevant designs for everyone and that there is no communication gap between different functions and we don't work as design team, delivery team, development team, whatever, but we have one team which is the delivery team with multiple functions. And here also business analysts get to have a bigger picture of design because they can help us with research for the first time they get to understand their users and walk in their shoes and then they can come up with more relevant business requirements and we get to write the stories together so they get more empathetic about the situation as well.
Of course the green one is the designer because we are seen as these peculiar weird people that cannot communicate well with the rest of the world since we are very creative and the little one that looks like Thor is the business analyst since they generally seen as the ones who say the last word.
But that's of course a joke. We work very well because like I said we work as one team. But as mentioned before our roles overlap a lot and we try not to step on our toes and see things from different perspectives. Because the BA tries to look at things from the business, using the business lens, while I try to look at things while using the lens of my users. And here, for example, some of the things that I need to do to be able to do my job is doing user research, stakeholder interviews, personas, prototypes, coming up with
features, drawing the wireframes and the user journeys. And the business analyst comes up with business requirements and defines the roles and goals and draws a product roadmap also. Works on the business plan and then writes user cases and scenarios. But in order for us to do some of those alone or together, one of us needs to work on other things before so that we can come up with our own tasks and we can collaborate as well. For example, if we are to sit together and write the use cases and scenarios, at least I need to have created some sort of proto-persona. Or if I need to start working on my wireframes, I need the BA to have finished business requirements and I need to know a little bit about our technical specifications as well, again for relevance purposes.
This is...
Kind of a realistic or semi-realistic timetable for our inception. Since we are an IT consultancy, we are using the inception to be able to sell our project to the client. So this might be different than what it might look like in your organization because our end result here or our goal is to be able to sell it. So what we do here is I start working on stakeholder meetings to see their organization and I do the initial user research and learn about the client processes and the BA works on business requirements and defines roles and goals and we feed each other with information because it has importance on our individual tasks as well. Then we get together and we start working on the project vision and strategy and write the feature list and we start prioritizing them. And then depending on who your BA is or your XD is and project needs and the workforce you have in the project, I or the BA might come up with an MVP definition and then start working on the process flows. Then we get back together and we start writing the Epic Sun stories. We start creating our user journeys when we write our stories. because they give us more insight about our acceptance criteria and we are able to provide more details when we write the stories if we have the user journeys at the same time, at least some basic initial ones. And we start working on the feature map as well. Then I start prototype planning and the initial prototypes of the key features. If we were not a consultancy, I wouldn't be working on the initial prototypes here, but I need to be able to sell this at the end of the inception. So that's why I start drawing them now. And then the BA starts working on the release planning. Then we get back together and we do the iteration planning.
Here the assumption is that we sold the project, of course, because we are so great. And during iteration zero, of course, we start doing mostly infrastructure related stuff. That's why I do a lot of user research and I start creating my hypothesis. And then I do research again to validate them, fix them or kill them. And then this cycle just goes on and on until the end of the entire project. And the BA starts working on dependencies, cross-functional requirements, and system integration. But at the same time, we also start working on the in-depth story analysis, writing the acceptance criteria, and we detail our user stories. Then I start gathering all branding related things from our client and then I start working on the information architecture, taxonomy, content strategy, user experience copy. And the BA works on business constraints, laws and regulations. Then wireframes, UX artifacts wall so that the design is very visible to everyone and the entire team knows what we are doing. Interactions, user interface, prototype, style guide. During these tasks I always do desk checks with developers and QAs during iteration zero so that they know what's ahead of us. And while the BA works on story mapping and doing the iteration board and the narratives and users, She does desk checks with them as well. Again, to feed them with information. We work very close during all these phases, so we don't do desk checks because it's like a full-time desk check for us anyways. And then I finish the iteration zero with user testing. Revisions and updating the UX artifact wall and at the end of the iteration we have the showcase on the retro of course. This is just any iteration during the project. It's basically the same except we start with a team kickoff at the beginning of the iteration and then we of course finish it with a sign off. And the experience designer is always involved in the kickoff and sign-off. If the story has any sort of user experience or user value, and most of our stories have some sort of user value, so I'm a part of almost all of them.
This is... Again, a semi-realistic time plan where you can see the orange one. Aha, you cannot see it, I guess. Well, there's a line here. I don't know how much it's visible. This is the orange one. It's collaborative sketching and ideation. We don't only do it as BA-XD collaboration, but we generally invite our developer friends as well. Or if it's possible, we are inviting our users too so that we can get more insights and more ideas about what we can do. This is the red one, which is iteration planning meeting. After we come up with our initial designs, we start planning the next iteration. Then we start working on user research, hypothesis validation, and wireframes, also story writing and acceptance criteria. And I do user testing while the BA does user acceptance testing. And then the entire thing goes on and on.
I'm only going to talk about three of our favorite tools. We are using many of them, but these are the most important ones, I guess. And the first two ones, of course, since I'm not the BA, I don't know about them. This one is the business model canvas. We are using this mostly to come up with a strategy for
for the entire project. It's a lean startup template and it is used for
documenting new businesses or the ones that already exist. It's always better to fill in those nine building blocks in this order, as much as my colleague says.
First, the customer segments. Second, value propositions. Third, channels for customer relationships. Five, revenue streams. Six, key resources. Seven, key activities. Eight, key partnerships. Nine, costs. Although I... I don't really use this myself since it's a tool that we use in Inceptions. What I've seen so far is that this is really important to understand what your customer or maybe in your case what your business is doing and how you are functioning. And it helps you have a better understanding of your users and how they relate to your business as well.
And we use value proposition canvas as an extended or zoomed in version of the previous ones to different building blocks, which are the value proposition and customer segments. What we are trying to do is that All these three different blocks in the two of them, they are related to each other. They are basically the same thing, but it's more like the one on the right is for the user. The one on the left is what you are offering them. So you need to make sure that what you are offering them is a match with what they need and what they want from you. If you have the perfect match, then you might have some sort of confidence that you are creating the right product. Of course, if you are objective when it comes to trying to understand if it's a good match or not.
The next one is the user journey map. I am using this to come up with a strategy for the entire product or bits and pieces of the product. And here you can see different stages and the touch points. How does the user learn about my product? How do they sell it, buy it? How do they use it? Do I provide them with any after sales? And how do they feel? What do they think during any of these stages? As I said, this is really important to use while you are writing the stories if you are not doing it with your intended or your happy path, but to analyze the current situation because it gives you a lot of insight.
So as you probably all heard this like five million times before, it's outcomes, not the outputs. We shouldn't worry too much about the artifacts and what we are creating as deliverables, but what we are creating as an outcome, what sort of value we are creating and the quality of our work is more important. So this is why we are doing this entire thing together so that we can understand the users and the business better so that we can feed and grow each other so that we can become better consultants as well. I'm not going to talk about the chart on top, but only about the one at the bottom.
Oracle ran this research in 2013 and they asked the same question in different ways to users or end users and to executives. And the question is, do you think a user would stop using your services and products if you were to offer them a bad customer experience? Or have you ever stopped using a service or a product because you didn't like the customer experience? The executives, 59% of them said yes, they would stop using. our products and services. Apparently 41% of them don't really believe in that, while 89% of customers said that they have already changed their providers due to poor customer experience. So this has one good side and one bad side. Amount of executives who see the reality is higher than the ones who don't. So this is great because 10 years ago if you asked the same question probably the percentage wouldn't be 59 but maybe 29, 39 because they didn't necessarily care about what their users wanted. The competition wasn't the way it is today and they were not really aware that the customer had some sort of say over what they are doing either. But on the other hand, the bad thing is 51% is still a very high percentage and This wasn't too far ago, it was four years ago, almost five years. So it is also still kind of sad to see that we still have blind people who do not understand the new realities of their own business.
The most important thing most of those executives fail to see is that if you are creating a new technology product and if it's not a business to business kind of tool, most of our users nowadays are from Generation Z and they are so different than all of us. They are very different than my generation as well. And I'm having a very difficult time to understand them as well because they are technology natives and it's almost like they are speaking a different language than you are. So they are obviously a lot more comfortable with technology. You hand them something and in two seconds they know how to use it while you look at them like a monkey trying to figure out how the very basic thing works. They have a very shorter attention span. You need to engage them very quickly, otherwise you lose them mostly forever. They prefer online shopping, mostly mobile. They are more knowledgeable and as a result of that, they are very... Difficultly impressed. Whatever you do, they generally don't like it unless you offer them some sort of new generation interaction or something really interesting that they haven't seen before, which is very rare anyways. They are very heavy users of Facebook. They really like videos. They don't like written content. If you give them anything to read, they won't do it. If it has audio, video, they will love it. They are multitaskers. That doesn't necessarily mean that they finish any of those tasks, but they will try to do multiple things at the same time. They are less concerned with money and another very important thing is that they are really fine with giving up their online privacy if you are offering them a really good benefits, a very engaging interaction.
Here, actually most of those are still kind of related to the first chart that I showed you, the executives versus the customers opinion thing. Another important thing to see here is that this is mostly related to the 59% executives part of it, because this entire evolution is about businesses who realize that customers'needs and what they want is changing. When we used to produce our products and offer them to the customers until 1960s, we used to just sell them in certain places and the customer used to go there to buy them. But between 60s and 90s, what happened is the company started providing the product where the customer needed it. So people were... More able to reach and access different products a lot easier than before. In the third stage, what happened is mid-90s and 2011, every product was, not every product, but most products were as ubiquitously as possible provided in most places. Probably this is so much related to internet and the first times of heavy use. of internet when people discovered how to order things online or how to look up for things online and in the fourth stage the company knows what you need when you will need it and where you might want to get it so everything is a lot easier and everything to buy and everything is a lot more accessible nowadays and
The last thing is how, if you are convinced that you should integrate user centricity or user experience into your organization, how you can do it is the most important thing to do here is to make everyone understand that it's actually very important because
It's a team game. You cannot do it alone, but you still need champions and evangelists. And you need to come up with a good design or user-centered strategy so that you can share the news with everyone and you can make sure that everyone is on the same page and you are moving towards the same goal and you all want to achieve the same thing. Another important thing is to making the knowledge and resources shareable and accessible because not everyone knows about it and they don't know where to get the information either. And you also need to stay true to your word, of course, only saying that, oh, we will do this. things will be amazing is not enough, then there needs to be some effort to really try to create the user centricity and to apply it to your work so that everyone in the organization and also your users see that you are honest with this and that you are doing it as well.
In conclusion, which is very similar to what I said at the beginning, user centricity is the most important thing that you can use right now because the technology is always evolving and you will always have to use the newest things that are used in that time while you are producing your products.
The only thing that will give you the competitive advantage at the moment is using user centricity, is understanding your users, is understanding who they are, what they need and trying to answer their needs.
And that's all.
Thank you.