Revolutionizing Marketplace Design: Strategies for Boosting Metrics Without Halting Progress

12 Mar19:00 – 19:30 UTCStage: Main StageTalk

Checking session availability…

Hang tight while we load the latest updates.

How did we redesign the biggest marketplace in the CES region (30M DAU) without stopping the product improvement

Revolutionizing Marketplace Design: Strategies for Boosting Metrics Without Halting Progress

Sasha Kalashnikov at UXDX Community: Leading Design Innovation: From Teams to Market Impact. Video: https://youtu.be/RR1e1KqYTcQ

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.

Who I am and what AliExpress is

[00:00:00] My name is Sasha Kalashnikov. I'm not a relative — it's so often the question. I'm a director at AliExpress. I was head of design, now I'm design director, but I'm still focusing on product design, so it's more or less always the same for me.

[00:00:23] Here is my photo, as I decided to speak about something. My past experience: I worked with those companies, and almost always I was a founding designer. My experience is to build products from scratch and manage all the processes. So now I'm at AliExpress and I'm doing more of the same, but at a bigger scale.

[00:01:00] About AliExpress. AliExpress is a global company, I'm sure everyone knows it, but in different markets there are different teams that try to localize it and make the best experience for different locations. AliExpress operates in many countries and we have 28 million, more or less, buyers per year. So it's a lot of people. It's a big product.

[00:01:45] I joined that company one and a half years ago, and we started that redesign I'll share later. We already won a bronze prize at a festival. For us it's a good sign that we do something bad — oh sorry, we do something good, that someone needs it. It's even bad for us, because we do everything in house. We have a small team and it's a big company, so it's a big challenge for that type of situation to have some kind of recognition.

[00:02:40] Today I'll share two topics. One of them is our design approach — we call it refresh, and I'll explain later why. And also some design organization things that really helped us.

Background: the year-long redesign before I joined

[00:03:00] Background, before I joined the company. Several years ago AliExpress already did one redesign. They had a lot of reasons why they did it, but we don't speak about that. We speak about how they did it. The whole company spent one year on development, so all the product managers, all the teams were involved, and in one year they launched new apps and a new website.

[00:03:41] It's a dream for a designer to join a company and say, let's do everything from scratch. So for some people it works. The benefits of such an approach: as a company, AliExpress got a brand new product with consistent pages, consistent flows, consistent design. Everything new. Everyone happy.

[00:04:21] The cons. It was really difficult for users, because even if the previous product was bad and you do something better, as you think, you just have their behavior and you at once change their behavior. A lot of new things, and you'll always have some bad reviews, and your users have to learn again how to use the product.

[00:05:05] The second bad thing was that all teams were focused on the redesign, not on new features. So one year later we had the same product but in a new package. It's good, but it's not great for revenue, for metrics.

[00:05:28] And the third thing: it's really difficult when you change everything, it's difficult to measure the impact of every part of the product. Maybe some of your solutions were good and some of them bad, but it's really complicated if you change everything at one time. It's huge work for analytics, and that's it.

The tricky task: a redesign without a redesign

[00:06:01] When I was asked to join the company, one of my goals was to update the design again. But at the time the company couldn't afford to spend a lot of resources again to redesign. So it was a tricky situation, because we felt that we needed some kind of update. We needed changes, we needed some kind of update in branding — and if we speak about branding, it always goes to product. So we needed some changes, but we didn't want to spend a lot of time and a lot of resources again to do the redesign. We had to do the design without a redesign. It was a tricky task.

[00:07:05] What we found out is the most interesting thing. We started from a whiteboard and said, okay, let's design everything we want, and we don't want to look at our system. Let's design the best marketplace we can. We checked the best products, we designed with design respect, and said okay, we want to be at that level and design without any limitation. It's just like a design challenge for us. We understand that the design has nothing in common with real life. We just dream about it.

[00:08:01] We designed it, we have our goal, and okay, somewhere inside we're happy. But designing something and launching something are two different things, nothing in common. And we realized that if you start to speak with teams about that future, we would have billions of meetings with a lot of product departments, where everyone would have their opinion and a lot of arguments about why we can't do that and that and that and that, and it would be an endless process. We would speak a lot and get stuck. But we had to move, and we had to save resources, because we don't have a lot of developers and we are a relatively small design team.

The approach: design forward, build backward, one element at a time

[00:09:06] So here's the approach we decided to try. We have our goal, we understand where we want to move. But we go back. We designed the new thing, then we go back and try to design the same but with the old design system. Test it, and then update one element by one element. It will be much easier, and we know how each element performs.

