Making our account managers appy

The title of this post is an obvious reference to a famous GDS blog post by Tom Loosemore back in 2014.

Tl;dr – native apps are bad, web apps are good.

Which I wholeheartedly agree with, on the whole. The web is open and free. Native OS apps are neither. Given a choice, for a general audience, I’d always favour the web.

But there’s always a but

I’ve been working on a project for a year or so now to see what we can do with Microsoft Power Platform tools. We’ve been co-designing with a group of Scottish Enterprise account managers, who work with early-stage businesses with the potential to grow very quickly.

This has meant developing both a client-facing account/website, and a Power App for staff – they both read and write from the same data source, so each update the other.

We’ve done tons of research with both the account managers and their clients, and one of the user needs we identified was that our account managers, when they’re on site with clients:

• usually don’t have their laptop (why would they?)
• commonly will arrange to visit 2 or 3 companies in the same area on one day, to minimise travel
• sometimes like to have an “aide-memoire” to hand, to remind them of the business’s origins, aims and ambitions (this is especially true of businesses they’ve only recently started working with)

Options

Given these findings, we tried a few things, such as making it easy to print crucial information about a client, rather than copy/paste content from our CRM system into Word and then print that.

That helped, but was hardly a game-changer.

So we thought some more. How can we get the information our high growth account managers need, to wherever they are, whenever they need it?

If you put it like that, the answer is obvious: get it onto their phones.

We used storyboards like the one above to illustrate different scenarios, or use cases, where a mobile app would be useful. And they seemed to resonate. So off we went.

Building a proof of concept

My colleague Emma did all the work here.

As Emma experimented and learned, she added more and more functionality. I simply made a map of it as she built it.

It quickly became apparent that, if we didn’t set constraints, we could end up spending the rest of our project exploring what we could do, rather than understanding what we should do.

Back to users, and their needs

So I spoke to a couple of account mangers to understand their days out of the office. Based on their feedback, we came up with a product brief:

The app should be 100% focused on one scenario: a high growth account manager who is out of the office all day for on-site meetings with clients.

• Access should be only to accounts in the Account Manager’s portfolio
• Focus entirely on tasks and actions commonly encountered in these circumstances, e.g.
  • Arrange a follow-on meeting with the client
  • Add a meeting note
  • Add a reminder/task for themself or another SE employee
  • View ‘aide-memoire’ content about the business’s background & ambitions, current projects
  • Email, message or call members of the account team
  • Email, message or call contacts at client businesses
  • Get directions to/from client’s premises

This introduced guardrails for Emma and Krzysztof, our UX/front-end developer: go this far, and no further.

And so to build

So, we are now building a native mobile app (albeit PowerApps are just web pages in a wrapper) available for either Android or iOS.

It’s an experiment. We’ll see if it works out.

OKRs

1. Takeup: 2/3 of account managers in the control group (there are <20) choose to install the app
2. Usage: In-app metrics show that 66% of those who installed the app use it once a week or more
3. Standard UX metrics:
   • Effectiveness (can users do this without errors?)
   • Efficiency (how long does it take?)
   • Satisfaction (1-5 rating of ease of use)