It takes a lot of effort within a large organisation to get things done, especially to a really high standard. However, it’s often minor tasks that will offer you the biggest rewards. This talk will take you through a journey of suggestions and tips to help improve communication, productivity and quality, whilst tying back to an overarching theme of Release Notes.
← All talks 
Build Engineering Turing Fest 2017
Minor Bug Fixes
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Thanks, Rachel. Thank you all for attending. Just like to start by addressing the title of the talk, because I know that it's, like, a little bit ambiguous, Minor Bug Fixes. You might be thinking, what the hell is all this about? Today we're gonna talk about release notes.
Minor bug fixes normally accompanies a release of some sort of software. Doesn't really matter what it is. I've kind of picked up a few issues over the years about companies tend to use this bug fixes or minor bug fixes regularly. They're actually doing a lot more work, and normally the word minor, there's not a right lot of minor about it.
Actually, quite a lot of effort has gone into this next release. So the TLDR, too long didn't read, in case you're wondering what that means, for this talk is basically the content's gonna be about apps, app stores, and release notes, but I'm quite aware that there's quite a few web people in the room, so we're gonna tie that back to communication, communication channels, and ways to improve that.
And like Rachel just said, I work for a company called Perform Group, which probably no one's heard of in the room. I'd be very surprised if anyone has. And the reason for that is it's kind of like an umbrella for a lot of different sports brands.
The sports brands that we have are like media, sports media websites and apps, basically taking sports content that's written by ourselves or stats that are produced by ourselves and distributing these across the world. So if we take a look at Goal, which is on the left here, and this is one of our biggest websites, I've highlighted for you some of the countries that we have local editions in.
So we have thirty eight local editions serving twenty languages. And the reach for this kind of audience is basically around about fifty seven point four million unique users per month. And this is taking numbers just from the website alone. If we were to add the apps into here, we're looking at over a billion page views every single month, which is a massive audience.
And basically, that kind of gives you a little understanding of the scale of work that I kind of work on on a daily basis. Hi, I'm Rob, the UX manager for this company. There's about five UX designers within my team. And we're basically based in Leeds.
And I've highlighted two of the countries there, Poland and France because for the apps, we work with a development team in Poland, and we've also got another development house in France as well. So that comes with quite a few challenges because obviously this is a much We've got to cover quite a different languages and different types of content.
But all the designers and the product guys are based in either London or Leeds. Perform comes and we often have these kind of issues like the business suddenly changes direction. We've got a lot of to serve, so you're working on this one. Oh, we've got to work on that one.
Ultimately, the main problem is everything takes quite a long time to actually produce. It's not a really nimble, agile way of working at times, shall I say. But the benefit to this is that we're working on software at huge scale, so we have access to a massive audience.
Football and sports are really passionate audience, and they're really keen to always offer their opinions and so on and so forth. It's really great to get that impact of that kind of reach. I wanted to start by taking you through one project that we worked on.
As I said before, we chop and change between different brands that we're working with. In December twenty fourteen, the goalnews dot com app was feeling a little unloved. I've kind of used the little grandma and grandpa on there as an indicator to say it's not been touched in a while, basically.
We'll get onto that in a second as well. That's not our users. Our users are generally quite tech savvy. But basically, it took about one year, three months, and eight days to be precise to actually work on the redesign of this product. And this is not anything that's revolutionary.
It's people digesting news content, so article pages, category pages. We're not reinventing the world here. And we ended up with something that looks kind of like this, which is It's got a nice new skin, some minor tweaks and improvements as we've gone along.
Like I said, one year, three months, and eight days, it's a lot of work that's gone into this. The design team, the product team, and the development teams have blood, sweat, and tears to get to this point. I'm sure that you've all been there and you've got to the release date and you have a release party, which is a case of those grannies.
They're kind of starting to celebrate. Unfortunately, there's one guy in the room, which is myself, looking more like this guy, which is thinking, what the hell? And the reason for that is this. The release note that accompanied all this work just simply read Sorry, I'll read it to you. Thank you for using Goal.
Your favorite football app just got better with the full redesign. And in my mind, that doesn't really reflect the amount of work that's gone into that kind of project. So the guy who wrote that, I'd much prefer that he did something like this.
That's not hanging himself. That's just making something that looks visually exciting and engages the audience a little bit better. As I say, I'm the UX manager, so I come from quite a visual design background, Type, typography and type hierarchy are all kind of things that I always try to look to include in my presentations in this case and work.
Someone just quickly typing up this and chucking it out there to me felt a little bit misaligned to the amount of effort that we've actually gone into releasing this product. I start asking around and basically trying to convince people that I've got this idea that we can do better than this.
We can definitely improve our products through release notes. I'm met with not the best kind of response. People are kind of saying, oh, well, we haven't the time for that. Like I have already said, we serve loads of languages, so it is going to be a nightmare translating this.
Essentially, no one reads these things, so why are you even bothering? I am thinking, well, I read it and I saw it, so someone must read them somewheres. I thought I'll spend a bit of time looking into trying to find some evidence to convince people that there's a better way of doing this.
And it turns out that no one does read release notes, as I'm sure some of you may be thinking. So my job today is to convince you to actually spend a little bit more time and thinking about the end stage and actually what the benefit is to this.
But first, let's just touch on why people don't read release notes, and there's two reasons for that. There's probably more, but these two are things that stand out. One, Android and iOS both offer auto update these days, so people just see apps getting, or don't see apps getting updated, so there's absolutely no reason to read about what the new features are.
Secondly, even if you did visit the What's New, I've got some updates section, you'd actually see the release notes. You've got to tap to expand those, which again isn't ideal when you're trying to tell your users, hey, we've got this nice new feature.
That's ultimately led to companies just being a bit lazy with release notes and are generally in the App Store not bothering. We've got Facebook on the left that just says month after month, hey, keep your app up to date and you'll get some cool features, which, to be honest, isn't that great.
It's just as bad as the stuff that we churned out. Or even worse, the title of the talk, just bug fixes, bug fixes, bug fixes. Is some of the biggest companies in the world that are doing this. My job today is gonna be to convince you that these guys are actually doing it wrong and there's a much better way, and I'm gonna try to talk you through some benefits of what we have kind of seen by taking a different approach.
It is self explanatory, but I just wanted to make it clear that if you are releasing something and you are writing it and the users are over here and they're reading it, it's very much a one way conversation. You're kind of just saying something and hoping that they're going to pick up on it or not pick up on it in some cases.
Looking back at some examples of how we can do this better, we found one way which is to actually include an option for feedback. So include an email address, say, hey, we've got some new features, but we're always working on improvements. Why don't you drop us a line?
That's already better than just writing bug fixes because you're opening up that conversation so it's less one way conversation street and it's more if they want to, they can get in touch with you and you can respond to that and basically have that sharing of conversation.
I've just kind of touched on some people that do a really bad job of this, and I don't generally like slogging people off, so let's talk about some people who do a really good job of this, and in particular, 1Password and Slack. These guys have documented much better ways of actually writing release notes and how to communicate to your audience and actually actively engage them.
I'm from a visual design background. I'm kind of dyslexic as well. My spelling's atrocious, so I'm not going to patronize you on what you should write. But instead, I'm going to try to talk about simple design tips that you can apply to just plain text release notes.
In this case, we are looking at using a very limited palette. We haven't got bold. We haven't got colors. We haven't got italics. We haven't got different sizes. We've got pretty much these characters that you see on the screen right now, and how can we use this to actually create something that's actually engaging?
I started looking around at some examples of other companies that do a really good job of this. I've already mentioned, 1Password on the left do a really good job. Use that TLDR, which is twenty first century for just summary. You don't need to read all this other stuff that we're talking about, but at least you get a little snippet of what's to come.
They use capital letters to kind of create a title, space to break out this section, that section, and medium as well using TLDR. It seems to be quite common practice in release notes in particular. We don't have access to bullets, but we've got the alt eight.
If you're using a Mac, you can still include bullets. Again, you can get creative and use text in ESPN's case, they've used open brackets and pluses. We've already talked about this, getting people's feedback, why not include that? That's a good idea. You can always reference the major release.
I'm not trying to say that writing minor bug fixes is always bad. I think that there's definitely some cases when you are just quickly fixing something, but you've probably done some really good work recently and you probably want to talk about that. The point would be don't just say the last thing.
To illustrate that point a little bit clearer, I'm gonna talk to you about the tipping point at which I started to get more buy in for this kind of new way of thinking. You guys have already seen this. This is the point at which we released the update to the Goal News app and we put out that crappy release note which just said, hey, it's got a brand new redesign, one year's worth of work down the drain.
We didn't learn from our mistake at this point, and obviously I wasn't able to get enough buy in. The next time we released, it was coming up to Euro twenty sixteen, and that's a real key date for Perform. Obviously, we're a sports media company.
We make a lot of money at key sporting events such as World Cups and Euros and so on and so forth. We spent a lot of time, like the next six months or so, really working on improving the app and getting a dedicated euro section for this time.
But two days later, we released minor bug fixes because we shipped it with something that was a bit of an issue. The reason that that's bad is if we just kind of map this out on a calendar here, we've got the euros section getting released, is great.
A lot of our competitors didn't have this, so it's a real unique feature that our app has to offer. Four days later, we've shipped a minor bug fix. We also had two of our releases that month, which aren't really that important, but I'll just put them on there for some context.
The highlighted area there is the time that in the App Store, if you look at your own app, the What's New section is a really great space to talk to your users and say, Hey, we've got this really good feature. You guys should check it out, or Our competitors aren't doing this, and so on and so forth.
During that time period, if I just flip back to that calendar, the only thing that we're seeing there is minor bug fixes. For a start, we can use that method that Evernote used that I had on screen a second ago where you say minor bug fixes, you still reference your major release.
The reason that this got so much traction is if a map where the euro started and finished, there's only actually four days where in the app store we're not talking about something like a really good feature release. Obviously, it's a key time for us.
We're getting a lot of traffic to that page and we're not really capitalizing on unique features that we've got. At that point, I started sharing all these insights that I've been gathering with the team, particularly the product team, which are traditionally the ones that are responsible for writing this kind of stuff, and I'm saying, can we work together and try to work out a perfect release note?
What should we put in there? What shouldn't we put in there? Can we have some sort of template that'll just speed up this process a little bit? We decided on this, which I'm just gonna quickly talk you through. You can always start with a nice little icebreaker.
It's not essential. I think sometimes it's appropriate, sometimes it's not. Always include that summary section because there's a lot of people who don't have time to read or they don't want to read. We've already touched on the elephant in the room that no one reads release notes, so just at least offer that little snippet to users.
Then just going down into different sections, so using capital letters to create a title for a group of content, breaking content down by something that's new, something that's improved, something that's fixed. You can talk about these in as much or as little detail as you want, but at least you're kind of covering the fact that you've done quite a lot of work.
Obviously, I've talked about this a few times already. Offer them the opportunity to get back in touch with you because that's important in creating that two way conversation. Life at Perform wasn't great before I kind of got this momentum behind this whole new way of thinking.
We've got Ole on the left here, which is an Argentinian app. We're using English to release to that App Store, which is not cool because it's not a native language. We've the same problem in Dutch. We're using bug fixes and then Klein bug fixes.
Forgive my accent there. He's just inconsistent. Sometimes we're writing a lot. Sometimes we're not writing a lot. It's generally a bit of a mess. Life after this template, we kind of saw this whole load of consistency. We're using native language. We're breaking down titles.
Sometimes there's not a right lot to talk about, but we're still using that kind of structure. Users can expect that kind of interaction with us. In fact, there's only one of these that's got a nice little ice breaking section, and again, you don't need to use it.
For any keen audience members today, I'm trying to break this talk down in a similar structure, so that's the reason for including TLDR at the start. At this point, life is good because we've really turned a corner, and that's pretty much been from me, the UX manager, is not the brand advocate or the release manager or the release manager, but I've kind of made some positive change here.
I'm kind of feeling great, but unfortunately, we've got some issues to tackle, and one of those is that translations take a really long time. I've already talked about how many languages we cover. If just one person does not reply, say, the Arabic guy didn't get back to us, that delays the entire release, which is not cool.
We've started working on a new kind of collaborative way of working. It's nothing revolutionary. It's a Google spreadsheet. We write English on the left hand column. We've got different columns for different languages and editions, and at this point, we've made it part of our workflow.
As a designer picking up a minor task, I can write in, hey, I want to tell my users about this, or as the developer who's just spent two weeks refactoring the app for the next update. We want to make people aware of that, that we're still chipping away and improving that.
If I go back to that map that I showed you at the start, the design and product teams are based in Leeds, but that suddenly meant that we're getting involvement from Poland and we're getting involvement from France, and we've got, obviously, daily stand ups and things like that, but it's an active thing that everyone's kind of passionate about within the team, is great to see.
Then the next issue would be, like I've already said, sometimes minor bug fixes are acceptable, but we make a lot of money through advertising, and one example would be that we spend a hell of a lot of time adding a new additional ad network to our app, which isn't cool.
Traditionally, we'd have tackled that by just saying, hey, minor bug fixes, sweep it under the carpet, the users don't need to know about this. That led me to have a little bit of an investigation into minor bug fixes over the last twelve months.
This graph here shows the amount of effort that's gone in. I touched on it at the start. I actually believe that there's a thing called a minor bug fix because no way is a bug fix a minor amount of effort. I've highlighted these that kind of minimal, so maybe you could get away with saying minor bug fixes at this point.
But this piece here that nearly took two sixty man hours to actually get out is the release where we actually added the new ad network. Like I said, traditionally we're using minor bug fixes for this. But from the design team's point of view, we did something really simple and it's probably not even worth talking about, but before we had our cards with a title and a little snippet, and we decided, hey, why don't we remove that snippet and all of a sudden users can see a lot more news within that view?
It's not a great thing to talk about, but it's much better than just saying minor bug fixes. We can take that release note and make it look something more like this where, hey, we've got a brand new card format. You guys can now read a lot more news than you could before.
We could just mention the fact that we've optimized ads. I know that adding a new ad network is not what the users want to hear, but it might be faster. There might be some sort of benefit to it. Maybe we don't need to go into too much detail.
The other idea would be reference the amount of bugs that you've actually fixed. That whole piece of two sixty hours was spent fixing twenty four bugs, which is quite a lot, and users might be getting frustrated by something like, oh yeah, let me try and check that out again and see if they fixed that particular one.
The other way of doing it is if you've not got anything like that to kind of say you are just releasing a new ad network, which is not cool, you might have some new features in the backlog which you know are going to come out relatively soon.
If this and that have used big improvements around the corner, I'm just kind of letting you guys know about that. This is the point at which I want to kind of address that problem that no one reads release notes. Product owners are saying to me, oh, it seems like a hell of a lot of effort for not to write a lot of reward.
Like I've already said, no one does read release notes. AutoUpdate is on traditionally for pretty much ninety percent of all Android and iOS users. But Surface Gores, one of our competitors does a really good job of this. They signpost people who use the app to a running blog of new features, and this is where they kind of reuse that copy and say, hey, this is new, this is fixed, this is improved, this is what's coming up.
It's taking it away from the App Store, so we're catering for some people who do use the App Store and not that many do, but we're also tackling the majority of people by hitting them the first time that we see the app. This kind of stuff is not something that we've got in our apps at the minute, but it's something I'm really keen to press for coming up soon.
Other ways that you can reuse that, I've just highlighted Nokia's Health Mate app. They pop like a model the second that you land on the app and it's the exact same copy word for word, so all that effort that you've just put in, you've translated it to twenty different languages, we can just reuse that.
Or if you guys don't generally deal with the App Store or websites, you can always do what Dropbox does and at every major release, send your users an email if you've got access to their email addresses. I just want to spend the last part of my talk just kind of proving to you guys that this works.
I've wrote an article about this, and I'll share this on Twitter later so you guys can read it if you're interested. But coming to Turing Fest, I really wanted to come here with some evidence and be like, look, we've done this and this is proper call and give you guys a little bit more insight.
Going back to that point of speaking to users and allowing users to speak to you, this is not, like we've already said, not a lot of people read these, so it's really quality over quantity. What we've seen in our inboxes is things like this where someone's gone to the effort to download our app, to update our app, to read our release note and actually send us an email saying, Hey, I think you guys could do some better work.
We've come back to them saying, Hey, would you mind just explaining a little bit more because we kind of get your problem, but we're not really seeing it within the office. This guy's come back and literally broke down why his notifications aren't working, what his teams are and so on and so forth, which is great.
This kind of insight is only there because this user's really bought into that process and he's already put quite a lot of effort in to get to this point. We've also picked up users for interviews, so someone, again, got in touch with us through the release note, went back and forth just dead quick and then said, would you mind just jumping on a call?
It'd be nice to speak to you a little bit more. That's kind of trying to get the point across about quality over quantity. Now the next slide really proves where quantity comes in place and where release notes might not be the place for quantity, but there are other drivers where you can get that real rapid increase.
This is something that we released off the back of that major release that we referenced earlier. Thanks for using Goal, your favorite apps just got better. Oh crap, loads of people are slaying us in the app stores, I'm sure you probably familiar with if you change everything, users tend to hate it immediately.
And we did this dead simple thing where we just introduced the app store rating block. It's quite common. You get the good people going to the app store and you get the people that are a bit pissed off directing them to an email so that you can have that two way conversation.
The benefit to that is twofold. One, you can address people that are pretty annoyed and give them some sort of comfort or reassurance that you might work on their problems in future. But two, if you are familiar with the App Store, the way that ratings works is it's quantity and quality.
So if you can get the four and five star guys into the App Store and you can get them there in abundance, what will actually happen is your apps will suddenly start getting featured, especially on iOS. This is the left during the Euros, we got the Go Live app featured.
We've been on the hot this week and on the pitch fills right at the front, which is great exposure for the team and for the app. I just wanted to show you the effect of this in the App Store and the ratings. This is the Android App Store.
At this point, we've got that release, which is a brand new redesign, and like I said, you can see the increase in the negative feedback. The next release, we added the ratings block to try to stop that negative feedback from sending us down the charts.
What we found is all of a sudden, the volume just doubled overnight, and it's like, woah, that's cool. We're actually encouraging people to speak to us in the right channels. We're not using the App Store for people slugging us off. We're using that for, hey, you're doing a good point, and up until recently, you couldn't actually reply in the iOS App Store to people's complaints, so getting them to go to the emails, it's got another benefit to that.
Then touching on the OLE app, so this is like the South American app. It does not get a lot of love, and we did a release recently with that ratings block implemented from the start, and it's shot up overnight, quadrupled the amount of response that we got.
So I just wanted to touch on a little saying that my previous boss at my previous company has drilled into my head and it's stuck with me a long time. I think you guys can all take it away today, apply it to your own workstreams, that's the two millimeter rule by Tony Robbins.
It's essentially the fact that to get from average to good takes a hell of a lot of effort. I'm pretty sure that none of you guys in this room are gonna settle average. You're all gonna want to get to good. To get from good to excellent is actually only two millimeters more, but pretty much everyone just gives up when they get to good because they go, oh yeah, it's good enough, ship it, it's gone.
If you actually spend a little bit more time focusing on some of the real minor things like release notes, you can actually achieve something that's truly excellent, and you don't actually realize how close you were to getting to that point. Then it won't be a talk about release notes without finishing on that feedback that we've kind of talked about.
Hit me up on Twitter. It's robgill. I'll tweet out the article that I wrote about this so you guys can have access to all the assets, but feel free to let me know how I did today. I'd be more than welcome to engage in a conversation.
Thanks very much.