00:00:06 ◼ ► And I'm David Smith. Under the Radar is never longer than 30 minutes, so let's get started.
00:00:26 ◼ ► where I always thought I was making an app that was very much for a very particular audience,
00:00:47 ◼ ► And then of course the app ended up, it turned out that it was for those people, certainly,
00:00:51 ◼ ► but it ended up that those people represent a teeny fraction of the actual user base of the application.
00:01:08 ◼ ► and all those kind of choices in it to allow people to express themselves with their widgets.
00:01:32 ◼ ► I tend to kind of, I have a list of features of things I want to build and modes I want to support,
00:01:41 ◼ ► And from version 1.1, version 2 of Widgetsmith, those features are very much more like doubling down
00:02:03 ◼ ► Whereas ultimately what it's like, it maybe became clear, is it's like what most people you want the app to do
00:02:11 ◼ ► And adding some super, like, okay, making it so that you can give it a URL that downloads and parses JSON
00:02:42 ◼ ► And so I found myself in this really funny place where I kind of had to decide if I was going to,
00:02:49 ◼ ► And pivot is that like the fancy Silicon Valley word that I feel like is a bit overused,
00:02:53 ◼ ► but in this case I feel like it's very appropriate for that situation where you thought you were building something
00:03:14 ◼ ► I could have just kept going with my crazy features and ignored the 99% of the people using the app
00:03:29 ◼ ► for it to grow, for it to develop, for it to have more staying power and retention with those people.
00:03:40 ◼ ► I threw away my roadmap and instead have been focused entirely on very sort of aesthetic
00:03:56 ◼ ► is very much entirely focused now on the concept of themes and that you can build, you know, themes.
00:04:02 ◼ ► And the app comes pre-built with dozens of different aesthetics that are kind of easy to use in the app
00:04:11 ◼ ► And it totally changes that sort of concept and it's so far the response has been positive for it
00:04:29 ◼ ► And then, you know, throughout that process, and this is where most of the rest of the episode is probably,
00:04:51 ◼ ► I mean, I've never had to tackle as big of a change as what you're describing here with any of my apps.
00:05:01 ◼ ► In the lifetime of Instapaper, I had to do a bunch of small tweaks here and there to address, like, shifting demand
00:05:10 ◼ ► One of the biggest ones, which was much smaller, but like on day one when I first released Instapaper to the App Store,
00:05:17 ◼ ► on day one of the App Store, it was like day two or three of the App Store, whatever it was,
00:05:20 ◼ ► I didn't have any way to create an account in the app because I just assumed the only people who would use the app
00:05:30 ◼ ► So I just had a login screen and there was no way to, like, start if you had discovered the app from the App Store.
00:05:36 ◼ ► And I very quickly had to add that because I had totally mispredicted how that demand flow would happen
00:05:52 ◼ ► much longer than I planned because the beta feedback that I got, like when I sent the first beta to the testers,
00:05:59 ◼ ► and I was like, "I think this is almost done. I think I'm going to ship it pretty soon."
00:06:02 ◼ ► And then it turned out there was so much feedback about, you know, things that people didn't understand
00:06:08 ◼ ► or things that I had made too complicated and, like, Voice Boost used to have three different modes you could set it on.
00:06:17 ◼ ► And eventually I realized that what everybody wanted was just the top mode, so I just made it an on or an off.
00:06:23 ◼ ► But it used to have different settings. And there were things like that, changes I made in the apps,
00:06:28 ◼ ► you know, over time to address, like, once something gets contact with the public, you realize, like,
00:06:35 ◼ ► "Oh, this thing I thought would be this way, like, that didn't work out," or "People didn't get that."
00:06:40 ◼ ► "This thing over here that I thought would be a minor thing is a major thing, so I need to work more on that."
00:06:45 ◼ ► Or, like, what people actually want is, like, 40% of this plus this new feature that everyone wants that I never even thought of.
00:06:57 ◼ ► And so I have to kind of, you know, pivot in that direction or shift over in that direction.
00:07:01 ◼ ► But I've never had anything on the scale of what, I mean, first of all, just in users, I've never had anything on the scale of Widgets and Myths.
00:07:09 ◼ ► But I've also never had anything on the scale of, like, the pivot that you've made with the app.
00:07:14 ◼ ► And I hate to keep using this douchey business word, but that's what it is, like, that's what you did.
00:07:26 ◼ ► Like, before you've actually done the work, how, like, how can you tell, I mean, in essence, you have, like,
00:07:32 ◼ ► effectively a massive scale feature request or a, like, user expectation mismatch or a target market mismatch.
00:07:40 ◼ ► Like, how do you decide what to address and how to, like, how to filter these, like, the possibilities of what you can do versus, like,
00:07:51 ◼ ► you can decide either, like, I'm going to do this thing, this is what this app should be, or some of the requests or expectations or ideas,
00:07:59 ◼ ► you can say, that sounds like what they want is actually a totally different app, but I'm going to decide not to serve that market.
00:08:05 ◼ ► Yeah, I feel like that tension is, I mean, it happens in the small level with all apps, I think,
00:08:12 ◼ ► that sense of dealing with feedback and working out, are you dealing with a vocal minority of users who are using the app
00:08:22 ◼ ► in a way that you don't particularly, and say you didn't particularly intend for it to be a use, but it is a possible use.
00:08:27 ◼ ► And there's a vocal minority of people who are using it in this way, and they keep telling you, oh, I wish it did this,
00:08:34 ◼ ► I wish it did this, I wish it did this, and if you actually listen to them, if you actually go down that road,
00:08:40 ◼ ► you can actually kind of ruin the app for the sort of the quiet majority who you never hear from,
00:08:48 ◼ ► because the app is already doing what they expected it to do, and so why would they reach out and tell you that it was?
00:08:53 ◼ ► And I feel like that tension is just always there, and it's like this particular app, I feel like,
00:08:59 ◼ ► I had something going for me insofar as it, sort of the volume of feedback and the volume of how it was being used,
00:09:08 ◼ ► and kind of the almost like, we were like cultural realities of widgets on iOS 14, meant that it was clear
00:09:17 ◼ ► that this was something sort of bigger and very different than I was expecting, and what they were looking for,
00:09:24 ◼ ► like I think, and this is a good thing to look for in that feedback, is there was a reason that they were using
00:09:30 ◼ ► Widgetsmith in the first place, that there was a reason that Widgetsmith took off and had its sort of moment in the sun,
00:09:38 ◼ ► and that reason was because it was customizable, that you could make it your own, that it didn't just ship with, you know,
00:09:48 ◼ ► ten themes you could choose from, that part of what made it work and I think successful is that it, you know,
00:09:55 ◼ ► from the beginning I opened up tremendous variability to it, and so it was interesting to make sure though that
00:10:03 ◼ ► if I want to sort of double down on that kind of features of the app, I need to do it in a way that I never want to make sure,
00:10:10 ◼ ► that I'm never taking something away from someone, or at least I'm very careful anytime you take a feature or an ability away from a customer,
00:10:19 ◼ ► because I feel like that's a situation that you can really like burn goodwill and like, you know, just shoot yourself in the foot,
00:10:27 ◼ ► like it's an unforced error, like if you just, there was this thing that people love doing and you took it away,
00:10:32 ◼ ► and so like that was my number one thought, is that whatever feature, whatever feedback I take in, whatever direction I take with this,
00:10:39 ◼ ► I need to make sure I'm not taking away, like the reason that people like it, I'm not taking away the reason that it got successful in the first place.
00:10:48 ◼ ► So what I'm hearing and seeing that people are using the app because they want to make super custom home screens,
00:10:54 ◼ ► that they want to have widgets that fit their aesthetic, that for whatever, whether that's the crazy extreme version,
00:10:59 ◼ ► which is like lovely and awesome to see where people have, you know, totally seamless widgets that blend in with their wallpaper,
00:11:06 ◼ ► and they're replacing the app icons for all their apps with shortcuts, and it's like very extreme to the version where it's just like,
00:11:18 ◼ ► Like, both of those extremes, you know, are serviced by the app and you're trying to find something that kind of works with both.
00:11:26 ◼ ► And so I think what it's like, I tried to crystallize the feedback into what is the actual sort of frustration that people are having
00:11:46 ◼ ► And it's like, in this case, it was that the two things that people really sort of wanted were,
00:11:52 ◼ ► A, was a better starting point, that they didn't have to completely build an aesthetic from scratch,
00:12:00 ◼ ► was something that I think was kind of annoying. Because in its first version, all of the widgets start off being like black background, white text,
00:12:15 ◼ ► And so I needed something that was better than that. And then they wanted a way to have a theme that they could apply to multiple widgets at once.
00:12:24 ◼ ► Like, those were the two things that I kind of was able to boil down out of the feedback,
00:12:29 ◼ ► is that they wanted it to have a good starting point and then have an aesthetic, once they've defined their aesthetic,
00:12:36 ◼ ► kind of tweaked from whatever that starting point is, have a way to apply it to lots of different widgets at once.
00:12:42 ◼ ► And so I tried to take that feedback and not get stuck in the weeds of exactly what they're asking,
00:12:50 ◼ ► and instead try and boil it down to the actual core need. And once I had that, it's like, okay, that was what I ended up building.
00:12:57 ◼ ► In WidgetSmith 2, you have themes, and there's a bunch that are pre-built, but for any theme, you can completely customize the theme.
00:13:08 ◼ ► And you can change it and you can say, actually, I want this font, or I want this color, or I want this artwork or border applied to it.
00:13:15 ◼ ► And then you can say, do I want to just apply this to this widget? And so essentially back to the old model that I had in WidgetSmith 1,
00:13:21 ◼ ► where for each widget you can go in and super customize, or you can say, just update the theme, and now that's your aesthetic.
00:13:27 ◼ ► You can apply it to all your widgets. And that process, I think, seems to have been successful,
00:13:33 ◼ ► and I think it's generally a theme that I would recommend. It's like, you need to listen to your users,
00:13:38 ◼ ► but try and understand what problem they're having, not the solution they're presenting.
00:13:44 ◼ ► Because I had all manner of different solutions or recommendations or things that people wanted,
00:13:48 ◼ ► and it's like the number of requests that I have for people, it's like, I want a different color.
00:13:53 ◼ ► I want more colors in the color palette. And at some point, it's like, okay, I'm just going to give you a custom color picker.
00:13:57 ◼ ► You don't actually want more colors in the color palette, but you want a very specific color.
00:14:03 ◼ ► And so it's like trying to listen to the need rather than the solution that you're hearing from.
00:14:20 ◼ ► You're not just listening to the people you know, like your little bubble in whatever social media circles you roll in,
00:14:31 ◼ ► That doesn't necessarily mean that that's something that you need to jump on and work on.
00:14:40 ◼ ► but not overwhelming yourself with rereading every single support request and driving yourself crazy.
00:14:52 ◼ ► if I actually listen to a lot of these requests, it will make my app less appealing to the core users.
00:15:00 ◼ ► When Overcast first came out, this was 2014, if you think back to what non-Apple independent podcast apps were like back then,
00:15:11 ◼ ► it was just massive walls of preferences, huge amounts of options and settings, and it was very confusing.
00:15:21 ◼ ► And even to me, as a nerd, I had trouble figuring out in a lot of apps, what does this setting even do?
00:15:30 ◼ ► Where is this setting? If I'm looking for something, why are there seven different pages of settings here?
00:15:39 ◼ ► And so almost every request somebody makes to me is, "Hey, can I have an option to change the behavior to do X, Y, Z?"
00:15:49 ◼ ► I also know that when I have added features or changed behavior things or added behavior options,
00:15:55 ◼ ► I have so often regretted it afterwards. And in some cases, I have then removed the regrettable feature for whatever reason.
00:16:04 ◼ ► If it was too hard to maintain or it caused weird bugs that I was unable to really avoid or fix or whatever the case may be.
00:16:15 ◼ ► And the people, as you mentioned, the people who you anger for that, it generates such a level of negative sentiment from your users.
00:16:25 ◼ ► Whatever percentage, if you remove a feature or change a feature in a way that angers 0.5% of your users,
00:16:42 ◼ ► And you're going to see, they're going to, like, I've had people who keep updating their one star review
00:16:55 ◼ ► And they're still mad. And they're going to keep updating that one star review every single time I do a new release
00:17:03 ◼ ► because I still haven't given them back this checkbox I removed three years ago that almost no one else cares about.
00:17:09 ◼ ► But if you anger a user for a change you make that is negative, that could stick around.
00:17:16 ◼ ► They could be a thorn in your side forever. And so you have to be so careful about that.
00:17:28 ◼ ► As I kind of look down my roadmap here, I want to do a larger scale redesign of my app.
00:17:41 ◼ ► I want to remove a lot of legacy options. Things like, I have these two different modes my table cells can be in.
00:17:52 ◼ ► And I want to remove that. Because it's just like, here's yet more, like, crust that I've accumulated over time
00:17:57 ◼ ► that it just makes it more complicated for me to move forward with the app and I want to get rid of it.
00:18:03 ◼ ► So I can move forward and appeal to the core users more. You know, like, many of the similar things that you're talking about.
00:18:20 ◼ ► Like, if you're going to get negative reviews for changing your app in a way that makes it appeal to more people,
00:18:25 ◼ ► the net result of that is positive. The net result is, you appeal to more people. Great.
00:18:30 ◼ ► And you should see more people coming in over time who have never even seen the old way.
00:18:44 ◼ ► This perpetual source of one star reviews and angry emails that you just will never get rid of.
00:18:48 ◼ ► And it's kind of hard, even though, like, logically and rationally, you do have to weigh the needs of the many
00:18:55 ◼ ► over the preferences of those few. It is still really hard to do that and to bear the brunt of all that negativity
00:19:02 ◼ ► from that small vocal minority. But it's just one of those hard decisions you gotta make.
00:19:07 ◼ ► We are brought to you this week by MailRoute. Bad actors threaten your business with spam and viruses.
00:19:14 ◼ ► And they're even more sophisticated in 2020. Email traffic has tripled as companies have increased the number of employees
00:19:19 ◼ ► working from home on residential networks. And as admins look to mitigate associated risks to their businesses,
00:19:29 ◼ ► When it comes to handling business email, there are a number of things that are vitally important.
00:19:38 ◼ ► MailRoute solves all of those problems. MailRoute's team was the first to build an email filtering service
00:19:50 ◼ ► MailRoute is the only service to provide one-click sync with Office 365 and G Suite for simple and safe migration.
00:19:58 ◼ ► Their API-level integration ports your data from 365 directly into MailRoute, so there's no need to duplicate your workload
00:20:04 ◼ ► to activate this protection. MailRoute also meets federal compliance standards, including NIST 800-171,
00:20:12 ◼ ► or NIST 800-171, I don't know, for Department of Defense contractors. I don't know what that is, but I bet they do,
00:20:17 ◼ ► and I bet it's really important. Admins also enjoy real-time log searches and real-time reporting in their custom dashboard,
00:20:24 ◼ ► and your dashboard also includes granular controls to stop spam and phishing attempts, plus viruses, ransomware, and malware.
00:20:31 ◼ ► So try MailRoute today and get 10% off for the lifetime of your account by going to mailroute.net/radar.
00:20:39 ◼ ► You can even get a 30-day free trial with no credit card required. So once again, just visit mailroute.net/radar
00:20:56 ◼ ► So I think something too that I want is probably worth talking about is the way in which we communicate change
00:21:04 ◼ ► inside of the app, and the degree to which that is overt change management, or if that's just subtle in the way
00:21:17 ◼ ► So in this circumstance, I was dealing with a place where there was this old way of doing it and there's this new way of doing it.
00:21:27 ◼ ► And it's like when you talk about, say, changing the overcast row behavior when you tap on it, it's this interesting question of
00:21:35 ◼ ► is there an obvious path from the old version to the new version that is going to be kind of intuitive to your customer?
00:21:43 ◼ ► That if suddenly I put themes rather than attached to widgets in their own tab, for example, there's like the themes tab
00:21:51 ◼ ► and then you apply those themes to widgets. That was one of the approaches that I came up with when I was building this.
00:21:57 ◼ ► And very quickly I decided, nope, this is the wrong way because it changes how the app works in a fundamental way.
00:22:05 ◼ ► There's not a clear and obvious path from the old way to the new way. And ideally, I think you're building something like this,
00:22:11 ◼ ► you want to make sure that there's this, like, if people are just going about doing the thing that they used to expect,
00:22:17 ◼ ► but now it's better, it's enhanced in whatever way, it's obvious. So in the overcast example, it's like that if you were expecting
00:22:27 ◼ ► when you tap a row for it to play and now it expands and there's a giant play button there, the change management is reasonable about that.
00:22:36 ◼ ► That it's not too crazy for a user to, they might be like, huh, I like the old way better, but they know what's happening,
00:22:43 ◼ ► whereas it's not this strange thing where now when you hit it, it takes you to this other place and then there's a play button you have to find.
00:22:50 ◼ ► That version of it is perhaps more disruptive than the middle ground. And I think there's that side of it.
00:22:57 ◼ ► And there's also the interesting things where I made a few user interface design decisions that I don't think are the prettiest,
00:23:05 ◼ ► I don't think are the most flashiest design, but they are intentional because they're a little bit, it's not like it's intentionally ugly,
00:23:15 ◼ ► but it's intentionally very clear and obvious. And what I'm specifically thinking about is in the new theme chooser,
00:23:21 ◼ ► where you're choosing your widget and you pick which theme you want, I wanted to make it extraordinarily obvious that you can still customize that theme.
00:23:31 ◼ ► And so I put a gigantic button in the old school iOS style with a big rounded rect and it's very colorful and stands out from its background.
00:23:41 ◼ ► And it is clearly a button button. It's not just some text on the screen that has a different color to it, which can often cause trouble.
00:23:50 ◼ ► It's like, nope, I wanted to make the most button shaped button I could imagine, put it in big obvious letters, and put it in an easy place to tap.
00:23:59 ◼ ► So it's like right at the bottom of the screen in this big obvious way. And it's not the most aesthetic choice,
00:24:06 ◼ ► and there may come a point down the road where I can kind of dial that back a little bit, make it fit into the aesthetic of the app a little bit more better,
00:24:14 ◼ ► but it was one of those choices where I'm like, I want to make sure people know that this button is still here, they can still customize the font,
00:24:21 ◼ ► they can still change the background, and so I'm going to make it very obvious that there's this giant button to do it.
00:24:25 ◼ ► And you're just kind of like, I'm just laying it out and putting a big spotlight on it saying, this is how you do it.
00:24:32 ◼ ► And I think I like that approach, because the other version you can end up with is the first time you launch the app,
00:24:39 ◼ ► there's a little animation pops up and it's like, here's Clippy saying, hey, a few things have changed in the app since you were last here,
00:24:46 ◼ ► and what you used to do this, now you do this. And personally, every time that happens, I always find it confusing,
00:24:53 ◼ ► because I'm not launching the app to have a conversation with Clippy, I'm launching the app to do something.
00:25:01 ◼ ► And so I'm just going to hit skip, I'm going to be like, I don't care, go away, I don't want a tutorial about the app right now,
00:25:07 ◼ ► and then I get to the point in the app where the thing they were trying to communicate to me is moved or changed,
00:25:13 ◼ ► and I'm like, I don't know, where did that paperclip go, I need to go talk to him, because I don't know what to do now.
00:25:23 ◼ ► is try and think about what your old users would expect, and then make sure that there's a reasonable onboarding path.
00:25:31 ◼ ► And obviously this is a great place for beta testing, for showing it to users, and getting that feedback,
00:25:36 ◼ ► but it's something you definitely have to think about any time you make this kind of change inside of the direction of your app,
00:25:41 ◼ ► is make sure that the path from the old version to the new version is somewhat intuitive,
00:25:46 ◼ ► or you're just going to like, it doesn't matter how good the new version is, if people can't find it and it's confusing,
00:25:55 ◼ ► Yeah, I mean, in many ways, you can use the well-known dark patterns that big companies use against them in the opposite direction.
00:26:08 ◼ ► Hiding an action that you don't really want people to do as just a text link that's like really small text somewhere on the screen,
00:26:17 ◼ ► that doesn't look like a button at all, is a well-known dark pattern, and people will do it less,
00:26:22 ◼ ► because they won't find it, they won't see it. It's a horrible pattern that many people use to great effect.
00:26:31 ◼ ► And you mentioned that it doesn't look as pretty, and this is a constant friction and tension and trade-off between aesthetic design and functionality.
00:26:43 ◼ ► And it's not an easy balance to strike, because oftentimes, I have so often done things in Overcast or other apps,
00:26:51 ◼ ► where I did something because it would be nicer design-wise, it would look nicer, and then people didn't find it,
00:26:57 ◼ ► or they didn't understand it, and so I had to then change it to be more obvious, or more cluttered, or bigger, or uglier, but then people got it.
00:27:09 ◼ ► And so many times, I get feedback or suggestions from designers or other users who suggest something that either is something that I directly already tried,
00:27:20 ◼ ► or is kind of in the vein of something I already tried, and I have to tell them, "I'm sorry, it's a good idea.
00:27:25 ◼ ► I wish I could do it that way, but I know from my own experience and from my own customers' feedback that if I do it that way, people don't see it, or people don't find it, or people don't understand it."
00:27:37 ◼ ► So opting for ways where you are overdoing it in the other direction, even if it's ugly, it's the right balance.
00:27:46 ◼ ► It is the best way to do it, because people will then find it. And designers will be upset. That's fine.
00:27:52 ◼ ► Designers will always be upset about something. Think about it, from the engineering point of view, there's always parts of your code that are inelegant, and they have to be for some kind of practical reason.
00:28:05 ◼ ► We get upset, because it isn't how it ideally would be, but the world doesn't give you ideal circumstances, and you have to make inelegant code, and you have to make ugly designs sometimes,
00:28:16 ◼ ► and that's just how it works in order to achieve functionality basics or reality goals. There's no exception to that here. That definitely applies here as well.
00:28:26 ◼ ► And to wrap this up, I think that point is excellent, just as a way to think about when you're pivoting your apps around like this, is making sure that you're not being too precious about your original vision of the app.
00:28:50 ◼ ► If you're thinking about the way you designed it originally, and you thought that was so cute or so pretty, or whatever that is, ultimately, if you wanted to be a sustainable, viable business,
00:29:00 ◼ ► you need to find the way to take user feedback and how people are using your app in practice, and smooth off rough edges, or make buttons bigger than you think they should be, or whatever that is, in the service of making the app better.
00:29:14 ◼ ► Because better becomes, once it's out in the world, is the app useful? Are people enjoying using it? Is it making you money because people are coming back to it time and time again?
00:29:24 ◼ ► And all of those things are a place where you can't be too precious, and don't get too stuck on the nuances of the design or the nuances of the aesthetic.