Designing with AnalyticsNovember 7, 2017
The idea of Analytics has surely been discussed in boardrooms all over the world. But, other than being a popular buzzword, what can analytics really provide? In theory, analytics helps take a step toward removing our rose-colored glasses to look beyond our biases and begin to understand the decisions and workflow of our users.
Analytics is more than a buzzword.
Plain and simple, analytics is a tool. As your user base grows, it becomes increasingly difficult to read through every review, email, or tweet for feature requests, bug reports, or even just inconveniences. At the same time, the users who shout the loudest do not necessarily represent the majority of your base. Although it is desirable to keep all of your users happy, it may not be wise to invest time and money into a feature that is misunderstood or not useful to the vast majority of your users. So, how can you attempt to identify your areas of need? Connecting your app to an analytics platform like Google Analytics or Fabric Answers is an excellent start. Once integrated, you will receive information about user growth, user retention, and user engagement.
With this tool, you can quickly get important information specific to your app in the form of custom events. These custom events provide additional information and can be extremely useful when making design decisions or creating feature roadmaps. For example, consider an application that wants to add in-app purchases for additional color themes and an upgrade option to remove ads. Before deciding which feature should be invested in (or possibly thrown out), use analytics to learn about users’ current behavior. If the app already has color themes, are they used? If they aren’t, is there some way to make them more obvious? Although this is a simplified example, this type of logic can be applied to many other situations. Are there any “hidden” features in your app? Are they being discovered?
Make informed decisions. Don’t take stabs in the dark.
At MichiganLabs, we use analytics as a tool to understand which features of an application are used the most, and how the users got there. What might our users have attempted to do? How can a workflow be simplified? Are we misleading our users by making a specific part of the app look potentially tappable but doesn’t do anything? What if we track how many of your users have been misled? (Notice my word choice of “misled”. If users are not doing what you intended, this may be pointing toward a design flaw.)
In a recent beta test of one of our apps, we implemented a basic card user interface layout where cards could be swiped from side to side. To make it more apparent, we displayed a portion of the previous card and the next card on the sides of the screen. Our intended behavior was for a user to simply swipe whenever they would like to advance to the next card. To be cautious, we also added arrow buttons at the bottom of the screen that perform the swipe for the user. On button press, the swipe animation is shown in an attempt to encourage the user to swipe the next time they decide to change cards. The screenshot below includes some of the data that we received, and most importantly data we received without needing to monitor their actions. As you can see in the results below, 85% of the transitions between cards were via a gesture (a swipe).
This data is extremely helpful and provides very useful information for future revisions. Although we identified that the majority of the time a gesture is used, 15% is still large enough to have some concern. However, because we have live data, we can continue to monitor how the screen is used and make intelligent decisions over time. Before we start jumping to conclusions, we can start to ask ourselves some more questions.
- What if we were to track this information per user? Do most users start out by pressing the arrows, and then transition to swiping?
- Could we add a message to the screen informing the user that swiping is available? Does this have any effect on our percentages?
- What if we simply wait? Do we even have enough data yet? Notice that when this picture was taken we only had a few hundred events. Before making critical business decisions it might make sense to just wait.
Optimize for your users.
Remember, your users are unique to your application and expect your application to work in its own unique way. Just because a decision was a good one for a similar app, does not mean it will be a great design decision for the next. Learn from your users and attempt to understand the areas of weakness in your own app. If features are not being used, make design decisions to draw more attention to the functionality. If a feature continues to remain unused, consider removing it or halting any future improvements.
Ultimately as the product owner, you hold all of the power and can continue to develop and design in whichever way you wish. But, with the power of analytics, you can learn about your users behaviors and use real data to influence your decisions.
Stay in the loop with our latest content!
Select the topics you’re interested to receive our new relevant content in your inbox. Don’t worry, we won’t spam you.
Putting a Kettle On: Server-Side Swift with VaporMarch 23, 2020
One of my goals this year is to make a concerted effort to try out Vapor for server development. As a framework for making server applications in Swift, I’ve had my eye on Vapor since the 3.0 beta period many moons ago. The release of Vapor 4 seemed like as good a time as any to dive back in.Read more
Why I use NextJSDecember 21, 2022
Is NextJS right for your next project? In this post, David discusses three core functionalities that NextJS excels at, so that you can make a well-informed decision on your project’s major framework.Read more