On the Importance of Supporting User Goals, an Example
On the Importance of Supporting User Goals, an Example
Join the DZone community and get the full member experience.Join For Free
Microservices. Streaming data. Event Sourcing and CQRS. Concurrency, routing, self-healing, persistence, clustering...learn how Akka enables Java developers to do all this out of the box! Brought to you in partnership with Lightbend.
If you have seen any of my conference presentations you are aware that I keep raving about understanding and supporting user goals in your app design. Supporting users on what they actually want to get done is more important than visual design or even following design guidelines. By that I mean that no matter how great visual polish the app has or great design pattern it uses, the app will fail if it doesn't help users achieve their goals.
When designing an app you rely on previous layers and build on top of them. The bottom layer that everything is based is the understanding of users and what they actually want to do with your app. Without this everything else will crumble.
Failing in User Goal supportI've been using an app that completely fails to understand very some basic user goals and I wanted to use it as a negative example of what kind of problems can be caused to your design when the design is feature focused instead of user goal focused. Later in this post I'll look into other issues in the app but they're not nearly as important to understand as the very first ones.
The app I'm going to be focusing is called Watchever. It is a German equivalent to the Netflix streaming service. It allows subscribers to stream any movies and series from their selection without additional cost.
Unfortunately, the app is disastrous. Not only is it buggy, ugly and fails with pretty much all Android guidelines but it is also built (at least partially) from very feature driven point of view. Let me explain.
The app's landing screen / home screen is divided into sections. The sections make various amount of sense but let's take a look at one of them. The third section after a featured graphic and "My Bookmarks" is "Already Watched".
A fair question arises when looking at this. Why is this here? What user goals this supports?
You can probably think of some that could be reasonable and even high enough priority to justify this section on the front page:
- I started to watch a movie but didn't complete it. Now I want to continue where I left it.
- I've been watching this series and I want to watch the next episode of it.
Here is why the section design is unlikely result of any real user goals but instead a feature added without further thinking:
The app does not show only movies I've not completed. It shows everything I've actually watched. There's also no way for me to know if I've completed the movie, when I did it and how many times I've watched the movie. All of which are important personal information the app should know and show me to support me in my decision making. The movie detail page is empty of any my personal information (other than my rating).
But what about the series use case?
I'm afraid the app doesn't fare any better with it. When opening a series page there's no information about any of my watching history. I have no idea which episode was the last one I watched. A small consolation is that if I hit the "Play" button the app will actually continue from where I left off in this season of the series. But why isn't this information visible to me? Series are also divided into individual seasons so you have to remember which season you were on or you'll not be able to continue from where you left.
Unfortunately, these are not the only places where the app fails to deliver the content in the right way to the user. It is littered with designs that were not well thought or incomplete. To me it looks like the team lacked the right processes to create end-user facing UI.
Issues like these create frustrating user experience. Users either have to remember things the app could remember for them or force users to find usage patterns that are out of the ordinary and unnecessarily complex.
Remember: your app should not contain a single feature that is not derived from a user goal! Every single component, screen and animation should help users to reach the goal they want to achieve with your app!
Android design guideline failuresThis app requires some serious rethinking to fix its UI. It is also littered with issues of lower level UI design mistakes and some Android-specific problems.
Tabs do not work this wayThe way the app uses tabs (its core navigation) is just plain wrong. This might be due to the heavy influence of iOS in the app design but that's a poor excuse. Tabs should be used on navigation on the top level. When diving into detail pages the tab bar should not be there anymore. Keep your app's navigation simple and one directional. Separating detail pages from main pages will help your users understand your app's content hierarchy.
NitpickingI've been accused of nitpicking a lot in the past. In fact, so much so, that I've decided to give a talk about why detail matter in UX in the upcoming Droidcon UK. These are things that force unnecessary cognitive load to users or force them to stop to think where no thinking would not be required.
Mixed terminologyThe app's main audience is German so it might very well be that the English translation is not given as high priority as the German counterpart but mixing terminology when it comes action and action labels is a very bad practice.
Is it an offline-mode or travel mode?
In fact, there's no difference. They should be called the same. The difference in labeling forces users to pause and think "what's the difference". It doesn't seem like much and users will likely understand it but why add this burden to them? Let them concentrate to the actual task in hand.
The actual app content naming is also inconsistent. The same episode of the same series have (at least) two different formats for naming. While most users will most likely understand that these labels refer to the same episode why do this? Make sure you refer with the same label to the same content everywhere in your app.
Ha! Gotya!One of my pet peeves is actions offered to users that are not actually available. The app allows users to download content for offline viewing (travel mode). There's a limit of two concurrent downloads. While the limit itself is fine it should be indicated better.
If I already have two downloads in progress and try to start third I get a pop-up on my download pop-up (ugh!).
This one would be very easy to fix. Just make sure that the download buttons are disabled when user cannot add new videos to the download process or even better, keep the rest of the videos marked for download in local queue and start the download automatically once the server allows it. That's what user indicates that he or she wants (user goals again!).
Search, I don't even..The action bar search in this app is something that really baffles me. The app's fake Action Bar has a search button. Tapping it brings up Android's contextual Action Bar and search. It works pretty nicely but exiting the search isn't that simple. Pressing back to dismiss the keyboard and then the search will bring you to another search view and pops up the keyboard again. This time you're in the fake Action Bar search.
How did this got through to the release?
Moving responsibility to usersThe app's travel mode could be one of the features that push competitive advantage to them over many competitors. Many of the competing services do not allow me to watch movies on the plane or elsewhere without internet connection.
Unfortunately, the implementation in this case falls flat. For some reason the app moves responsibility of moving between offline and online modes to the user. Users have to manually trigger switching the modes.
When switching to the travels mode the user is even greeted with two consecutive pop-ups. I hate pop-ups!
I can't wrap my head around why this is done the way it is. Android platform provides developers tools to detect internet connection availability and the app can react to this automatically.
A great example of handing the very same use case is Google Music. Simply use the same interface offline and online but indicate the users what is available to them (and allow users to filter the views). Even better would be to adopt the pinning pattern used throughout Google apps to allow users to download content offline.
SummaryThe Watchever app gives us an example of an app that will require a lot of work to fix. It is barely usable in its current form and the company is sure to lose a lot of its customers to any emerging competition.
Fixing the app would require foundation work and better understanding of users and user goals. Fixing smaller issues in the app would likely result into marginally better user experience while still failing to create acceptable app.
Often, when I review apps on this blog minor fixes could elevate the apps to decent standards but this app is demonstrating the dangers of not building proper foundations. Understand your users' goals before you start building your app features! Think how your users will use your app. Support them in their goals and make sure your understanding has been correct ( usability testing on prototypes).
In my case the unusable Android app lead to this (account terminated):
It doesn't look like other users are happy either:
Published at DZone with permission of Juhani Lehtimaki , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.