User Experience At Scale
Checking session availability…
Hang tight while we load the latest updates.
User experience is a crucial part of an agile team. In this talk, we will explore how UX design methods can apply to more than just designers.
We will also highlight the results of sharing the knowledge with project managers, Product Owners, Developers and Scrum masters.
Breaking the silos between the project team’s members, sharing experiences, UX philosophy to have a common language, should bring a better understanding of the product and accelerate the working process that would give better results.
User Experience At Scale
Nivin Al Kuzbari at UXDX Community: France. Video: https://youtu.be/aS6HQZJUK-M
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.
The UX philosophy at scale
[00:00:04] Thank you for having me. Hello to everyone, I hope you are okay and safe at home. Today I'm going to be talking to you about building a new UX philosophy at scale. Just a little bit about me and my background: I used to be an art director for a company that was based in London and Paris[?], and it's been two years that I have joined the bank Société Générale, and today I am the head of design there.
[00:00:41] The UX philosophy at scale, and as I mentioned it is a philosophy, because it goes deeper into three points. Which are: expanding UX mentality and methods to the product team; the second point is to design better user centric projects; and the third point is that it has to deliver more product. I will go deeper into these three points throughout the presentation.
[00:01:11] I'll be talking with you about agility and its process, the process that we have observed at the bank, the reasons why we are having this kind of process and its effect on the team and on the product. And then I'll move on into how we are trying to improve this process by presenting and introducing the design at scale philosophy, and then we'll go into details about expanding, designing and delivering, and then we go with the takeaways.
The agile process we observed at the bank
[00:01:52] Just a little brief about the product team. I think we all know that it goes from product owner, to scrum master, to the core team as developers and design. And the agile process is: we grab the requirements, and then we start the phase of design where the UX expert works and then the UI designer starts, then we go to the developers to do their own job, we test with the developers and then we review.
[00:02:34] Basically the agile process that we have: each sprint we go on two weeks of sprint. But in a bank that has been there for almost 150 years now, we're still having some difficulties. I'm not saying that we don't move forward with it, but sometimes we could observe some difficulties and some problems with our own process.
[00:03:01] Our observation with my team was that the process, our sprint, goes from requirement directly to the development phase, then testing, and then maybe they would add at the end the design phase, if there's a budget left or time left. And then design, and I mean UX and UI, and then we review it.
[00:03:35] Some of the reasons why we're having the design phase badly: sometimes there's budget restraint, either the project has started way back and they don't have any more budget, or they just don't have the budget. Sometimes product owners think that they could do the job of UX designers. When I say the job of designers it's like doing the interviews, collecting data, doing the research and all this stuff.
[00:04:17] And then we do have silos, so you will see we're going to be trying to break these silos. Developers, they all work very well together. UI designers, they work well together. The PO has his own ideas. But then when it comes to working all together, everyone starts being a little proud of his job and they don't want to really share with each other. And then there's a misunderstanding between the difference between the user experience designer and what he does and the user interface designer and what he does, and when the PO should call these designers, and in which phase and at which time.
What happened on one project
[00:05:09] This is an example of a project that we had to work on, and it was a big project. The PO had already thought of the project from A to Z, and without doing research, which left place to assumptions and changes. The PO thought that he could do everything and he had his ideas clear, and he started the development phase directly. This took two months, and then he called my team, wanted to include a user interface designer, and the problem started actually.
[00:05:56] Because the UI designer, he could see that there are problems with the workflow, because of course since everyone has his own job, we might not think of some areas like a UI designer would think of. Once we started this phase we started seeing that we have missing content. Every time we had to go back and ask questions to the PO, the PO didn't have time to answer us. Or whenever we presented from design, the PO goes like, oh yeah, I thought of this new idea, it's going to be great, let's try it.
[00:06:41] And then as well the phase of testing. Of course this is why we test, because we want to see what works and what doesn't work. But while we're working on the UI phase the development phase was already moving forward. So as you could see here, we are really redoing the work all over again, and we were stuck in one sprint, not moving forward, and we ended up with a product that wasn't that well thought out actually.
[00:07:15] And its effect, it affected the team and the product, because we redid the work for four weeks. Actually for more than two or three months we had just three working pages, because we had already started[?] the project and introduced the design phase really at the end. It ended up with an unmotivated team, they didn't want to work with each other and they didn't want to work on the project itself. As I mentioned, an average product quality, and a budget, the wasted budget that we had.
Expanding UX mentality and methods
[00:08:02] Basically this is where the UX philosophy at scale comes in, and this is how we are working to improve this process. The design at scale philosophy, as I mentioned at the beginning, starts with expanding UX mentality and methods to the product team. So what we did already is we introduced some online courses that everyone could have. Every year we chose around 15 courses and it was open to anyone who wants to join these courses.
[00:08:41] Two years ago we introduced the reskilling program, which is a 16-based[?] program where we asked people who wanted to change their jobs to come into this program with an idea of a project, and they learned UX design while doing their project, so they ended up with a project that they made from A to Z. So we had people from Theo's[?] to business analysts or the HR team and so on. In one month we're starting the third one.
[00:09:17] We introduced as well the upskilling program, the UX Connect[?] program, as part of the UX community that we have at the bank, where every senior UX designer would help and coach a junior designer to upskill the person. Then we introduced meetups. Every Thursday we have meetups where we could talk about how POs could work with UX designers, how scrum masters could work with web designers, developers and designers at all.
[00:09:55] And we did as well some big events. One of the events was called Adopt a UXer[?], which helps us to introduce more design at the bank and make people understand more what we do. The second phase of this expanding UX mentality and methods is we're going to be creating a platform, a platform that would take users assess[?]. It's going to have a step-by-step guide on how to design a project from A to Z, on different types of project and different needs, and you're going to be able to search based on your needs. It's going to have a toolkit and courses, courses as mentioned before.
[00:10:48] Throughout the toolkit[?], empathy for example is something like a soft skill. So how would you expand the UX mentality to everyone at the bank? How could we have this empathy as a human being? I know we do have empathy, but how could we push it further to better understand the end users, actually? And at the same time it's going to help us to create a T-shaped team, where everyone could work all together in order to help each other with each phase of the process.
Designing better and delivering more
[00:11:32] The second point or aim was to design better user centric projects. You could see here that without design at scale we could have six weeks of sprint instead of two weeks. I'll explain why in a while. And without design at scale we're having design by the end of the process, but with design at scale we're hoping to bring the design phase into the early stages of the project.
[00:12:07] And the third one is to deliver more product. As I mentioned, without design at scale, and if we keep this process as it is today, the sprint that should take us two weeks in a normal process is taking us six weeks. So we are saving, if we are able to expand this philosophy at the bank, I think every project would gain about four weeks more. So we will be able to create more and more projects based on user centric, based on research and so on.
Takeaways
[00:12:49] The takeaways of this presentation and this philosophy: I think it could be applicable to every organization, I think, because it's still a philosophy, it's a model of working and it's a state of mind actually, and how we could all share the same knowledge together.
[00:13:15] For expanding UX mentality and methods to the product team, it has to break the silos between the product. The communication stays open all the time. Every team member would understand each other because we're going to have a common language between us. At the same time there would be a live vision, because everyone would be in phase with every phase in the process.
[00:13:44] Expanded knowledge: so we could for example ask POs to help us conducting interviews, because on the platform[?] we were going to teach how to conduct, for example, an interview. So basically if we ask the people to conduct the interview it will take, let's say, 80% of the job from UX designers, but the 20% that's left is for UX designers to focus more on searching for the data, pushing further the result of it. We will have joint forces and I'm sure we're going to keep the team motivated for more and more projects to come.
[00:14:40] Design better user centric projects: we will have better thought out projects because it's going to be based on research and not based on assumption. We're going to be sure that it's going to be usable because we have already tested it, because we already asked users what they want and we were aligned with users' needs, and it's based on research. And zero rework, no time spent for nothing actually.
[00:15:15] And the third point and my last point is deliver more product. Actually it's time optimization. As I mentioned, instead of expanding the process from two weeks to six weeks, we're going to bring it to two weeks, so it's going to leave us four weeks more to create more projects and make projects benefit from a user centric approach.
[00:15:50] Optimize budget: we all know that budget today is a question and it always has been, so we better focus on that and respect the budgets, I would say. And then it's very important to accelerate the time to market, because as we know time has been changing so fast, the market is moving so fast as well. So the UX philosophy at scale would help us accelerate the time to market.
