Press "Enter" to skip to content

Tag: product improvements

Are you paying enough attention to the little things?

Published February 9, 2017

I consider things like loading indicators, success notifications, error handling, and other user experience niceties as “little things.” They can make a product more enjoyable to use, more helpful, and less confusing — but they’re typically not going to move the needle in a meaningful way for the business on an individual basis. I’ve found that there are consistent opportunities to fit these kinds of little things into your design and development plans without costing you business priorities, and in aggregate they can elevate the overall user experience of a product.

Examples

Success notifications:

One of my favorite little things is a checkmark that appears after you’ve successfully done something, such as adding an item to a list or updating a profile. I refer to this as a “success notification,” which come in many varieties.

  • The text that accompanies the checkmark can say whatever is appropriate for the action that the user took (e.g., “Added” or “Updated!”)
  • In some cases, it’s fine for the message / checkmark to automatically fade away after a second
  • Bonus points if the user sees the checkmark draw itself (but this is of course more time consuming to implement)

giphy.gif

Loading indicators:

Waiting for a page / screen / module to load can be frustrating for a user if it lasts more than a second, so having a nice loading indicator is an opportunity to prevent dissatisfaction. Any kind of indicator is better than nothing (e.g., a simple spinner), but some extra effort can make it a good experience.

Pull-To-Refresh-action.gif

Seeing the above isn’t so bad, right? It makes me think about the indicator, as opposed to the fact that the data on the screen hasn’t loaded yet.

Compare that to a very basic loading indicator:

And compare both of those to a complex (and very nice) example that’d take more time than most early-stage companies have for this kind of thing:

So where should you end up on this? How about a spinner, but a little more interesting than the most basic kind, such as:

It’s great to find ways to reduce loading times (such as by caching data, removing unnecessary data, or loading multiple things asynchronously), but loading time is a reality and you can prevent it from being an unpleasant one.

Error handling:

Plenty has been written about creative 404 pages, but error messages are another area that deserves attention.

I’ve seen error messages that aren’t clear what the problem is, aren’t helpful with how to resolve the problem, and don’t seem like they fit into the design of the application that they’re a part of. A little bit of descriptive text goes a long way, and a tiny bit of design attention is better than nothing.

Don’t overlook error messages as part of your user experience approach.

Planning

I like to have yearly, quarterly, and monthly plans when it comes to roadmapping.* These plans outline an approach to hit company goals while solving for user needs. Examples of company goals are increasing sales by X% or $Y, or reducing churn by Z%, within a set period of time.** A roadmap should be focused on achieving company goals while solving customer problems, but with some planning, you can likely also fit in some “little things” along the way.

I suggest doing advance planning for the little things just like you should be doing advance planning for the bigger things that are aimed at company goals. If you identify something that could be made nicer with a little thing, add it in your backlog or other type of planning documentation and prioritize it appropriately.

At any time, if something needs to get bumped from your plans, it should be the little things. With this approach, you’ll be focused on company goals and solving important customer problems, while also delivering value via the kinds of nice little things that are often missing from products to improve a user’s experience.

*I also build an idea of where things might be more than a year into the future, but that’s on a higher level with less detail because things are expected to change over time. Things also change within a quarter or even a month, but items on a roadmap within the next quarter are typically rearranged and not cancelled, while items more than a quarter out are more likely to be cancelled. So, have a vision for where things can be in the future, but don’t spend significant time on the detail.

**It’s important for any goal to have a target (i.e., a number to achieve), a deadline (i.e., how much time you have to achieve it), and a clear way to measure progress. Define success, measure it, learn from it, and report on it.

Comments closed

Improving the Pocket app

Published December 23, 2013

This is the first of a series of posts where I’ll be looking at potential improvements to products.

Pocket is one of my favorite apps and I was recently asked what I’d improve about it. The Pocket team has done a lot of great work outside of the app, including:

  • An ease of adding content into your items list for future consumption: you can save items to Pocket via email, a bookmarklet, and hundreds of apps
  • The ability to use the app on many devices, including smartphones, tablets, computers, and even some e-readers (they’ve integrated with Kobo)

I point this attention to outside the app because the consumption experience and sharing capabilities inside the app are pretty good. There are always opportunities for tweaks and optimizations, but some higher impact changes can potentially be made in the areas of discovery and sharing when users are outside the app. I think the Pocket team knows this, as they recently began sending a weekly email to users with a few suggestions of popular items that you may be interested in.

Example of Pocket app's discovery emails

This email is aimed at increasing engagement via discovery of new content, potentially resulting in more items being added to Pocket. So now Pocket has made advancements with discovery outside the app, but what’s still missing for me is a nudge to share content more than I currently do.

I rarely share content via Pocket with others. I use the app for a few minutes at a time (such as when I’m on the subway), so my focus is on reading what I have time for and then moving onto something off my device (such as getting off the train). Sharing doesn’t need to only take place inside the app — I’d explore a way to get users to share items when they’re not using the app.

The goal here is to increase virality through users sharing items. More items shared = more potential new users of Pocket. I’d experiment here with a periodic email sent to users that nudges them to share items that they’ve already consumed. This is different from the ‘discovery’ focused email described above, as here the user is already familiar with the content (it’d be a few items they’ve consumed within the past week) and can make a quick decision to share it.

Wireframe of potential sharing email for Pocket app

  • If the user is on mobile and the Pocket app is installed on the device, tapping on a sharing icon would open the app and put the user into the app’s existing sharing mechanism to complete the share based on the selection they made in the email (e.g., tapping to share via Facebook)
  • If the user is on mobile and the Pocket app is not installed on the device, tapping on a sharing icon would open the web app in the device’s browser with the user auto-logged in and they could complete the share
  • If the user is on desktop, clicking on a sharing icon would open the web app with the user auto-logged in and they could complete the share

The best number of items to include in the email could be A/B tested, but for the sake of this post let’s go with 4. Here’s how they’d be selected:

  • If the user consumed 5 or more items during the past week that they didn’t already share, include the 4 that were most popular based on what other Pocket users have also consumed
  • If the user consumed between 1 and 4 items during the past week that they didn’t already share, include all of those items
  • If the user consumed 0 items during the past week, send the same ‘discovery’ email that Pocket currently sends (with no built-in sharing element)

In some cases a user will have only consumed articles and no videos, or vice versa, but here we’ll assume it’s both.

Depending on which metrics are most important to Pocket, the results of this new ‘sharing’ email (the goal being to increase user acquisition via some of the people who receive a shared item) could trump the results of the existing ‘discovery’ email (the goal being to increase engagement from the primary user).

One option is to combine the ‘discovery’ and ‘sharing’ emails to introduce a couple of new items to the user along with a couple of already-consumed items that they may want to share. This could be tested.

Example of potential discovery and sharing combination email for Pocket app

The following would be tracked from the emails to measure success:

  • Email open rate
  • Click-through rate on items within the email
  • Shares that originated from the email
  • New users that resulted from a share from the email

Success would primarily be determined by new users that resulted from the shares. A secondary benefit would be increased engagement by existing users who either share items or receive shared items.

Comments closed