Designing Mature Products

Janina Jungiewicz at UXDX Community: Europe East. Video: https://youtu.be/-FmP84JECm4

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.

Voluum and the report table

[00:00:00] Hi, my name is Janina and I am a product designer based in Krakow. For the past three years I have been working at Codewise on a SaaS application called Voluum Tracker. Today I want to tell you a little bit about my experience of designing a mature product. To give you a context for what I'm going to talk about, I want to tell you about Voluum. Voluum Tracker is an analytical SaaS solution that allows for tracking, optimizing and automating advertising campaigns. Currently it's the most popular tracker on the market dedicated to affiliate marketing.

[00:00:42] Voluum is also a product with a rich history. Its development started in 2013, so a lot of people have been working on the product since then, and through these eight years different approaches have been taken to develop it further to our users' expectations. And through that time we have also accumulated quite a lot of debt, both technical and related to design.

[00:01:14] I don't want to go into too much detail on what affiliate marketing is, but for the purpose of this presentation I think it's really important to understand that Voluum is, and has always been, a tool centered around data. It is very crucial for users to be able to get accurate data, often in large volumes, with additional tools that can help them interpret that data, so they can draw the right conclusions and further motivate their advertising decisions.

[00:01:49] The table has been the centerpiece of Voluum, and as the product grew bigger in features, all the new additions had their button representation added above the report table with data. To give you an example of what this means to our users, let's assume that we have a screen that is 640 pixels in height. The table in this example is around 57% of the whole screen. So far so good. It's not the best, but it is okay for our users.

When each new feature takes space from the table

[00:02:26] Now let's say we have developed a long-awaited feature called notifications. We wanted our users to be able to add notifications from the report table, so a Notify Me button was added above the table along with the other buttons. And this is what happened, and it's a real-life example. The buttons didn't fit in one line anymore, so the whole line broke, creating a lot of white space for this one additional button. What that means for our users is that the report table is now 330 pixels in height, which is around 51%, well, 50% of the whole screen.

[00:03:13] Basically, each added feature takes space away from the table. And with screens smaller than 640 pixels, which are also common for our users, the table also gets smaller. And the buttons grew in number, and despite the fact that some were used much more often than others, they had the same character, being in the same line above the table. Also, due to the design that I mentioned and some past decisions made, some of the buttons were appearing out of nowhere once a campaign was selected, which made the whole screen jump. I had the opportunity to observe the workflow of some of our users when they visited us at the office, and I noticed how much they were struggling with this while working on their laptops.

Why the redesign kept being postponed

[00:04:04] Those two reasons seemed like enough to start working on the redesign. The product team had been aware that this was an issue for quite some time, but improving it never seemed to be a priority. There were designers before me that tried to do it. There even was a design prepared to a certain extent. But there was always something more important to get done. Voluum Tracker is a very technically complex product, and it requires a lot of maintenance. Also, the features that our users are requesting are quite difficult to build, so development resources were always spread rather thin.

[00:04:45] And there's an additional problem with a change like this, which is the fact that it's difficult to measure. I did observe it, but I didn't have any numbers to support my case at that point. And there was always this argument that kept coming back: our users are not complaining that much. They are still using the product, so maybe it's not bad enough to be worth fixing.

[00:05:12] At the beginning of 2020, something changed. A girl with primarily product design experience, who was working on a different product in my company, got the offer to take up a product manager's role in Voluum Tracker. I didn't have much experience working with her at that point, but soon after she joined I noticed this shift in perspective. She has the product and business needs in mind. She doesn't only think about good UX, but she's aware of the value it brings to the table. We had been talking about the changes needed in navigation for a while, and finally, thanks to her help, I got a green light to move forward with the project.

The redesign

[00:06:01] I used the resources I had from past attempts at a redesign, and I dug a little bit deeper into the numbers. I was focused on the redesign itself, on making the navigation simpler and lighter in style, but I also really did not want to hide elements important for our users or slow them down in their everyday work. I needed precise data on what users were clicking most often and what screen resolution was the most common for them, so that the change would be an advantage for most of our users.

[00:06:43] The final redesign involved two main parts. The first was hiding less frequently used buttons under two dropdowns: More Reports, for the report buttons, and More, for the buttons above the report table. In both those cases we decided that they would be sort of responsive, so depending on the screen resolution, some users would see more of them and some fewer. With wider screens there was the option to see even all of the available buttons, so that our users could still have access to all of them if they have bigger screens.

[00:07:28] Another change was that we divided the buttons above the table into two groups. On the left we now have buttons connected to managing campaigns, offers, anything that's listed in the table, and on the right we have buttons that are connected to managing the report table itself. The effect of the improvements was, first of all, much more space for the report table, which on the 640-pixel screen now took 67% of it. That was really good for our users. And an additional bonus change, but very important from my perspective, was the fact that the screen was no longer jumping when the user was selecting a campaign.

Testing and rolling out the change

[00:08:22] A lot of work had been done up until this point, but we still had a long way to go, and we had to test those changes out to make sure we didn't miss anything major before turning it on for all our users. To test it in the first phase, we used our Slack community called Voluum Lab. It consists mostly of our power users, but for the purpose of this change we decided that that was good enough. Our strategy was to turn it on and then check for reactions.

[00:08:55] And there were some reactions. I had been prepared for that, because I understand how it's always difficult for the brain to adjust to a change like this. Surprising to me was the fact that there wasn't much emotional feedback, of people begging to revert the changes and not change anything in the product. Some bugs were mentioned, and some functionalities had been taken away by us by mistake, so we worked to bring those back.

[00:09:26] The next step was rolling out the changes to 50% of our users. As I mentioned before, the biggest surprise again was the fact that the users really didn't complain that much. There were some technical issues that we encountered, and they mentioned them, but once we fixed those, we rolled the changes out to 100% of our users. And only a couple of them, out of thousands, directly complained that they didn't like the change.

Finding advocates

[00:10:06] Another thing I've learned through the process is how important it is to get people on your side when you design a change like this. I really believe you need to find advocates for better user experience, and this is something that worked really well for me. I found exactly two people who understood my goal. One of them was the product manager I've already mentioned, who helped me get the green light for the project. The other person was the front-end developer, who understood user needs and cared about them. They helped me, in reality, to first make the change a priority, and then they supported me through its development.

[00:10:52] I also recently read a book that talks extensively about this topic. Leah Buley says: "Every day is an opportunity to invite your non-UX colleagues into the world of UX, and invite them into the conversation and the community, and treat them as partners in the ongoing project of making your products as user-friendly as possible." I think this is very important. I think once people feel that the project is also theirs, they care more, and the whole product gets more out of it.

Summary

[00:11:27] To summarize, it has been my observation while designing Voluum that when you have a product with that much history, it's sometimes difficult to make even small changes, because you worry about the users' reaction, the impact this will have on their work, the bugs that the change may bring forward. And I know firsthand that it may be tempting to let users have what they got used to.

[00:11:54] I feel it's also more important with mature products such as Voluum Tracker to include people from different roles, with different backgrounds, in the creative process and through development and testing. Because, for one, they have the answers that designers need, the knowledge and expertise, but also they are our teammates, and once they feel that the project is partly theirs, they will motivate us and others and advocate for our version. I think it's also very important to get the data behind your ideas and make sure that the improvements you're planning are not actually going to make life harder for your users. And if you have those two elements, my advice is: don't be afraid, and trust your instincts, because your product needs refreshing and it needs changes, and the users will learn to live with them if you don't take away something that they need most. I think that's it. Thank you for your time.