Create onboarding flowchart for users of WP.org installations

[alwaysbrightblue]

Chatting in the [design channel on Slack](​https://wordpress.slack.com/archives/design), we believe documentation should exist for user onboarding. While this is somewhat related to the customizer project for setting up an install, a general user flowchart should be created.

[alwaysbrightblue]

The problem that is trying to be solved is how designers and developers create solutions related to issues with user-experience. Without onboarding documentation how do we know what the WP dev community expectation is for a WP set-up? How do you know what to focus on for issues around setup of a new install? How do you establish priority on UX problems?

The tracs for [UX-feedback](https://core.trac.wordpress.org/tickets/ux-feedback) do not show a document outlining the basic onboarding experience of a new WP user. It seems there are assumptions about onboarding, but no documentation exists. Therefore, expectations of a user setting up WP are all assumptions.

For example, there are currently discussions about the Customizer and the Editor on Slack. From what I can tell, the discussions are looking to implement features to ease the setup process and future editing of WP. As a designer, I am having trouble understanding why these areas have been identified as pain points. Are users not using WP as expected? In the WP Design Handbook, there is no documentation around onboarding (​https://make.wordpress.org/design/handbook/), so I have no basis from which to understand what "standard" onboarding results are versus "edge-case" onboarding results. I would more easily be able to participate in contributing if I understand the baseline expectations of users by the development community.

An excellent source of documenting the onboarding is being posted here ​https://make.wordpress.org/design/2017/01/18/share-a-walkthrough-of-setting-up-a-wordpress-site/ These examples are from experienced users, which would be one segment of the user base. Even from these users, we see variation in setup. Which would be considered "normal" and therefore fulfilling the expectations of the developers?

Without this documentation, it is challenging to align designers and developers on resolving user experience. I hope by establishing documentation around onboarding, the community's expectations of users are aligned. When exceptions to the onboarding occur, it will be more identifiable as an edge-case.

We can all get this process started without overthinking it. Keep it simple by drawing user-flowcharts. Contribute to the "Share a walkthrough" post. If you alreay have user expectations, please share! If you already have documentation of expected user flows for WP, please share!

Thanks for your time!

[karmatosed]

Hi @alwaysbrightblue thanks for posting this after the discussion in #design Slack today. I am still a little confused if you mean this to be a ticket to move to a solution for on boarding. I think that's what you want, so let me assume that - correct me if I'm wrong.

The problem that is trying to be solved is how designers and developers create solutions related to issues with user-experience. Without onboarding documentation how do we know what the WP dev community expectation is for a WP set-up? How do you know what to focus on for issues around setup of a new install? How do you establish priority on UX problems?

I think there's a wider and more focused approach here. You ask a lot of wider questions, forgive me for focusing in a bit as I think that's sensible to find a route through this ticket. Wider, I think we all agree we need to have better research and we're working on it. I think what you are suggesting is a focus on on boarding here though, I think it's a good first focus for your efforts there and aligns with what others have indicated they want to do. It also aligns with real user issues.

The tracs for [UX-feedback](https://core.trac.wordpress.org/tickets/ux-feedback) do not show a document outlining the basic onboarding experience of a new WP user. It seems there are assumptions about onboarding, but no documentation exists. Therefore, expectations of a user setting up WP are all assumptions.

The ux-feedback trac tag would probably not be the right place for such a document to exist. I'd probably say the handbook. You are right though, there is no document outlining flows for this. Although, I would say that documentation and any flows would be linked to a solution. So just having them doesn't get there.

For example, there are currently discussions about the Customizer and the Editor on Slack. From what I can tell, the discussions are looking to implement features to ease the setup process and future editing of WP. As a designer, I am having trouble understanding why these areas have been identified as pain points. Are users not using WP as expected? In the WP Design Handbook, there is no documentation around onboarding (​https://make.wordpress.org/design/handbook/), so I have no basis from which to understand what "standard" onboarding results are versus "edge-case" onboarding results. I would more easily be able to participate in contributing if I understand the baseline expectations of users by the development community.

A few things to answer here, good points. I think its important to focus a little as you are panning out into wider issues and then back to on boarding. I would to give you some context provide some links here that cover some background:

​What makes a great customisation experience: some really insightful feedback there

​The announcement of the focuses: to give some context

I also

An excellent source of documenting the onboarding is being posted here ​https://make.wordpress.org/design/2017/01/18/share-a-walkthrough-of-setting-up-a-wordpress-site/ These examples are from experienced users, which would be one segment of the user base. Even from these users, we see variation in setup. Which would be considered "normal" and therefore fulfilling the expectations of the developers?

Not all examples there hopefully will be from experienced users. I think we have to see what results we get back there and I do agree though we need to look at all levels. I'd strongly encourage you to run some test yourself - it's incredibly insightful to do so.

[alwaysbrightblue]

@karmatosed awesome feedback. Thanks for helping me with structure and some of the nuances of how to post a trac ticket. Yes, I want to move to a solution for onboarding. Part of that solution is a user flowchart that can be a reference document for designers and developers. The deliverable here is a PDF or image of a flowchart that displays "onboarding" for WP users.

Ok, I'll try to keep this succinct.

How do we define "onboarding"?
I define "onboarding" as a separate experience from editing content. My definition of "onboarding" is, "Start by ​downloading the latest release from WP.org, setting up a testing environment that concludes at the default admin screen."

"Where does onboarding begin?"
My definition above does NOT align with the ​editor and customizer discussion. That thread is about editing, which I see as following the steps I outline above. Therefore, does "onboarding" have multiple milestones?

"What are the milestones of onboarding?"
Speaking of milestones, what are they? Is the goal of onboarding similar to the setup of the TwentySeventeen theme where a full website is a result. That end point aligns with examples of ​Wix and Squarespace as examples of working onboarding. @lukecavangh ​has a Wix onboarding screenshot documented here. Similarly, @lukecavanagh has a ticket open with the admin dashboard welcome screen, which could be part of onboarding.

"Where does onboarding end?"
If the first milestone is downloading core, the second milestone is content editing to get a website looking like a website, where do we define the end of onboarding?

"Who is onboarding for?"
The user at Wix and Squarespace are (in my opinion) different types of users than those who set up Wordpress. A user who downloads core from WP.org with the expectation of seeing a website would have a different set of skills from someone signing up at Squarespace. The ​new Wp.com onboarding seems more like the Squarespace experience, but I do not think we are addressing the wp.com experience here. However, is THAT what the community wants the WP.org experience to resemble? Are the users we are focusing on categorized into different experience groups (no-code and code-comfortable)?

Great, so once the definitions around onboarding are agreed upon we have a starting point for the flowchart. From there, we can get into "Is onboarding editing content?" and usability (which should be different tickets!).

Thanks!

[karmatosed]

@alwaysbrightblue I'm not totally sure you need to go the route of different tickets. How about you do some user research and bring to this ticket and build from there?

I would say the deliverable in terms of this trac ticket should be an on boarding actual process, that's what this ticket says not a PDF. It also makes sense to focus on how do you get to a patch? How can you work on something smaller and iterate? I understand the attractiveness of working on something large, but really working out a path for fixing would be better.

I also think maybe you could explore something in the form of a plugin. I'm not sure if that's not better than a ticket with a patch. You certainly could do more user testing that way easier.

[lukecavanagh]

@karmatosed 

Ticket #39617 is related, in that was on improving what is currently already in core with the dashboard screen and the welcome dashboard widget.

[lukecavanagh]

@alwaysbrightblue

So onboarding would be defined after WP install. Some hosts improve WP install, so it is a little easier on setup.

But onboarding would be after that user has logged into wp-admin after install.

[alwaysbrightblue]

Since my last post here a new Editor prototype has come out. This new editor has brought up a lot of use case tests, which are documented in ​the post introducing the new editor on Make. The day this Editor came out was the day of our monthly Wordpress MeetUp, and I lead a discussion about this as it relates to onboarding. The most significant takeaway: Personas.

Personas are ​defined as “represents a cluster of users who exhibit similar behavioral patterns in their purchasing decisions, use of technology or products, customer service preferences, lifestyle choices, and the like. Behaviors, attitudes, and motivations are common to a "type" regardless of age, gender, education, and other typical demographics. In fact, personas vastly span demographics.” We already somewhat acknowledge personas in the User’s Panel with Subscribers, Authors, Contributors, Editors, and Admins. Each has their set of permissions which change the options for control within the dashboard. But, currently, because onboarding is defined as starting after a successful install, the first step of onboarding is either a default theme on the front end or the current Admin user dashboard. Therefore, all users are treated as an Admin.

Different personas want different experiences. An Admin level persona could be an experienced developer who wants to continue to use the existing dashboard interface. Luke Cavanaugh’s ticket is focused on this current dashboard design and is beginning a good change for a better UX for setting calls-to-action. Specifically, at our meet up, the existing dashboard was described (and agreed upon unanimously) that it is not a good place for personas who are not already at an Admin level. If we only consider the existing Wordpress users, we are already too overwhelming for ⅘ of potential users.

“Choice” became the focus. For Themes and Plugins, there are thousands (millions?) of choices. It’s overwhelming. We discussed onboarding processes of GoDaddy, Genesis Framework, and the WooCommerce Wizard and how these seem to help, but are still too overwhelming for certain users. Prebuilt themes are easy to setup but come with so many options that it can inhibit setup (not to mention inhibit performance on the site). Even the difference between “Page” and “Post” can be inhibiting the progress of a new user.

But we did have the new Editor (​Gutenberg and ​iseulde Editor Blocks), and it got us thinking, “what if this is the first thing we see?” It is more intuitive because we are seeing the CSS in action on the page and starting to “build” a website because “Seeing is believing.” “Page” and “Post” are irrelevant here, and it’s a welcome change. We are no longer distracted by choices. This week, some other user testing sessions occurred: ​@annaharrison, ​the entire thread releasing Gutenberg prototype. These are showing similar experiences.

We thought about custom ways to different onboard personas, and it was then raised, “Should personas be linear?” We should think about focusing on the task to be accomplished by the user. Some overlap is ok. Think about setting up custom roles with the ​Members plugin and how those permissions are specifically meant to allow a user to accomplish their task. For the sake of simplicity, let’s use existing persona categories as a basis to set up an onboarding walk through. The task could be to create questions that establish user tasks and needs to set the permissions a user may see initially. There will always be an “under the hood” area to add permissions, get to settings, probably within Customizer, but we’re not there yet.

To continue progress and not get lost in the weeds, I will work on some onboarding flows for the existing personas of Wordpress: Subscribers, Authors, Contributors, Editors, and Admins. I would welcome others to also help in this process.

Resources
​Usability.gov
​UXMag.com: Personas: The Foundation of a Great User Experience

Editor Blocks
​https://iseulde.github.io/editor-blocks/
​https://github.com/WordPress/gutenberg

Onboarding
​https://www.useronboard.com/onboarding-teardowns/

UX Archive
​http://uxarchive.com/tasks/onboarding

[alwaysbrightblue]

This is my experience setting up Wordpress with 4.7.2. I did this on a local installation, so once I entered my database info, I was presented with the front page of TwentySeventeen. It took me a few scrolls and clicks to get in.

If you have a different experience getting to the dashboard, please post!

[alwaysbrightblue]

I thought this quote resonated for Personas in the Subscriber, Author, and (maybe) Contributor level.

"When we talk with users who switch from Weebly to WordPress or from Wix to WordPress, their most common response is: 'I wish WordPress had a drag and drop website builder.'"
Source: ​WPBeginner.com

Currently, I'm thinking the onboarding would put these user groups directly into the new Editor window, albeit with a few UI adjustments that I will mock up.

[karmatosed]

Noting we chatted in Slack about this. A few things:

• It would be great to take this out of the trac ticket and follow the path discussed of blog posts. I feel focus on your group first is important.
• The roles you identify aren't personas. They are simply a collection of permissions. I'd be wary of basing any flow on that.
• It's very important to focus on customizer and editor focuses and not spin out beyond their scope yet. I do not believe this comes into it yet.

The above said, repeating my recommendation here:

- Do some user research outside group: this practices your user research skills and I’m happy to help you there.
- From that create suggested personas. These won’t be the WP absolute personas, no data from a small set could be, but it can kick start.
- Focus from those to work out flows.
- Begin thinking about designing ‘just’ for the initial onboarding. Ignore the wider project for now.
- Test a few flows locally.
- Iterate.

Each stage could have a reported post, personally I’d find them super interesting and really keen to see. What I feel though is this provides both an awesome exercise for your team and could then lead to a more focused trac ticket. A more focused roll out to other meetups.

If you agree, I'd also suggest closing this ticket for now and refocusing on those blog posts @alwaysbrightblue. Closing doesn't mean not making it happen, I just think there needs to be focus here.

[lukecavanagh]

Knowing the personas of WP end-users is a worthwhile topic in itself.

​https://www.usability.gov/how-to-and-tools/methods/personas.html