[00:09:52] I'll show an example. Here is our product description page. We have an idea where to move, so a design concept — I'll show it later, our beautiful future. We started from the navbar. The navbar is not connected just to the product description page, it is connected to the whole website, but we needed it for our redesign. We did it, and it also performed well.

[00:10:26] Then, our hypothesis was that if we move from two columns to three columns, our page should perform better, because we can show more information, and there are more chances that people will see something more for them and buy more. We designed that page with the old components, so everything is the same, we don't touch the UI. Then we checked it. It performed great. Okay, it was a green flag to continue.

[00:11:14] Then we started a new design system with new components, and started from small parts. So buttons: let's add new buttons and check how they perform. They performed great again. So it was again a great flag for all the other teams that they should not be afraid to use it in their parts of the product.

[00:11:51] And then we updated the other parts of the UI. It's small changes, for most users it's more or less the same, but we continue to update. What next? What next? Yes, check it, do a test, do some, blah blah blah blah — so the whole circle. Then the next part: we moved the title to the second column, more space for the image, a new layout, a new gallery design. Okay, we test it, blah blah blah, and step by step we go: update another part, update another, update one more time, check it.

[00:12:36] And then we updated the reviews part, added photos of the product, because it's a really important thing for buyers. So as a result we got a brand new product description page, but for customers it was a really smooth process. It's not like they open it and it's everything new. No, we updated it step by step by step by step by step, and we know exactly how all the elements in our page perform. So we have a lot of knowledge about how it works.

The orders page, and what the approach buys us

[00:13:19] One more small example. Here is the orders page. Okay, we think it's one column, let's move to two columns. Designed it, checked, and the result was that the second column didn't perform so well. It took a lot of space and had a lot of misclicks. So we continued but we stayed with two columns, and updated the design with small parts, and as a result we got a new page.

[00:14:02] Again, here is our approach to redesign without a redesign. It's not so fast, we do it in small parts. It's much easier for us to communicate with product managers, with everyone, because every period of time we improve one small thing, but we understand where we're going.

Design team organization: giving designers a part of the product

[00:14:30] That was the first part. The second part is connected to my previous thing, when we understand where we're going. It's design team organization. Here is a designer and here is a product manager. It's an example of a layout of some website and how it was before.

[00:14:52] The product manager came with a task and said, okay, we need to update this part of the page — a small task for a few days. We needed it yesterday, and we have limits with developers, blah blah blah, and please do it the best way you can. And the designer, with all the limits, does the best the designer can.

[00:15:36] Next sprint, the product manager asks for a new update. Then again a new task with a different part, again different limitations, different restrictions, different circumstances, we need everything soon. So as a result we have some kind of page with a lot of different solutions. Each time the solution was good for that moment, but as a result, when I joined the company I asked designers, please explain why that page looks like it looks.

[00:16:18] And the answers were: because of some kind of design system, because of weird product managers, because of developers, because a lot — because that part was designed by another designer, that part is not for me, that part is another team's. So: I work in that department but I'm really not responsible for everything, because I can't control it. And as a result no one is happy. Everybody understands that yeah, it's not the best, but what can we do, life is like that.

[00:17:02] So we changed that approach and said, okay, here is a designer. You're responsible for that part of the product. Today it looks like that. What it will be in one year will be your responsibility. We moved the designer to be an equal partner with the product manager. They work almost always together.

[00:17:33] We still have a lot of small tasks, a lot of small urgent jobs, but the designer understands that everything should be consistent, and the designer should push the design level to the next level. And the designer should find agreements with product managers, with the development team: guys, please, let's do solutions like that. If you don't have resources, that's fine, let's leave it like that, but understand that next week or the week after, please update that part, update that UI to our consistent design. So the designer understands what he or she wants to build as a result.

[00:18:29] The main goal is to have pages that the designer should be proud of. We have a lot of metrics, every product manager has their own metric, and everything should perform well — that will happen automatically. But how it looks, except designers, no one cares about. So we added this responsibility, and as I showed before, our designers started to think about the whole part of the product, and it worked. It works really great.

[00:19:15] Okay. A short speech, 19 minutes. Any questions?

Q&A

[00:19:22] Host: Thank you very much, Sasha, that was a nice, interesting one. I've got loads of questions in my head, but if anybody else has any questions out there, please do feel free to write them in. I'm going to start with a question from Dian. What was the thinking behind two primary buttons, for add to cart and buy now? Typically you have one primary and then maybe a secondary color, but you had a bright green and yellow.

