Improved first-time login experience

[jshorland]

• Begin every deployment with dummy data set only viewable by admin to help educate
• Create tutorial layer about how dummy data works and how to setup deployment
• Login by social signup?

Needs user testing.

[jshorland]

Assigning us all to indicate we'll need to scope, design and stage a user test for this

[jshorland]

Note: we need to have to have this in "dev up next" by end of quarter.

[brandonrosage]

I've put together the pieces to a first pass at scoping and designing the solution to this need.

First is a modest scope, which takes an iterative approach to rolling out an increasingly "smart" onboard tasking system.

• Version 1 is the lightest technical lift, using Intercom more dynamically to suggest on-boarding tasks related to the configuration of their deployment. It would all occur in Intercom's in-app chat tool.
• Version 2 would provide a more immersive, step-by-step experience for on-boarding (replacing Intercom as the tool guiding this process), with the option to "do this later." But there is not yet a systematic way to remind the user to return to the task(s) they skipped.
• Version 3 uses email to periodically remind the user about tasks they haven't yet completed.
• Version 4 uses email and Ushahidi's built-in Notifications (yet to be completed) to deliver these reminders.

Second is a simple UX concept for what an Intercom-powered on-boarding solution might look like in Version 1.

Third is a semi-interactive wireframe that illustrates what the user experience might look like for a more immersive Version 2. Highlights include:

Language

I've front-loaded the "Language" control to the "Create new deployment" process so the subsequent on-boarding is done in users' chosen language. It should also help them understand which languages are supported before they commit to creating a deployment.

Survey building

Including survey creation so early in the process underscores their value and importance to data collection. In this iteration, it gives them a blank slate. No placeholder survey or template.

Data source configuration

Including data source configuration immediately after survey creation improves our communication about what they're for and how they're related. A noteworthy piece here, I think, is the treatment of the "survey form" as a data source alongside email, SMS, etc. By selecting any of the data sources not yet configured, their controls are displayed in a modal (e.g. try selecting "Email").

User + role creation

There is just one question we're asking people in this step: "Who else is working with you?" There's not a separate question focused on roles. In this case, when you add a person, one of the controls is "Role," from which you can choose an available role or "Create new." By choosing "Create new," the "Roles" select control would be replaced by a fieldset for defining a new role:

The user could then define this new role or go back to using an existing role by selecting "Use an existing role," which would replace the fieldset with the previous select control.

Share

When the user has reached the end of the on-boarding flow, they're delivered to the (empty) "Map" view, with a "You're all set!" message that prompts them to share their deployment. When this window is closed, they're dropped into their deployment with no more hand-holding measures.

---

In addition to any questions y'all might have, it'd be really helpful to get feedback from a few folks in particular:

• @jshorland: Both in scope and execution, does this seem reasonable to pull off before Q3?
• @rjmackay: Have I presented a solution that's reasonably within the technical boundaries of what we've built so far?
• @aoduor: Did I address all the touch points we flagged during our work in Aberdare?
• @caharding: How are you feeling about the flow I've presented here?

[aoduor]

I really dig this, @brandonrosage. As a first pass, i think this looks good. As we continue to iterate, it would be great to figure out

1. Where elements of training/showing them HOW to perform these tasks would fall into place. The simplified questions help quite alot, but we still need to show them how to do it. Maybe it'll be as simple as links, but we should think about this.
2. How to tackle templating based on focus areas they select on deployment creation - in as much as we may not be able to handle that right now - but just make space for it?

That said, i think, looking at our initial commitment, this looks pretty good to me.

[brandonrosage]

Note: I've revised my summary above to include work I've added in order to outline Version 1: Intercom-powered on-boarding support. That work is included in the scope for the overall issue, as well as in the addition of a UX concept for the Intercom-powered solution.

Example:

This was largely in response to @KrisKuri's comments in the Support & Engagement meeting Tuesday, as well as the "Intercom strategy." Let's get this effort moving and fully-detailed.

[brandonrosage]

Where elements of training/showing them HOW to perform these tasks would fall into place. The simplified questions help quite a lot, but we still need to show them how to do it. Maybe it'll be as simple as links, but we should think about this.

I think it'd be ideal for each of the messages I've drafted in the UX concept to include links to relevant ushahidi.com/support pages (or embedded content, like videos). I haven't included it, however, because it's not clear what that content would be, how it's going to get created, or when. So short of those details, I designed a solution we could implement right away.

How to tackle templating based on focus areas they select on deployment creation - in as much as we may not be able to handle that right now - but just make space for it?

In my mind, these considerations would be made for Version 3 or 4, where we know we have the ability to design solutions that require non-trivial developer support. I agree, we should save space for, say, pre-packaged surveys that deployers can choose from during the "Design your data" step. But I don't think we should design that until Version 3 or 4.

[caharding]

In my mind these onboading tips should be in addition to an in product tutorial, which will be much more helpful as a visual aid. These sorts of onboarding tips should only appear if people fail to complete essential functions I'd think.

[brandonrosage]

As I understand your comment, @caharding, you're saying that Version 1 (Intercom messaging) and Version 2 (immersive, step-by-step) need to co-exist -- that they can never stand alone in the absence of the other.

Is that what you're saying?

[brandonrosage]

The Intercom-powered v1 on-boarding campaign is staged.

Just waiting on devs to configure the webhooks we need in order to send these messages to the right people at the right time.

[caharding]

Fantastic!

[aoduor]

[jshorland]

Related: #1891

[rjmackay]

@jshorland I have no idea whats needed on this issue anymore?

[rowasc]

Relevant context for ushahidi/platform-pattern-library#205 but it appears the tasks listed were merged so closing in favor of the new UI refresh tasks