User Experience is everybody’s job

I’ve met lots of product teams who will tell you: “User Experience is a design thing.” They hire ‘User Experience Designers’ to design the User Experience, and generally assume that they alone are responsible for the overall UX.

I believe that simply assuming the User Experience is a ‘Design Thing’ is a very dangerous mindset, for three very important reasons.

UX is in the middle between Product, Design and Technology

Within a product, the overall User Experience isn’t delivered only through design.

Certainly a big part of the UX is the visual design, the interaction design, the brand design, and so on. But an equal part of UX is the implementation of that design through technology. The danger in assuming that UX is a ‘Design Thing’ is that it quickly leads to people from other disciplines disconnecting from worrying about the User Experience at all. Every technology decision has an impact on the User Experience, which makes every engineer who is making any technology decisions – (which is every engineer) – equally responsible for ensuring a great UX.

Too often I see product tradeoffs being made where teams decide to sacrifice the user experience in favour of saving time, saving cost, avoiding that refactor or simplifying that internal process. These are all terrible reasons to sacrifice the User Experience. Additionally, sometimes the best User Experience improvements come exclusively through technology improvements. For example performance improvements, which can have a huge impact on UX, often come from deep and complicated engineering innovation.

Engineers: The User Experience is your job, too!

User Experience is also about solving the right problems for the user, and solving them with the right priority.

The user will judge the user experience to the extent that it solves their problem. A perfectly executed product that doesn’t solve a problem for the user won’t lead to a great User Experience.

This is where Product Managers should feel in command of the User Experience: in making sure the problems you’re solving are urgent and pervasive within your market segment, and that the solutions you are delivering are differentiated and defensible. Make no mistake: this has the biggest impact on your User Experience – and the resulting product success – than anything else, so it makes sense that you should focus here.

Product Managers: The User Experience is your job, too!

The overall User Experience goes beyond just the app/website/service/widget that you’re building.

When we’re working as Product Managers on digital products, we’re all so concentrated on our app, website, widget or whatever, that it’s easy to lose sight of the fact that your app is just one piece of the whole User Experience.

The overall UX starts the moment the user first hears about your product, and goes all the way to support, fulfilment, billing, etc. In other words, the User Experience spans the entire customer lifecycle.

We hire people with titles like ‘User Experience Designer’, but then put them to work designing user flows within single apps or products. To me, there is a difference between Interaction Design and User Experience design.

Interaction Design is concerned with the design of discreet experiences – interactions – within customer experiences. How does the user interact with this feature/product/widget?
User Experience Design takes a holistic view of the entire end-to-end user journey – from their first contact with the product via a marketing message, the app store or even a word-of-mouth recommendation, all the way to customer support, billing, delivery, etc.

But it’s not only the job of the User Experience Designer to think end-to-end. Everybody working on the product should have the entire end-to-end flow in mind, to understand the unique context of each user, why they are there, what problems they have and what they are hoping to achieve.

Marketeers, Support Engineers, PR folks, Delivery technicians, Logistics technicians, etc: The User Experience is your job, too!

Why this matters

Users have more ability to discover and switch to new services than ever before. Traditional lock-in effects like platform dependencies and data ownership are eroding thanks to open platforms and data portability, and there are great alternatives in every product vertical. The thing that keeps people using your product or service is the quality of the user experience, from end to end.

Companies that become great and enjoy great customer loyalty do so by developing a culture of unwavering customer focus. Sure, many companies say they are customer focussed, but actually being customer focussed is more than just a mission statement – it’s a deeply embedded culture that everyone lives and breathes from the CEO down.

A couple of examples:

  • Facebook prioritises the customer experience over everything. Facebook understands that their business model depends on gaining more and more users who each spend more and more time using Facebook. Their business is cultivating user attention. Everything else in the business comes second to user engagement.
  • Amazon is another company which was founded and grew on the fundamental premise of making the experience great for the customer. When Jeff Bezos launched Amazon.com in the mid 90s, he knew that the key to scaling massive consumer adoption extremely quickly was an unwavering focus on a great customer experience, and he considered the customer the most important thing in the business. He built this customer-first attitude into the company’s DNA from day one, and every innovation they have delivered – from 1-Click ordering, to personal recommendations, to the Kindle eReader to the voice-controlled Echo – has been about making a great customer experience and making it easier to shop and interact with your content.