[00:19:52] Sasha: Questions about why we have two, or about the colors? Why two primary colors?

[00:19:59] Host: So usually you might have one primary color button, which you want people to press, and then maybe a secondary button which is a bit more muted.

[00:20:09] Sasha: It's two different behaviors. Let's move to that page one second. Let's find it. Yeah, it's here. It's two different behaviors for different people. We have metrics, and people use it equally — we have almost 55% for both buttons. So we have no main one, and the reason why it's like that is because if you buy something — for example, you sit in a cafe and realize, oh, I need to buy some batteries, I open it, I click buy now, click it right now without checkout, just pay and forget.

[00:20:56] Sasha: If I use add to cart, it's for another type of user. It's when you discover something: I add to cart, continue scrolling, I find another product, add to cart, add to cart, add to cart, and then go to the cart and decide what to buy. So it's two different behaviors for different reasons. I can't say that this is our main behavior, this is not. That's why they're both equal.

[00:21:31] Sasha: It was a good point, because before we had — yeah, here is the original design. Here you had a red and a black button. The reason why: I asked the previous team, and it was because the system was like that, they had only two colors in the system. So they had three colors, red, black and green. They checked green — sorry, gray. They checked gray, and no, the gray button didn't perform, because it's gray, it's like disabled. So that's okay, we have only one color, let's use the black one. But for users, I had to think about it: they look too different, and which one to press? And we said, okay, those colors are close to each other, they're both active, and they both do almost the same action for users. So you press any one and you'll be fine.

[00:22:29] Host: Okay, great, great explanation. One thing that you touched on was a page that had been just organically created and it was a bit of a mess. Did you not run that risk of trying to optimize component by component, because a component that might work in a current design might not work?

[00:22:53] Sasha: Oh, you speak about that part, or when we started to update?

[00:22:57] Host: Well, I was referencing this, but I was saying, did you not have the same problem when you started to update component by component?

[00:23:07] Sasha: The problem, I think, is somewhere here. If you said those buttons were really bad here, it sounds ugly. It was one of the first things that was really complicated for me. Like, I can't agree with the design. I said no, no, no, it's not something bad, no, it's not consistent, we can't do it. And then we realized, okay, if you start to update by big parts, so all the components will be consistent with each other, it would be a super long process, because if you see that part, we have price, we have coupons, we have cash back. It's different products, we have to speak with a lot of people, they have their own metrics, we need A/B tests for everything, and we'd get stuck on it.

[00:24:07] Sasha: So we say, okay, honestly we're not happy with the previous design, so it's not good, but it will not be consistent for, I know, a few months. Okay, we can live with that, but as a result it would be faster with the new design. So it's like a compromise for us.

[00:24:29] Host: And even though it wasn't consistent, your A/B testing still showed that you were getting an improvement with this new design?

[00:24:39] Sasha: Yes, we had to prove everything with a test, because this is the only reason how we can communicate with our product team. We should prove that our design performed well.

[00:24:54] Host: And then I guess my last question: how did you sell that internally? Because the A/B testing I understand, but was there an argument that oh, it'll be cheaper just to do it all in one?

[00:25:11] Sasha: It's a topic, I think it's a topic for another meeting, how to sell inside. We had a lot of arguments. Not everyone was without doubt, because it's difficult when you come and do some big changes.

[00:25:39] Sasha: We did it together with a branding update. If I show you this part, it's from our new brand, so we have new icons, our new font. Everything here is our new future concept. We did some presentations inside, then we launched some small parts, then we had a lot of arguments inside the team. It was a lot of fighting inside, because what am I doing, guys, don't do it, it's something bad. And everything became better in a few months, when our new design showed good results after it. So you can prove that you do something good.

[00:26:49] Sasha: That's it. If you speak about some kind of opinion, like I think, I'm sure it's done better — no, it doesn't work. That's why we started with small details. And we have the new design inside the design team, and it's not a fact that it will be launched, so it's a long process: how to launch it, how to find agreements with product managers. We have to ask them, please do that and that and that, and product managers have their own KPIs, and we have to find something that will be good for them as well and for us as well. So it's a long process.

[00:27:32] Host: Brilliant. Well, thank you very much for sharing. That was a really interesting case study of the new design. I think personally it looks better as well, so I'm glad that the A/B testing is reflecting that as well. Thank you.

Speaker

Sasha Kalashnikov

Sasha Kalashnikov

Head of Product Design

aliexpress