Download directly

In this episode we change the tune and talk with Raveesh Bhalla; Raveesh is a GDE for design specialized in UI/UX.

He starts off by helping us get a good understanding of what UI/UX involves. He then shares his experiences and learnings from having conducted extensive research specifically for Android. What are some good patterns today, what are anti-patterns, what should we watch out for. Listen on to find out more!

Show Notes

Apps with interesting designs

Misc

BuddyBuild is a continuous integration and continuous deployment system built specifically for mobile developers. Thousands of development teams love BuddyBuild because it’s the fastest way to build, distribute and gather feedback for their apps. Give it a try for FREE at buddybuild.com

Contact

Transcript

Donn Felker: Let’s hop right into it, folks. Today, we’re going to be talking about some fun stuff related to UX and UI. We have a special guest here with us. Please welcome Raveesh Bhalla, a GDE. Welcome to the show, Raveesh!

Raveesh Bhalla: Hey, guys. Thanks for having me.

DF: For the folks who aren’t familiar with you (particularly with your background in Android), can you give us the Reader’s Digest version of how you got into Android and what you’re currently doing with it?

RB: I got into Android (on the development side of things) back in 2009 or 2010. Smartphones were just starting to take off over here in India, and I wanted to start writing code for mobile applications. I started out with Nokia, and then realized that it was a big mistake. That was a big thing in India for a long time, though.

But after building a few applications, I noticed that I was spending a lot more of my time with the design elements of things, particularly the UX. Slowly, as a result of that, I moved into a design role. I still write some Android code on the side—in fact, I just released an application last month that aids my design work—but that’s only a hobby now.

I just joined an Indian design and development agency called Uncommon, and I’m advising a few more startups on the side.

DF: So you’re like a wild unicorn—someone who can both develop and design.

RB: I actually don’t think it’s that rare. I really think that developers have a huge role to play in design, and they’re already doing that. I think that there are at least a few developers out there who are actually already pretty good at design.

KG: My friend, you overestimate the capabilities of developers. To be fair, there are actually a bunch of developers who have pretty good design tastes.

RB: It’s not just their design tastes, but also the roles that they play. There are other sides of the table that they need to take care of besides just visual elements.

KG: That’s actually a great segue. Before we get into that, though, I had a quick follow-up question. When you started off with Nokia, did you actually have to write apps for the Symbian OS?

RB: Yeah, they used Symbian C++ and the QT IDE. That thing took forever to get the hang of, and I eventually gave up and thought, “You know what? I think I’m just going to write for Android, because that’s in Java.”

KG: What does it say if you actually pick Java as a language over something else? “This is too annoying. I’m just going to go with Java.” That speaks volumes about what it was like.

RB: It was awful.

KG: You mentioned that UX isn’t just about visual design, and I find that fascinating, because a bunch of my friends who are designers also mention that. Obviously, there’s that famous Steve Jobs quote:

Most people make the mistake of thinking design is what it looks like. People think it’s this veneer – that the designers are handed this box and told, “Make it look good!” That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works. – Steve Jobs on design

Could you talk a little about that topic? To you, what is design? What does it mean to you, especially as someone who’s worked as a developer before? You have the unique advantage of translating this mystical world for us.

RB: A lot of people confuse design with art. They think that since they can’t draw or aren’t good with colors, they don’t have a role to play in design. But visuals are just a part of design itself. I look at design as the strategy that you’re using to solve certain challenges that come your way. I almost consider it a science, personally. I believe that good design can be measured, and that you can quantify what is and isn’t working. It takes a lot of logic, which is why I believe developers can actually make pretty good designers.

KG: Usually, I try to think of it as the difference between UI (the art, the illustration, and the other visuals that you see) and UX (the overall experience). Does the science aspect that you mentioned play more heavily into UX, or is there a conjunction there? Is it something that you can even demarcate?

RB: I think it plays slightly more into the UX side of things, but it does play into UI as well. The point is that you’re essentially measuring a certain design change (for instance), quantifying whether a user is able to do what you wanted them to do. That doesn’t necessarily mean that you should do the old Google A/B tests with 50 different colors of blue for links, or something like that. I think that’s a little overblown.