A few ways to make sure you’re thinking end-to-end about UX

  • Do you share a common set of User Personas across all departments, including tech, QA, product, design, marketing, comms and support? Having a common set of personas ensures that everyone has the same user in mind when designing their solutions.
  • Does your QA team test the entire acquisition and on-boarding funnel? It’s important, but insufficient, to focus your QA efforts on the app/website/etc. You need test coverage of the whole end-to-end experience. If you don’t QA your marketing or your support functions, you should consider doing so. For example, you can test your support team with the ‘secret shopper’ approach.
  • Consider a ‘Stop the line’ policy for the User Experience. It’s a familiar concept to your engineers – certain situations within the build environment, such as test coverage dipping below a certain level, or open bugs exceeding a certain threshold, will trigger a ‘stop the line’ where no new check-ins can occur until the situation is resolved. What if you did the same for User Experience? What if you gave everybody in the product team – from Product Management and Design, to Engineering, QA, Marketing, Comms, Support, etc – the permission to Stop the line? To put a pause on building anything new until the UX issue is resolved? What impact would that have on your customer focus?

Ultimately, the User Experience is the culmination of every touchpoint you have with your customers. This experience can, and should, be designed from end to end. But it’s not just the ‘job’ of Design to get it right.

UX is everybody’s job.

Ways to think about Android Instant Apps, and what it means for developers

This week their annual developer event Google casually announced a huge new feature coming soon to Android: Instant Apps. Chris Maddern called it their “one more thing” moment. When finally released, perhaps later this year, it could be the one of the most fundamental changes to the way mobile apps work since the App Store. What it won’t be, however, is an instant solution to the majority of app developer’s main problem: app discovery.

Let’s unpack this a bit.

Android Instant Apps, as they were presented during the keynote, will allow Android native apps to run immediately, without being installed, by essentially lazy-loading the relevant modules to the device at run-time. This will allow users to interact with your app and your content immediately, without needing to go through the hurdle of visiting the app store. Users can then (presumably) install the ‘full’ app if they want to.

It’s easy to see why this is a big deal. The mechanics of installing an app involve a lot of physical and psychological friction: do I really want this app on my phone? Do I trust it? Will I ever use it again? Do I have the time to wait for it to download and install? Do I even have the space for it? (Anyone with a 16GB iPhone can attest to this being a very real and very constant problem). Apps could lose anywhere between 20 to 80% of the traffic that hits their app store page, so anything that helps eliminate this friction will be a huge win for app developers.

Then it gets even more interesting with Android Pay. According to the keynote, Instant Apps will be able to integrate with Android Pay. If we assume this gives the app instant access not just to payment details, but identity and shipping details as well, you could easily imagine purchasing something you just discovered on the web in an Instant App with just a couple of taps.

Ways Instant Apps will help app developers

App linking will be smoother and involve less friction.
Both Android and iOS have allowed native app deep linking for a couple of OS versions now, allowing developers to link into deep content views within other apps. This generally works great if the user has the target app already installed on their device; but if they don’t, the experience isn’t so great: the user is generally redirected either to a mobile-optimised version of the target product, and usually presented with a mobile app upsell ad; or they are directed straight to the app store, where the user needs to first figure out what kind of app this is, do I care enough about it to install it, etc.

Flowchart showing how apps are installed from app links

The sloppy app-install experience from app links

Some companies have been trying to improve this process, such as Branch.io who have built tools to allow developers to use ‘deferred deep links’, so that when the user does install the app after tapping a deep link they will be directed straight to the piece of content they were looking for directly after the install. But there is still heaps that can go wrong: the user needs to tap ‘install’, wait for the installation to finish, then open the app… So although deferred deep links help, they are a band-aid on an essentially sloppy user experience.

Instant apps will solve this by skipping the whole store and to-install-or-not-to-install question. Because of this, I expect to see more developers engaging in app linking partnerships and leveraging such partnerships both to monetise their own users and also to grow by seeking partners to send incoming links. The NYC-based startup Button is building an exciting business around facilitating a network of deep-link-based affiliate partnerships, and through their SDK has also tried to solve parts of the app-install problem by bringing more content into the publishing app.

Allowing easy access to rich native experiences from real world locations
Lots of brands and stores have apps already, but they all suffer from the app install friction as described above. It might be really handy to be able to place your McDonalds order in advance from the McDonalds app, but if you’re only going to McDonalds this one time, will you bother downloading the app, signing up, adding your payment details, etc?

