A case for User Onboarding

User Onboarding is the process of increasing the likelihood that new users become successful when adopting your product.
see https://www.useronboard.com/

I'm bringing it up in this context so that the Plone community keeps this in their consciousness. I'm not 100% sure on how this should look, but I'm sure it affects the following areas:

  • Tooling (e.g. Diazo Snippets Library)
  • Documentation (lots of good work happening there)
  • UI/UX
  • Communication

In summary I think User Onboarding is everyone's job and there should be some conventions/guidelines that ensure that the Plone experience is always newbie friendly to support this.

This is all very new to me (I've started seeing it this way about a year ago).

Hi David - this is a laudable effort! As you mentioned in a different post, not all of this effort fits within one existing team. My concern with trying to set up a new team is that there are only so many of us, but by all means it's worth pursuing (either participating in all the applicable existing teams or trying to set up a new one).

I've been thinking that it need not be a new team. Rather an area of responsibility the members of a given team may be asked to give attention to. So effectively on the UX team there may be someone who is asked to pay attention to user onboarding related issues and the same for the Framework team etc..

Another approach might be to make space for user onboarding the way that we do for testing. So filter what we do through the lens of whether a given change makes it easier or harder to adopt Plone.

Again these are still unpolished thoughts, but I think they're worth putting out there.

I know how "full up" current team members are already. Rather than asking them to take on something new, since you care passionately about this topic I think you would have greater, consistent success if you joined one or more of these teams and did the work on each team of ensuring that onboarding is part of the discussion and of the action items. (I'm reminded of the PLIPs, in which unless you, the submitter, can convince someone to add a new feature it's pretty much assumed that you will be doing the work yourself).

I'm okay with that. It also sounds like I need to spend time fleshing out the process with typical day to day actions so that if I need to hand it over to another "roaming" onboarder they can pick up from me.

You are right, I am passionate about it. After having to teach both Plone and Wordpress to newbies I realize how challenging the onboarding experience can be for both tools. I'd like to do my bit to fixing some of these Plone onboarding discrepancies. So it sounds like I'll be joining multiple teams....

1 Like

I'm working on ways to get better communication happening between UX experts, core developers and end user advocates. Primarily via github so can involve people who can't turn up to sprints and meetings.
So far that process involves writing issues that specify end user problems seperate from suggestion solutions.
for example https://github.com/plone/Products.CMFPlone/issues/463
In particular this is meant to be for "hard" long term things that don't have a known solution. However I've found this format useful even for short term bugs. It help prevents developers from losing sight of why there are implementing something and how sometimes the decisions they make can sometimes nullify the very reason they were implementing it in the first place.

Process also involves using tags to like UX editor or UX themer to indicate which user is effected.
Perhaps another tag would be useful to indicate "newbie effecting"? or "onboarding related". That way we can prioritise those issues.

The next stage is I want to involve end user voting on which issues affect them and some way ensure UX team member input on these tickets.