KG: Are there are any other misconceptions regarding design that you think are important to iron out at this point?

RB: Design needs to be thought of as strategy itself. It needs to be at the core of a product team. For example, most of the startups I advise have a product team that decides on what needs to be solved and how to solve it. Then they go to their designers and tell them, “Okay, we want you to design the UI for this.” But I think that designers need to have a seat at the table on the strategy side of things.

KG: In other words, right where you’re building this product to begin with—at the stage where product managers are doing their whole business evaluation of the application’s objectives?

RB: Exactly.

DF: I completely agree with that statement. It seems like at every company I’ve consulted with, an idea comes down from the higher levels to designers too late in the product life cycle. Then they feel like they’re just applying a coat of paint on top of something, solely to make it look better.

But if design was brought in earlier, management might actually see, “Hey, we can do this thing a little bit differently, and it’ll make more sense to users than the wizard flow that we’re building.” I think that’s a great idea, and I completely agree that we should be bringing designers into the fold a lot earlier in these conversations.

Now, how can you tell by looking at an app if it has a good user experience?

RB: I won’t necessarily be able tell immediately. I mean, I can probably point out a few things that are done wrong if they just stick out, but I think that good UX is something that you realize over a period of time. Quite often, you don’t even notice it because it feels so natural, and you aren’t paying too much attention to it.

For example, a lot of applications will do a lot of animations (and things like that) just to wow you. Over a period of time, though, you’ll probably get tired of them, or maybe they don’t have as much impact as you might think.

KG: Do you think that some folks have gone overboard in the Android world today? I don’t want this to be a leading question, but do you think that folks have gone overboard with Material Design, or do you think it’s not being used enough? That’s one interesting conversation that I’ve had with quite a few folks. Now, they’ve always said, “Material Design is great,” and I feel that way too. I don’t see it as being overboard—but then again, I am an Android user, so maybe I’m being biased. What are your thoughts, as someone who works in design? I imagine you have a slightly more objective outlook on that.

RB: I think that a lot of people get the original goals of Material Design wrong. If you talk to a lot of people, most of them think, “If we do Material Design, we need to have a floating action button, a toolbar, and stuff like that.” I don’t think that’s how you need to think of it. Go back to what Material was originally supposed to stand for: trying to bridge the divide between digital interfaces and physical products; taking some of the affordances that we have in physical products and applying them to digital products. Essentially, they wanted to add shadows and make the way things move feel very natural.

Because of that, I do think many people get it wrong, in the sense that they’ll put a floating action button in a place it probably doesn’t need to be in. I think that Google also missed a big beat over here. The original Material Design guidelines talked about a floating action button as a promoted action, and I felt that that wording was imperfect.

I also think a lot of designers feel very constrained by Material Design. As a result of that, we’re seeing very homogeneous designs. I think that good designers try to step away from that, understanding that (while there are guidelines) it absolutely makes sense to deviate from the guidelines every now and then.

KG: One of the easiest ways to help someone understand good design is to point them to applications that do it really well. Can you point out four or five applications have good design in general (not necessarily just Material Design)?

RB: I think that one which a lot of people have probably used is Todoist. It’s a todo application which I absolutely love (and I’ve tried out a bunch). It feels like a very standard Material Design application, but one of the things that I really like about it is a little feature called “karma points”. It essentially promotes being a little more active in terms of keeping track of your tasks and marking them off. They use this small indicator, which points up or down in terms of your trend, gamifying getting your tasks done.

Another app I really like is Foursquare Swarm. There’s a little known feature in Swarm that indicates when you’re on a streak. I saw someone who did a 52 week streak of checking in at a gym, and I tried to do that this year as much as possible. I got up to about 44 weeks, but couldn’t go further with that, but I still got 44 consecutive weeks of going to the gym!

KG: That’s pretty good. Donn has a three year record.

DF: Not lately.