Instant Apps would allow businesses like McDonalds to allow customers to place their order, and pay for it, quickly and easily without needing to download anything. The example Google used in their keynote was paying for parking, without needing to install any app, and – more importantly – without even needing to know which app you need. Just ‘point your phone’ at the parking meter and via the NFC connection it can figure out what app you need, lazy-load in the needed module, connect to Android Pay and – boom! You’ve paid for your parking safely and securely. Or perhaps you’re in a new city and you want to buy a ticket for the subway, but you have no idea how the system works in that city (and we’ve all been there). Just point your phone at the ticket machine, and the appropriate experience to book and pay for your ticket pops up right on your phone.

Given the ease of linking into rich experiences that this allows, I could imagine other, non-commerce use cases. Imagine Yelp issues all of its businesses a QR code. Then when you’re sitting in a restaurant and you’ve had a great meal, you could scan the code and go directly into a Yelp-powered experience where you can leave a review – without needing the Yelp app ‘installed’ on your phone. (And if Instant Apps allow users to access users’ identity, you don’t even need to create an account on Yelp either).

Preview an app without installing it
It will be interesting to see if Google build some of the Instant App mechanism into the Play store directly. This could allow you to quickly ‘preview’ an app before you make the decision to install it. Screenshots, descriptions and videos are great – but nothing beats actually using the app. What if you could preview a working version before you install?

Instant App-powered Trial Versions could become the next frontier of App Store Optimisation.

Or what if this enabled free, limited trials of paid apps? Before choosing to drop $9.99 on that newest distraction-free text editor, what if you could trial it? This could also be great for games: like Shareware for the app economy.

Will you even need a mobile-optimised website at all?
If you take all of this to the logical conclusion, you start to wonder if you need a mobile website at all. (Ok, at least an Android-optimised mobile website, for now).

These days plenty of businesses, such as Hotel Tonight, are mobile-only from day one; but for many others the web, and particularly the mobile web, remains an important discovery and conversion channel. For content-based businesses, it’s particularly important to have a mobile website to deal with the “app not installed” dilemma described above: when somebody discovers your content, either through SEO or a link from another service, you want to be able to show the user some content immediately. (Or you risk sending them directly to the app store and hoping they convert to downloading the app).

If Android Instant Apps can provide a real, native experience immediately, without downloading the app, why would you need to have a mobile website at all? You would shift your SEO focus to concentrating on Google/Firebase App Indexing, and shift your conversion funnel to the Instant App experience.

(There’s an interesting internal conflict for Google here. On one hand, Google is inviting developers to prioritise native app experiences – which when followed to the logical conclusion might very well result in less investment in the web. At the same time, Google’s control and monetisation is still heavily dependent on people searching and discovering stuff on with Google Search: one of their rationales to invest in their Accelerated Mobile Pages project.)

Where Instant Apps won’t necessarily help: App Discovery

Instant Apps could make the entire conversion experience for apps much more seamless, making it easier to access, consume and potentially test/trial apps.

But conversion is only half of the app distribution problem: the second half. The first half of the problem is app discovery, and this is where I don’t see Instant Apps helping that much – at least not directly.

Instant Apps will make it smoother to link between apps, and this could hopefully encourage a stronger ecosystem of app user/value exchange. This will help app discovery for sure. But the majority of apps are still discovered in the ‘traditional’ ways: word of mouth, content search, app store ‘browsing’, or performance/digital marketing.

Instant Apps by and large won’t let developers circumvent the traditional app discovery channels. You still need to get your app in front of a user. What it does is dramatically simplifies the conversion process, allowing more users to interact with your app and discover its value – once they have discovered it.

Things for developers to think about

What does Instant Apps mean for you? Some things to think about:

  • If you have a content or commerce-based business, start thinking about how to expand your reach through affiliate partnership building. Instant Apps will make consuming your content or service via a referred link in a partner app much easier and this can be a powerful source of acquisition.
  • Where else can you include links that could surface deep views of your service without needing an install? In marketing materials? Affiliate programs?
  • Start thinking about how to modularise your codebase now. For some apps it will be easy: Google says that some apps should be able to make the necessary changes within a day. But for other apps, depending on the architecture, it will be more complicated. Try signing up for early access to the program in the Android developer portal. But even if you don’t get in, start thinking now about how you will approach modularisation – is there a big architecture refactor you’ll need to invest in?

