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
- Facebook research medium post: Embarking on international research
- Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems
- UC Mobile browser app
- Google Ventures : The design sprint
Sponsor
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
- @raveeshbhalla [twitter.com]
- @fragmentedcast [twitter.com]
- @donnfelker and +DonnFelker
- @kaushikgopal and +KaushikGopalIsMe
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.