RB: Another one that I just came across is this little app called Enki. It’s actually meant to help improve your programming capabilities. They also have a small little gamification thing which lets you know how many days in the past week you’ve spent five minutes in the app, going through one of the workflows. Also, they position that by telling you that all you have to do is spend five minutes in the app. That convinces you to take that much time out of every day.

One that I came across recently, while doing some research here in India, was called Fastfilmz. I love this because it’s completely different from what you’d expect from a Material application. Fastfilmz is a startup based out of South India which does movie streaming in three of the languages spoken here.

They have a completely different UI. One of the things that I’ve noticed during my research on Indian users is that nobody here really uses search. So, their entire navigation is actually based on movie stars, because one of the major reasons that people watch movies is to keep track of their favorite stars.

During the stream itself, they have a couple of buttons on the screen that you can tap. One of them essentially mimics a whistle for you, and the other displays firecrackers all over the screen. If you’ve ever been to a South Indian movie screening in a theater, you know exactly what I’m talking about. People over there go nuts at times with firecrackers and other stuff inside. No one cares about fire codes at all. Fastfilmz just replicates that behavior for people on the phone itself.

KG: I’m chuckling because I know exactly what you’re talking about. Are you used to whistling in movies, Donn?

DF: I mean, it’s going to get a little rowdy in certain theaters in New York City, but throughout the majority of the US, if you go to a movie theater, people may clap when certain things happen in a Star Wars movie, but they generally just sit there and watch them. You don’t hear a single thing. Apparently, that’s different in India. What’s it like over there?

RB: It’s very dependent on the region and the stars themselves. Bollywood films get it for Samachar, for example, but most of the other movies don’t have it. I’ve never particularly experienced this, but I’ve heard of a lot of people who have.

KG: Back when I was in India, there was an extremely famous movie star named Rajinikanth. He was from South India, and he was basically our equivalent of Chuck Norris. Some of his movies are outright crazy. He’ll catch bullets and shove them back at people! But people have a devotion towards him because he’s also a good person in real life. Even though people know that what they’re seeing is completely bizarre, they’ll go to his movies just for the experience of enjoying it with other folks and reveling in the ridiculousness of it all.

RB: It kind of signifies how big their user base is overall. You could never expect NetFlix (for example) to do something like this.

KG: It makes sense that NetFlix doesn’t do it, but Fastfilmz does. It’s all about that target demographic.

That brings up another point, then: if you’re in a startup that’s doing well, and you’re expanding to different countries, should you localize your app specifically to every single country that you go to? I don’t mean the technical localization that most of us developers are used to. I mean, do you tailor your app to the specific countries that you’re moving toward? For example, does the Uber app need to be completely different when used in India, China, or the US? What are your thoughts?

RB: I think it makes sense to make that investment once you know that a market is becoming important for you. For example, I know that a bunch of companies are starting to do a lot of research in India to understand the market better, now that they’ve determined that that’s where they’re going to see their next big growth. Facebook wrote a great post recently with their best suggestions for international research. It doesn’t need to be a completely different app, but I wouldn’t be surprised if there are a few things here and there that need to be changed.

DF: So, as we move forward, if I want to mimic some of these applications that have good UIs, UX, and so forth, do I need to worry about building a particular team in a certain way to accomplish that? If I do, should I just start with engineers, or should I try to get a designer first? Is there any particular way that you advise companies to structure their teams in order to make sure that they nail their design and UX?

RB: One of the benefits of the last few years has been that a lot of startups tend to have a design founder right from the get-go. That means that design has a significant voice at the strategic level itself. But if you don’t have that, I do think it makes sense to hire a designer, if you can. If you can’t afford it, I’m not going to stop you.

Having said that, the biggest investment you can make early on is in research. You don’t necessarily have to hire someone else to do it. You probably can pick it up yourself, at least to a degree. There’s a book by Steve Krug called Rocket Surgery Made Easy about doing user research yourself. I haven’t actually gone through it yet, but some people whom I respect recommend it a lot.