Growth Product Managers: You should learn to code Python. Here’s why:

Python code

<tl/dr>

Growth Product Managers and Growth ‘Hackers’ should learn to code Python: it saves time by automating reporting and analysis, and it will make you a little less dependent on your data science team and a little more confident to go looking through your analytics data yourself.

I run Growth and Monetisation for HERE’s consumer app business. We have an Android and iOS app, a mobile web app and a desktop web product. We are collecting a ton of app usage and attribution analytics, but they are spread out across multiple places: mobile attributions in Adjust, mobile analytics in Amplitude, web analytics in SiteCatalyst, and so on.

The dashboards provided by the analytics tools are great, but I found myself logging into multiple web dashboards every morning, exporting CSV files and importing them into an excel file to get just the view of the data that I wanted. I was spending 30 minutes per day just cutting and moving data around to get the view I wanted, and I decided there must be a way to automate it.

There are a few options when it comes to scripting languages to let you easily pull and manipulate data sets. Your data science team probably uses R, but for Growth PMs a great place to start is Python. Python is a general-purpose interpreted scripting language that is both extremely versatile and easy to learn. It is inherently great at working with data sets, but there are also a ton of additional libraries available designed especially for data science that make fetching and analysing large data sets, like your app analytics, really easy.

Here are a handful of things you can build yourself with a bit of Python scripting knowledge:

  • Automate checking your dashboards and compiling data in the way you want to see it.
  • Save time manually exporting CSV files from different sources and creating an Excel file to see the data how you want to see it: use python to pull all the data sources automatically and crunch them into the right format.
  • Perform basic analysis automatically at regular intervals and email yourself and your team the results.
  • Create an automated ‘early warning’ system: if any of your key metrics start changing (going up or down) at a certain rate, create an alert email. This is a script that could run automatically a few times per day to monitor key stats and email you and your team when any key metric starts changing drastically.

Example
As an example, I uploaded one of my basic scripts to GitHub. Take a look here.
This basic script does a couple of things:

  • Allows you to specify a couple of frame variables at the top for how you want the data returned: you can specify the period, the channel grouping, and choose between active or new users.
  • Pulls app analytics data from Amplitude for an Android and iOS app sequentially.
  • Adds two columns to the end, one for the standard deviation and one for the % change between the last two complete periods.
  • The script prints out the channels that have gone up or down by more than 2%. (This variable is configurable at the top of the script as well, allowing you to adjust the sensitivity).
  • For data that is grouped by Country, it will also print the % change for a list of pre-defined ‘Key Markets’.

This is just one simple example for one particular analysis – but you could write a script to pull and combine data in any way you choose, depending on the analysis you want to perform/automate.
(This post is not intended as a ‘how-to’, but if you want help, you can contact me. Also there are some resources for getting started with Python at the bottom of this post.)

The best Growth PMs live and breathe their data. Learning to manipulate and analyse your product’s data with Python will save you time by allowing you to automate many reporting and analysis tasks. The act of working with your data at a raw level will also help you fully understand it.

Your data science team are of course the experts, and you’re not likely to become more competent in programmatic data science than they are – but you can learn enough to make yourself just self-sufficient enough to be able to answer your most burning questions immediately, and you don’t rely only on your data scientists and analysts to create the reports and dashboards you need.

Resources and getting started
There are a ton of great resources out there to help you learn Python. Some assume previous programming experience, and others are designed for absolute beginners. It really doesn’t matter if you’ve never programmed before (although, of course, it certainly helps). If you have a good understanding of data manipulation in Excel, for example, you should be able to pick up data analysis with Python with a bit of patience and practice.

Some resources to get you started:

  • datacamp.com is a great place to learn the basics of Python for Data Science. The basic python course is free, and $25 will get you access to the intermediate course, which covers the most important things you’ll need when using Python for data analysis.
  • A more general Python beginners course is available at codecademy.com.
  • The O’Reilly books are relatively expensive, but they’re the classics.
  • Of course, stackoverflow.com is a gold mine for budding and advanced programmers.

Note
Although I studied Computer Engineering I don’t consider myself a programmer. My scripts focus on simplicity and getting the job done, and in so doing break occasional rules and programming best practices (I use global variables a lot, my conventions are sloppy, etc). But that doesn’t matter. As Growth PMs, we’re not contributing to a large codebase with lots of other developers: we’re programming just for us. So don’t get caught up in conventions, unless they help you write code that you can understand.