Citrix GoToAssist App

Autumn 2015

GoToAssist is a suite of products that we’re working to unify. As part of this unification, we need to define a mobile strategy – and validate it. After some discussion with stakeholders, I worked with a product manager to define this concept app for Unattended Support (i.e. no human present at the endpoint) within the Remote Support use case.

Why Unattended?

GoToAssist has many use cases, so why start with Unattended Support?

  • It was something we could build on a single platform (Android), and the developers for that platform were available to us (other teams were engaged in other projects)
  • It was (somewhat) within our current technical capabilities – feasible to do
  • It’s a logical stepping stone from where we were to where we wanted to be – we’d like to rebuild both technical architecture/the mindset behind how people are thinking about providing Support. We can make a new app, absorb important features of the old app in this new technology stack & then kill the old app.
  • Unattended sessions were not something we completely understood, and it was an opportunity to do research on the use case.

To Begin: Research

I’d always wanted to do some research on our Unattended use case with this project, but the questions I had were quite broad. To narrow them down, I needed to define a bit of a direction.

We threw together a Google Doc with a ton of ideas for what features this app might have. We tried to be really broad and open minded and ended up with many ideas – some novel, some normal, some crazy – but crazy’s good at this stage. We gathered together relevant stakeholders, discussed the ideas and boiled it down to a few we could

  • be sure would provide users with enough new value that they’d actually use this app over the existing one
  • do easily – we didn’t have many resources to invest
  • test and validate in a simple way

Most of our ideas ended up being around data we wanted to pull from the machine, or actions we wanted to push to the machine. A lot of our Unattended use cases were actually attended machines that our customers wanted to administer without involving the human on the other end.

Now that we had an idea of the direction we wanted to go, I could put together the survey.

The Survey

We sent a 20 question survey to a bunch of customers, and I spent a week going through the results. Unfortunately, it was difficult to ask the questions we wanted to ask in a way which provided easily manipulatable answers, so the majority of the time was spent trying to categorise issues/ideas/potential features. We also used this as an opportunity to figure out some usage patterns which we couldn’t discern from our system data – and whether or not users were actually able to perform the kinds of tasks they wanted to from our app.

I put together a document which made the data easily digestible by less-technical stakeholders. Also the survey raised some issues outside the scope of our challenge, but which was important for others to know about – so more digestible data made it easier to bring them up to speed on those issues. The survey gave us valuable insight into how people use and perceive the tool, much better than NPS (which I’m not a huge fan of) or usage data.

All of this influenced…

The Spec, The Sketches

The idea document was then further refined into a specification. A single sheet of A4, with a straightforward goal (which unfortunately is private and can’t be shared).

From here, I put together some sketches to bring the idea to life & discuss with stakeholders.

Sketches

High Fidelity Mockups

From here I created some high fidelity mockups and an InVision click prototype to send to customers. The scope of the project was quite narrow, so I felt comfortable moving to high fidelity mockups more quickly. We iterated on a few small details – primary actions, how to lay out different types of data most efficiently – and ended up with the following (including a few variations on primary actions).

Diagnostics & historical data

The primary function of the app is to "check in" on machines, perhaps because you've been sent a Monitoring alert. Making this data easily accessible and digestible was important.

Actions

For our MVP, we decided against being able to perform actions on multiple machines. It wasn't a top priority in our survey data, either.


Starting an attended session

A little outside the scope of this project, but somewhere we eventually wanted to go with it - so I mocked it up.

Outcome

Unfortunately this got put on hold due to changes in priorities. We never got to test it: but we learned a lot about our Remote Support users, and the whole exercise was good to help us assemble a strong overall mobile strategy alongside our concept development.