One of the strategies that I recommend early on is to understand your target users, see what kinds of applications they’re using, and keep your design as similar to those applications as possible. For example, I worked with a startup recently that’s designing a chat app for customer care. What I essentially did (in the early versions of the application) was copy WhatsApp’s design and behavior, except for adding a little few things here and there which I felt polished it a little bit more (like typography).

KG: You said that user research is pretty helpful early on. How should I go about this specifically, as an engineer? Since most of our listeners (in the end) are engineers/developers, I imagine they’re interested in knowing how.

DF: Just to add on to that really quickly: in other platforms (like the web), there are things that can kickstart you into getting a decent design and UX (like Bootstrap, Foundation, and so forth). Do you know of anything similar in the Android world that developers can rely on?

RB: I think you can rely on the Material Design guidelines themselves right now. They give you at least the basics. After that, it’s going to be largely a case of going through the guidelines and being aware of them.

More to Kaushik’s point about what he should do, what I’m actually going to say is: don’t get into a rush with code. I would highly recommend taking a step back and ensuring that you spend time on your designs while they’re in sketch. Create some prototypes for them and test them out in InVision. That’s how you should probably go about it. There’s a little quote from IBM’s research wing which talks about how every dollar spent on design and research can save you about ten dollars in development costs and a hundred dollars in post-release maintenance. I highly recommend remembering that.

The process that I would recommend is something called a design sprint. Google talks about it quite a bit. It essentially gets you to really understand your users, do a lot of prototyping really quickly, and test it out with them—all inside a week—so you’ll know whether your design is actually working.

KG: So can you talk a little about design sprints? For example, if Donn and I were to sit down and say, “Let’s build this thing together with a design sprint integrated into our workflow,” what would that look like?

RB: The first day should be spent doing interviews. Ideally, I’m talking about interviews within your team, but if it’s just the two of you, you’ll have to figure out who else you can do this with. In these interviews, you’re trying to create a user journey map, where you put the user on the left side of it and the goal that they’re trying to reach on the right. Then you kind of draw a map of how they’re getting to this goal currently—through an existing product, through a bunch of products, or whatever. In this map, you essentially need to find where the pain points are for the user. The suggestion is simply to fix those pain points. So day one just shows you the opportunity.

After that, you try to go as wide as possible. You sketch out a bunch of different ways that you could potentially solve the problem. You’re just doing very rough designs yourself, using pen and paper—not even touching your laptop yet. Then you share these between the two of you or the rest of your team, and you talk through each thing, determining what seems to be a positive idea and what seems less strong. Then, on day three, you essentially create a storyboard, where you agree upon how you’re going to solve this problem. Once you have the storyboard, it becomes a lot easier to create your designs and make a prototype, since you now know exactly what designs you need to create. That’s the remainder of days three and four.

Day five involves finding five people whom you can test these prototypes out on. Take them through it, and see whether or not it’s working for them. Try to ask them questions which aren’t very leading. Don’t ask them, “Is this the best design you’ve ever seen?”

KG: “Is your mind blown by this design? Is this the best thing you’ve ever seen in your entire life?” Those are probably not great questions.

RB: One of the most common mistakes that people make in user research is asking people whether they would use something that does this. Particularly if the feature is free, users will almost always say yes. It doesn’t matter whether they would actually use it or not. What you need to do is glance at their behavior, and then understand from that whether it’s a good fit for them or not.

KG: That makes sense. The user journey maps you mentioned are actually pretty fascinating. Even as you were saying it, it made sense to me. If folks are interested in coming up with an application design or something, I imagine that that could be pretty useful.

You said that you studied about different patterns. Can you talk about that process? What were your findings, specifically on Android? Did you discover any patterns of usage when you conducted these studies on Android users?

RB: In the second half of 2016, I did a lot of research in India, a part of a demographic called “the next billion users”. It’s not really a marketing term, though it comes across like that. Cisco has data pointing to an increase of about a billion internet users between 2014-2019. As you’d imagine, a lot of these users are in India itself, where internet penetration is pretty low (but it’s picking up a lot).

