Designing A Mature Product: Evolution Of Legacy

Yulia Zozulya at UXDX Community: Central Europe. Video: https://youtu.be/REJtgbWhO3c

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.

Designing IDEs at JetBrains

[00:00:00] Hello everyone, my name is Yulia and I'm a UX designer at JetBrains. More specifically, I design IDEs. IDE is short for integrated development environment, a place where software developers develop software. The most prominent part of it is of course the editor, where you write your code fast with code completion or refactorings. But what if you wanted to build your code and share artifacts with the rest of the world, or what if you wanted to debug your code? The visual debugger starts to look really complicated, right?

[00:00:43] Well, this is what I design, and this is actually IntelliJ IDEA, an IDE for Java which is 19 years old and has more than 2 million active users every month. The thing is, it's not only an IDE for Java, it's actually an entire platform for 11 more IDEs for different programming languages like Python, PHP, JavaScript and others. We have a saying in JetBrains that if there is a programming language, we probably have an IDE for that, or at least a plugin. In fact Google made their new IDE for Android development also based on our IntelliJ platform, and this is really great, it leads to more than 8 million active users every month.

[00:01:32] So 8 million users each month use our platform as their main professional tool, and they use it every day from 9:00 till 5:00. Well, not really, programmers don't really do 9 to 5. So what do you think happens when you try to change something in a product that is so heavily used?

The toolbar that broke people's habits

[00:01:49] For example, we wanted to update our icon toolbar. You can see the icon toolbar on this slide. It looks a little bit outdated, has a lot of small details which add to visual clutter, it doesn't look really consistent, and also colors are a bit off. So we changed it. You can see that icons are a little bit more modern now, they have consistent shapes and they have consistent colors, so it looks like a win for everybody.

[00:02:25] Well, it wasn't. Users were not happy with the change at all. When we posted a blog post about this small toolbar update, it quickly became a discussion which became one of the most discussed blog posts in JetBrains ever. And the users actually didn't stop there, they reported it back as an issue, which is still in the top ten most voted problems in our issue tracker. All this over a simple visual change of icons.

[00:02:55] But this actually makes sense. They use our tool every day, and we realized that to us it was a simple visual change to icons, but for our users it was a change in habits. By changing the icons we were breaking someone's daily habits. So if it was that traumatic to change a toolbar, how do we update and redesign a product which has such a dedicated and passionate user base? What if we want to redesign something more complicated, or even introduce new features? What if we want to change the position of the elements?

The commit interface, before and after

[00:03:30] I will share with you today the steps that we took to update an interface on the platform called commit. For those who don't know what commit is: when a developer needs to make changes in a code base, they need to save those changes to the source code repository, so that if something goes wrong they can revert those changes, or better, if everything is all right, they can share the change with the rest of the team so that the rest of the team can work on top of those changes. The process of saving source code changes to the repository is actually called commit.

[00:04:11] This is how the commit interface looked for a long period of time. You can see here that a developer can review the changes here, select them, and summarize them in a commit message. Summarizing is required because later teammates can understand why the change was made and how it's made.

[00:04:41] It worked for a while, but the problem with this dialog actually is that it's modal, so you cannot switch between the dialog and the main IDEA frame. And you'd want sometimes to switch between this dialog and the main IDEA frame. For example you'd want to see the content of some unmodified files, or you'd want to run tests once again to make sure that everything is all right.

[00:05:06] So to fix this we could just simply make this dialog non-modal, but this would introduce a lot of context switches between the dialog and our main IDEA frame, which would add to information load and other problems. So we decided that we can do better and we introduced a new interface. Instead of the dialog we proposed this horizontal bottom pane, where we still kept the main interface details, such as the changed files and commit message, but we also introduced the changes preview on the right side here.

[00:05:56] And we didn't only change the look of things, we also changed the workflow a lot, because previously commit was a kind of isolated process where you'd open the modal dialog box and do all the stuff within this box. But now, being a pane inside an IDE, it is actually more integrated into the IDEA flow.

Starting small: dogfooding and UX research

[00:06:19] So with that big change, how did we introduce it to our users? Well, we started small. We released the interface to smaller audiences at a time and gradually increased the number of users affected by the changes, so we can incorporate their feedback and use cases and update our suggested designs.

[00:06:48] So how do you start small? Actually the easiest and cheapest way is dogfooding. Basically you get your colleagues to use the product with the changes, and we are quite happy in JetBrains because we have around five hundred developers who use our tools daily and update daily. Having them close by makes it easier to get quick feedback, and as colleagues they will usually not hesitate to tell how they really feel about the changes. Many suggested solutions can be easily implemented and tested quite quickly.

