On user support and product feedback

#1

Having users’ feedback is crucial. However, we haven’t implemented any kind of knowledge base or interactive feedback mechanism inside the Aragon client.

The reason has always been privacy. Those systems are usually centralized, US-based, and track users. Yet we feel the need to have such a system in place, so users can opt into having help, access to a knowledge base and possibly open issues and request feedback from the comfort of a chat-alike interface.

I’m thinking about integrating a help button across the product. When you click it, it will request your consent to load the help system, and therefore a third-party script that may track you. If consent is given, we could then load something like Intercom or Help Scout.

Those systems give us the following features:

  • Friendly and easy to maintain knowledge base
  • Contextual help, like displaying a knowledge base post about how to transfer tokens while the user is in the token manager
  • Support tickets via chat or email, in case the knowledge base is not enough for the user’s needs
  • Shared inboxes so people across multiple Aragon teams can access it and help support users
  • User satisfaction surveys to both documentation and user support chats

There are some differences between the systems, and after analyzing and trying both out, I’m posting my thoughts here.

Intercom

Pros

  • Default knowledge base template is pretty
  • GitHub integration: Issues can be opened with a click from a chat conversation, and then the user is automatically notified when the GitHub issue is closed
  • Engage package: Which we can use further down the road to interactively tell people about new product features and stuff they could do with the product (e.g. you haven’t added members yet, mint a new token now!)

Cons

  • Intercom branding is very visible
  • No themeable knowledge base using CSS

Help Scout

Pros

  • Fully themeable knowledge base using CSS
  • Can remove Help Scout branding

Cons

  • Doesn’t work with GitHub by default (have to use Zapier)

Pricing and everything else is very similar, with Help Scout being less pricey.
I think the Intercom brand is very strong, but maybe some users in the crypto community won’t like it. Therefore I think Help Scout could make sense since we can remove that branding and completely customize our knowledge base.

I think this is very high priority. We could learn a lot about our users and their confusion this way, and also guide and help them along the way.

5 Likes
Aragon One product scope for 0.7.x
#2

This could probably be a very important feature to improve general UX, and end-user’s learning curve.
However, I think this should remain something configurable by the integrator of any given DAO.
If I launch a DAO, and that I also want to have a specific FAQ-based wiki (describing all the governance mechanisms of that specific DAO and how they integrate in the Aragon UI/UX) that is, for instance, hosted on the IPFS. Then I’ll maybe don’t want my users to rely on a centralized service to find help, or to land on pages related to basis Aragon UI functionalities and not related to the DAO itself ?

A “dual” help system (one for the Aragon UX/UI and the other for the DAO itself) may confuse more.

Just posting some thoughts about this, as I also think this is a very important feature, from the point of view of an integrator (and not a developer) of the Aragon Client.

3 Likes
#3

I think that could make sense down the road; maybe implementing an option for the DAO to signal that it doesn’t want the help button to be shown at all. We’d need to try this and see how it works, and if a lot of people want their DAOs to have their own knowledge base, we can find a way :slight_smile:

1 Like
#4

I think this feature is a great idea and it is especially important for people who are new to crypto – for smoothing the on-boarding process with help docs and chat in more easily accessible locations.

Is there a reason that ZenDesk was omitted in the comparison/search? It seems their knowledge base theme can be customized and it’s the product that has the most adoption from what I have experienced.

As far as costs go, how many help seats are you imagining? I’m wondering if the shared inboxes will be limited toward the number of seats one is paying for.

#5

I think the idea of it being configurable per DAO is interesting. But since all DAO transactions and UIs are already open by nature, it doesn’t necessarily have to be a DAO team that provides the support.

I would think that the primary use case of needing help would be something related to the UI or some failed transaction, as opposed to a very organization-specific query.

It is likely that DAOs will also have some chat rooms they manage, and organization-specific questions may more likely be directed in their chat channel vs. the Aragon help system.

1 Like
#6

Hey,

Regarding the DAO-specific wiki this is something people will soon be able to build with pando.

I don’t wanna spoil too much and i’ll give more details on this very forum in a couple of days but pando will be on Rinkeby very soon for everyone to experiment with and the experimentation use case will be … an Aragon DAO on-boarding guide :slight_smile:

I think this can be complementary to the Intercom like solution which I believe is a really good idea to help onBoard people.

5 Likes
#7

I’d imagine around 5 seats or so, one for a UX person from each Aragon team, and then possibly a couple devs.

Also on Zendesk, AFAIK they are much more focused on corporate and their chat tools are inferior in terms of offering contextual knowledge base articles based on the message the user sends, which I think it’s a key feature of a system like this.

1 Like
#8

You are certainly right. But in my previous experiences integrating ERP systems (Odoo, etc) in companies, or also SCADA for industrial applications, a dual help system (one channel for the core components / basis UI, and another channel for specific use-case related help) always brought a lot of confusion to non-technical end-users.

That is great news! As we’re currently studying solutions for sharing and management of governance-related documents in a DAO, I’ll certainly take some time very soon to have a look at your work.