Companies like Google and Facebook, for example, are promoting this a lot, but they focus on the technical side. One of the things that I realized was that these users have never used a computer in their lives. The first computing device that they’ve used is probably the smartphone that they picked up. So far, they’ve only used a feature phone. So, one goal of mine was to test out a few very different, but common patterns (or gestures) that we have—things like search, buttons, and swipes.

I gave these people very easy goals to test out with prototypes, whether or not it works for them. That’s when I realized, for example, that search is something they’ve never used. They have no idea, because (since they’ve only been on feature phones) they’ve never really performed a search. How I recognized that was by giving them a fairly standard dialer application and asking them to dial the number of a contact starting with the letter R. Every user would scroll down to get that, instead of tapping on the search icon right there in front of them. Then, when you talk to them about it, you realize that they’ve never been taught the concept.

Another thing that they’ve never really done is horizontal swipes. Again, that’s something that (on Android in particular) we take for granted with the top tabs themselves. When the argument of top nav versus bottom nav comes up, we say, “Hey, you just have to swipe to get to the next one.” But these people aren’t used to it. Even when they figure out that this is a tab interface, they tap on the ones on top instead of swiping through it.

The buttons are especially tricky, because we take it for granted that people will understand the icons that they have in front of them. But the thing is that icons are sometimes not really clear to the person. We sometimes joke about how millennials have no clue what the save icon is, since they’ve never seen a floppy disc. But these people have never seen a mouse in their lives. Communicating these things to them becomes even more challenging at that point.

Simultaneously, a lot of these people are illiterate, which means that they can’t even read their own regional language, and certainly not English. So buttons in particular get very challenging for these people.

KG: And these folks are still using smartphones today, even if they can’t read the language?

RB: The people whom I researched about were specifically people who had never used a smartphone. They were just about to, though, because they had signed up to drive for Uber. I had the opportunity to go there and interview them before they got their smartphones. A lot of Uber drivers in India are new to smartphone itself, and you can see how they’re struggling with much of the interface. For example, I saw one driver on his first day who had actually missed out on cash from his previous ride because he canceled the ride by mistake instead of ending it. He kind of held onto me and said, “Please, end this ride for me.” They have a button to end the ride that you have to swipe across, so he swiped across it. Then every next button that came up after that, he tried to swipe across. When it asked him to rate me, he tried to swipe across to give me five stars instead of just tapping on the fifth one. When it came time to submit, he again tried to swipe across the button instead of simply tapping on it.

KG: Wow, that’s fascinating. He’s straining his model in real-time to understand how this interface works.

RB: The thing that I noticed is that these people need very clear cut affordances to make them understand what they need to do. The swipe button at the beginning had a color gradient that comes across the rectangular button, and he didn’t quite get that. It’s very possible that in the bright sunlight, he didn’t even notice that glare going across. Then he was trained to swipe across, so he just kept swiping across every button he sees.

KG: I didn’t even think about that.

Following up quickly on something you mentioned (I’m pretty sure everyone is interested in this): you know how Google has finally added bottom navigational tabs officially to Material Design as well. So (you know where I’m going with this) what are your thoughts about adding bottom tabs, because this is something that comes up all the time?

RB: It’s one of those things where I’ve come to accept it recently. It makes sense if you have a hamburger menu with options hidden in there. Ultimately, the entire reason for the bottom nav is that the devices are getting bigger. We’re at a point where the average device is about five inches, and it starts getting really difficult for users to reach the top. In that sense, I’m okay with it. I do think that you shouldn’t just say, “I have to add a bottom nav because it’s the flavor of the season.”

KG: So are there any interesting quirks or differences in behavior that you’ve noticed when you’re designing for the next billion? I know that you brought that up in your presentation at DroidCon NYC. You also mentioned the studies you did on folks who were signing up to be an Uber driver. Is there anything we take for granted as Android developers that probably should be highlighted?

RB: As an Android developer, the biggest thing to keep in mind is that a lot of these users don’t download your apps from Google Play. I don’t necessarily mean that they pirate your stuff. The tend to get even free applications through Bluetooth from their friends. There are a few applications which are really popular over here called Xender and SHAREit. They essentially allow you to rip out the APK of your current application and share it over Bluetooth or local WiFi with somebody else.