[00:07:28] So after dogfooding at JetBrains we actually confirmed that habits are broken, but we also received a lot more feedback that although it changed a couple of habits, it was actually more convenient and created a better workflow. After testing it internally we were ready to slowly release the changes to our users, but to still have some control over the release we decided that we need to do some UX research.

[00:07:59] As many of you know, UX research is really great. It allows you to actually see how users interact with the interface and what problems they have. And though it is quite expensive, as it takes time to have the sessions and to analyze them all together, you cannot have a lot of participants in the study. But at this point it's not a problem, because we're starting small, aren't we?

[00:08:27] After the study we were able to understand that not all existing patterns and habits, that we were desperately trying to save for the existing users, were really clear for new users. I will show you an example. In this slide you can actually see that one of the files is ticked and the other file is highlighted. If you want to commit the file you would tick it and then press the commit button, but if you'd want to revert the file you would highlight it and then press this revert icon on the toolbar. Most of the old users actually understood how it works and understood the difference. But guess what, none of the new users did. After that it is really clear that not all the habits are actually worth saving, because not all of them are clear to the new users, and maybe we can just remove them.

The beta program, and redesigning again

[00:09:35] After this we again a little bit expanded our release, through our beta program. Our beta program consists of around 20,000 developers and they're really great, because they are loyal and they are ready to give us feedback, and more importantly they are ready to share their use cases with us, the use cases that we might have missed during the design stage.

[00:10:03] Actually, because of this feedback after the beta release, we redesigned the UI of the commit function quite drastically. As I showed you already, we suggested this interface, the bottom horizontal pane with the changes preview and files and commit message here. This changes preview actually requires a lot of horizontal space, but this horizontal pane started to lose vertical space too. And vertical space is sparse here. You cannot see a lot of files in this file list, especially when it's grouped by location, and you cannot write a lot of text in this commit message field.

[00:10:54] Our beta testers actually showed us that though the preview of the changes is really useful, sometimes it's not really needed all the time. So we were able to remove it and to move the interface to the vertical pane, so it has enough space for the file list and enough space for the commit message. And if you'd want to still see the changes preview, you can still do that in the spacious editor area here.

Releasing to a portion of users, and the long tail of the old UI

[00:11:29] Normally at this point we would be happy enough to release the new interface to all the users, but with the commit interface being so big we wanted to be a little bit more cautious. In our beta program we normally have more old users than new, and we wanted to receive more feedback from new users, so we decided to release the interface to only a portion of the users again, to better understand interaction and feedback from the new users.

[00:12:05] How did we decide which users will get the new interface? As I said, we have a lot of IDEs based on the IntelliJ platform, so we decided to release the interface only to one of them, an IDE that has fewer developers than IntelliJ IDEA, but more importantly users of this IDE are not familiar with the platform, so they are new to the interface. Through releasing to this IDE we actually understood that the new interface was easier to understand by new users, so we were able to apply this feature to all new users over our IntelliJ platform.

[00:12:45] As for old users, we allowed them to opt in to this new interface through a promotion bar that we showed in the old interface. You can see it here on the slide. Through this promotion we actually understood how many users switch to the new interface, but more importantly how many users switched back to the old one. And we actually saw that not a lot of them did. So we were able to introduce the interface for all users, but still with the possibility to roll back. As I said, habits are hard to change, so we wanted to keep this option available for our users.

[00:13:37] This also allowed us to get some information on when we can remove the old UI, as it would be the last step in the process. But to be honest, we are still in this right now. We weren't able to remove the old UI until now. Changing habits in a mature product is a long process and it requires many steps, and we've learned through this journey that we need to go really slow as it affects too many users. But we really hope that we will be able to remove the old interface soon.

[00:14:16] So just to summarize, we went from this to this, and it wouldn't be possible without releasing it slowly to this enormous user base that we have, and it of course wouldn't be possible without the help of our loyal users. So here's the summary of the steps that we took to change the interface. We don't really take all the steps with all our updates, normally we just have dogfooding and the beta program, but it's nice that we did this with the commit interface, because it was really huge and because we were able to understand our users better.

[00:14:59] And that's it from me today. I hope you learned something from me. The thing is, redesigning is not just about changing an interface or changing a toolbar, but actually in a mature product like ours with a lot of users, it is changing a lot of habits. Thank you for listening.