I have to admit that the main motivation for me to reply to this topic was because of the idea to see a centralized service natively integrated in the Aragon UI…
And so with my colleague we took some time to think about it.

So, what about something like this:

Help Center dapp


The Help Center tab would open a screen with the following initial actions :

The Help Center would be an Aragon app featuring :

General

  • Queue management system based on a smart contract.
  • Integrated IM client based on some decentralized protocol, like Matrix (or Whisper 2.0?), that guarantees privacy and anonymity.
  • Maybe also a ticketing system (also smart contract based) for issues needing more work or a more long term tracking.

On the helpers side

  • Number of open helping seats at any given time would be automatically adjusted, based on a configurable SLA policy (average waiting time) by the DAO integrator.
  • Helpers could/would have the following incentives :
    • An minimum (timely based?) incentive for occupying a helping seat
    • An incentive for every chat session started
    • A bounty for every chat session that ended with the user signalling that his problem has been solved

On the help seeker side

  • An on-boarding screen offering to search across existing knowledge base (maybe built on pando as @osarrouy suggested), or to initiate a support request (entering the queue with a SC transaction, thus protecting against spam).
  • Eventual additional fee could be configurable.
  • Ability to rate their experience (could have an influence on the amount of the bounty)

There certainly is still room for plenty of other design ideas.

And maybe the actions could also be accessible from the home menu :

What do you guys think ?
Would love to see that kind of help / support functions instead of a centralized commercial provider. :slight_smile:

2 Likes
#9

This is great, and I think that if there was a system like this in place, we wouldn’t need a centralized alternative. Unfortunately I’m sure a system like that would take many months to be built, but definitely should exist.

#10

As Aragon grows, it won’t really be sustainable to have UX people or devs doing support – in traditional orgs there are always specialized support people and it’s a full-time job. How are you thinking that will be managed within this initiative?

I think it’s good to have the ownership outlined in these earlier stages – will it be something like the security partner where we eventually look for a proposal from a team solely focused on support and creating reports of common pitfalls (to help drive product)?

I think that there ultimately will need to be some type of supervisor once full-time support staff are needed, and the task being spread out across teams won’t necessarily scale.

As far as the product goes, I think the Help Scout option sounds good – I like that you can customize the branding. Also, I asked a friend whose friend does crypto support what they used, and they use Help Scout and like it a lot.

1 Like
#11

I think that could make sense down the road, having a team handling that.
Good to know, and also Help Scout is a public benefit corp, which makes me more at ease with using a centralized service. I think it’s the way to go.

2 Likes
#12

Okay. We’ll try to gather resources and deliver at least a PoC before summer.
That kind of interaction is a needed feature for one of our key projects anyhow.

@everyone If someone is willing to help, feel free to DM me here or on Keybase.

I’ll hopefully come back to this thread soon :tm: to show some progress.

#13

Amazing!! Looking forward

#14

Something to consider with the implementation of this is liability for the people responding to support inquiries. There should be an explicit release of liability for the support agent in case the user follows some directions and bricks their organization or something.

5 Likes
#15

Absolutely agree

1 Like
#16

I am going to be working on copying / migrating some of our user guide documentation to Help Scout this week to prepare for the initial implementation. One topic I have been thinking about that has been in my mind since first beginning work on user documentation is how we want to organize the documentation for Aragon apps and who will be responsible for this documentation.

So far I have documented everything that is accessible from app.aragon.org right now (all developed and released primarily by Aragon One). But with new apps coming from other teams (e.g. TPS, Pando, Futarchy, Livepeer Delegator, etc), and potentially new related templates, there will soon be much more to document from an app and templates standpoint.

With this context, the question I have is: what exactly is the scope of documentation available in Help Scout?

4 Likes
#17

Great idea! Probably would also make sense to have guidelines for the support person on which things s/he should handle and which ones should be left out for another instance (i.e. forum if opinionated or a professional if technical).

#18

As I see, there are two interconnected but different problems to solve:

  • How to inform and help users.
  • How to learn from users.

For the first one, all the proposals seem great. There are some services that include a bot that works as a first filter to redirect people to the docs/wiki first. Even intercom has something like this. This would be great for scaling support.
On the second issue, I know this service called Canny, which helps to track user feedback.
I have a mixed feeling about it because it’s centralized and it also involves some discussion tools. It can add complexity to the whole communication system being yet another comm tool, but on the other hand, it’s specific and has a low barrier to interact with it.

1 Like
#19

I’m curious about docs too. I reached out to the hack.aragon team about TPS docs, but they said they we’re quite sure what to do. I was just going to start rolling them on my own in the context of a demo DAO that’s using them, but it would be great to have a more organized community led effort so that we don’t duplicate work.

2 Likes
EthDAO: Making Ethereum great again
#20

I think that for now we should document the apps in aragon-apps, and all the other officially supported apps. That’s a very open-ended term, and I think it makes sense that ANT holders or core developers decide on which ones are the critical apps that are important to audit, document, etc. Until then, we could just rely on our own judgment, and be open to feedback if anyone feels like an app needs to be documented.

1 Like