KG: That disturbs me on so many levels.

RB: I came across this with the messaging application that I’ve worked at. One of the users was complaining about how he was unable to receive the messages, and I asked him what device he was on. He was on a Nokia X—and I was thinking, “How did you get the app?!” They only put the app on Google Play, and it requires Play Services. That’s when I came across these.

DF: How does this work? How are they getting these apps?

RB: Xender and SHAREit essentially allow you to rip out the APK of an app that you have installed, and you can just keep sharing it.

DF: So I just walk up to you, and it helps us share the app via NFC, Bluetooth, or whatever?

RB: I think it establishes a connection over Bluetooth or local WiFi.

DF: And that’s a completely normal thing in that region?

RB: Exactly. It’s a complicated market. I don’t have the data to back this up, but a few people have pointed out to me that Chrome only has a 50% market share of mobile browsers in India, despite the fact that Android itself has a 90-95% market share.

DF: Wow. What other browsers are these folks using?

RB: There’s a browser called UC Browser that’s very popular over here. It’s primary goal is to boost data saving, because a lot of people are on 2G (or even 3G) connections with very small packs of data—maybe 300 MB per month.

KG: I remember that Opera had an app called Opera Turbo which tried to minimize data usage.

RB: I used to use Opera Mini back in my Nokia days. I think it’s still around, but UC Browser is really big in the market right now.

KG: The other thing you mentioned scares me, though. Sharing of APKs… I imagine that it somehow figures out the architecture? What if it’s an ARM architecture that’s completely different? What if it was built specifically for one architecture? That boggles my mind. I imagine that the app accounts for that. Play Services are a problem. The other thing is that I imagine these are rooted phones? Otherwise, how do they pull the APKs, since this is an external APK, not their own application? My mind is already hurting from thinking about this.

RB: I’m just going to make it worse for you: users in India do not tend to update their apps as quickly as you would expect. Once you put an app out there, it’s going to stay around for a very long time, installed on these people’s devices.

KG: And shared across multiple devices, so it compounds.

RB: Be very careful of what you push out.

KG: Folks, no bugs. Ever.

DF: There are so many folks out there included the next billion, so I’m just going to stick to the region of India, which is where you have the most experience. What kind of devices do they mainly have? If you had to guess (I’m not looking for exact data here), how many folks are currently using a smartphone, versus a regular old feature phone?

RB: If I remember correctly, the number is around 300 million smartphone users. The Internet Association over here points to about 400 million Indian internet users. A lot of us don’t believe that to be true. Facebook shared some data recently about it’s 170 million users in India, so I think the number is probably going to be closer to 250 million or so. What could be happening is simply that these people are internet users, just very, very infrequently.

DF: If I’m designing an application, taking into consideration these next billion users and all of the things that you’ve talked about—from folks swiping buttons because they’re still learning, to people being introduced to mobile phones in general—what’s the lowest common denominator that I should be designing for? Are there any tips and tricks you can provide to developers so that they can give their app the best chance of being user-friendly to that next billion?

RB: I think a lot of us take pride in not having tutorials in our application. We don’t want any coach marks or stuff like that. You need to realize that these people are trying to pick up the design of your application itself. Especially if you’re using gestures, something that might seem easy to you is probably not the so easy for other people, even those who have regularly used smartphones previously. Providing menus, suggestions, and stuff like that helps.

Of course, that also means that you don’t just do one tutorial. What I’ve found from my limited tests so far is that it really helps when tutorials are done in context. What you want to do is design your application in a way that promotes performing a certain action on the first try.

For example, there’s an application in India called PhonePe. It’s a new application for transferring money from your bank account to another person’s bank account using a pretty popular framework over here called UPI. They’re trying to promote people at least making their first transaction, because getting them to use their phones for banking is pretty new here. So they’re saying, “Even if you just transfer 1 rupee, we’ll give you 50 rupees back.” A lot of people are doing that just to get the cash back, but the huge power of it is that it gets them to realize how simple it actually is to do this. Once someone experiences your application this way, it gives you a better chance to bring them in the next time.

KG: They’re betting on convenience being the thing that wins them over eventually.

RB: Exactly. The other side of it, of course, is the fact that it’s essentially going through the old Dropbox referral system. They’re not spending money on user acquisition through Facebook ads or something else. They’re just giving it to the users themselves.

KG: A quick follow up question to that: you mentioned that, in order to maintain that high level of quality, you sometimes need to do in-app tutorials and a wizard-like interface. Are there any examples you’ve seen of applications that do that pretty well?

RB: The problem is that I can only point out the ones that do this really badly—the ones that give you all of the tutorials right at the beginning, and you’re just blindly skipping through them.

KG: That’s a great point. When I think of the simplest implementation of what most folks call the “new user experience”, usually it just stores in your shared preferences, “If it hasn’t been activated before, load this new user experience.” What’s going to happen if it’s a new device? Essentially, you’re just going to have four of these new user experiences popping up, one after the other. A good way to handle that would be to actually provide it with context. When folks use that feature, that’s when you pop it up for the first time.

RB: One thing I can think is called “activation”, where you’re trying to get your user to harness the real power of the app. Twitter does this really well when they’re trying to get new users to follow a lot of accounts at the beginning. They’ve determined that when people follow a lot of users, they stay engaged for longer. Previously, they would just push up certain accounts, but now they make you point out what your interests are and try to make you follow accounts based on that. It’s not really coaching, but it gets a user to invest in your application early on.

KG: Actually, that’s a better definition of what a new user experience would be: “How you get a new user to ‘get’ your product.”

Stepping back from a little from user experience, since we have an opportunity to actually talk to someone who understands both engineering and design, what are some common design trends that you think work well? Or even if there are some design trends which you don’t think work well, maybe you can let us know. Many times, we’ve noticed that a lot of the Android design aesthetic is suggested by the developers themselves, because designers tend to be iOS-focused. That’s just the nature of how things started. Many a time, I’ve found that the suggestions for Android applications come from the engineers themselves. So what are some design trends that you think work well, and some things that we should be aware of?

RB: On Android in particular, a good Material Design app is a given at this point. Users now expect it, so you have to meet those guidelines to have an application which does even half-decently.

A new trend that’s taken over this year is something called “complexion reduction”. The focus of this is to remove as much complexity from an interface as possible. That means a lot more white spaces and a lot less color, and tends to mean a lot more line icons and things like that. The point of it is to get straight to the content itself. It’s used by applications like Instagram, Medium, and Uber, and it works really well. What happens is that point where you really want users to focus is where most of the color and other stuff lies, so it points their attention over there. Human beings have a desire to just reduce the complexity of anything that they see to its bare minimum, and this fits in right there.

KG: Interesting. Would you say this is similar to iOS 7’s flat design, where everything was just a line or a box? I assume this is a little different from that.

RB: Flat UI essentially means that you don’t have a z index. You might have fake depth in the sense that users may perceive a background and a foreground, but you’re essentially completely flat. Complexion reduction doesn’t worry about that. You can still have the drop shadows, but you’re going to use them a lot more carefully. For example, you would probably not want a Card UI with shadows in a simple list view. That just adds color on your screen when it doesn’t need to be.

KG: As Android developers, we don’t necessarily get the time to think about these things in such detail, so this was super helpful. Thank you so much, Raveesh.

RB: You’re welcome.

KG: If folks want to reach out to you and throw in some more Android developer questions, what’s the best way to do that?

RB: You can reach me at Twitter. I’m @raveeshbhalla.

KG: Excellent. If folks want to draw out on your startup experience and all of the wicked designs you’ve been working on, Donn, how do they do that?

DF: You can reach me at @donnfelker, which would be the best way. But Kaushik, how do folks get ahold of you and your wicked design skills?

KG: I don’t know about wicked design skills, but if you want to reach out to me, @kaushikgopal is usually the best way. Thank you folks for listening, and thank you so much for joining us, Raveesh.