How Urbit can leverage open user feedback systems for massive UX gains
The fastest way to get ripped, jacked, and responsive to feedback
Yesterday I was trying to get my Urbit planet fixed. I fired up a comet via Port to ask in the Help channel of the Urbit Community group. As it was a new comet, I wasn’t already in the group, and I’d need the name of the host planet to join.
I googled “urbit community group”, and to my pleasant surprise, the first result was exactly what I needed: a page for the group on the official Urbit website. It even had a nice “copy link” button.
I copied the link, pasted it into Leap, joined the group and got the information I needed to fix my ship (thanks ~tinnus-napbus!).
Going back to the group page on the Urbit website, I tried to find a link to a list or directory of other groups on the network. I couldn’t find one, though I was offered instructions on how to join a group, or submit my own to be shared on the website. But no option to search for or browse other groups.
Maybe there was a good reason for this omission, or maybe it was a planned feature already on the roadmap. Maybe, though, it just wasn’t something that anyone had thought of. There no was way for me to tell.
Because a website is opaque, we can’t see into the minds of its designers; we can’t read their intentions or convey to them our wishes. In the future, this may change. But for now, I had to Lodge User Feedback… by Any Means Necessary.
There’s not really a great way to provide feedback on Urbit, whether it’s regarding the website, a particular app, the UI of Landscape, the error messages of Port, the inconsistent quality of its founder’s newsletter, the Dark Elf Digest, or any other related matter.
You really need to know a few people on the network, and then maybe you can ask them, or just tweet for a while and hope the right person sees it. Or you can post on Urbit itself, but there’s not one big clearly-marked User Feedback group, and if there was, it would be a total chaotic shitfight.
Doing user feedback right means having systems fit for purpose. But first, we need to understand why we need user feedback in the first place.
Introducing the microproblem
As I wrote in a previous article, microproblems are problems that users encounter within software products that have been built and designed to solve other, generally larger problems (which I’m calling macroproblems — it’s a nomenclature boring but consistent).
For example, Uber Eats solves the macroproblem of, “I want to go and get a kebab but it’s raining heavily”. Deliveroo solves the same problem in a slightly different way, for a lower cost, but introduces a microproblem in the form of erratic delivery driver tracking.
A microproblem could be a bug, but it could also be a friction point, a typo, or a feature request (as in my request for a groups directory link on the Urbit Community webpage). It’s micro because it’s annoying, and you suspect it could be fixed relatively easily; but it won’t keep you awake at night, and it generally won’t stop you using the product. So, despite the driver tracking issue, you might still use Deliveroo because it’s the cheaper option.
But microproblems add up. Think of them like bugs: one or two mosquitoes can be swatted or shooed away, but a whole swarm of them can make you pack up your campsite and head elsewhere.
Microproblems vs pain points
How are microproblems different from user pain points? There’s some overlap, but I wanted to coin something new to steer clear of associations with existing UX conventions.
Pain points are the things UX researchers are always trying to discover, probe at, collect, gather data on. It’s like when you go to your doctor for a check-up and he’s peering at you, poking and prodding you, saying, “How about here, does that hurt?” He’s looking for the pain points, and you and he both hope he finds them, so he can write you a script and you can put your shorts back on and go home.
But even if he finds the pain points, he won’t find the microproblem, because the microproblem is that your doctor has really bad halitosis; in fact, this is only half of it. The other half is that it’s hard to tell him this and not risk having to find another doctor. That is: there’s no good system for lodging feedback about the doctor’s bad breath.
So, microproblems are generally not discovered in UX research, and users don’t often raise them via existing feedback channels. This calls for a new approach.
Frictionless open feedback systems
The best approach to solving microproblems involves leveraging the annoyance of users who encounter them and using this leverage to identify, describe, and organise them in an open commons based on how many people they affect and to what extent.
I call a system that can get such a result from this annoyance leverage a frictionless open feedback system (FOFS). I’m sure there’s a better name out there somewhere, but this one will do for now.
A couple of months ago, I compiled a list of all the different platforms, products, modules, widgets, and giblets that provide the basic functionality of a FOFS. Here are some: Canny, FeedBear, UserVoice, Frill, Gleap, Nolt, Upvoty, Sleekplan, Changelogfy, Userback, and Aha! Ideas. And no, I’m not going to hyperlink them all.
They’re all variations on a theme: they bolt on to your website or browser app and let users submit an item of feedback, then give you and your users a way to sort these items in a public or semi-public place.
The frictionless part applies to the lodgement step, the open part applies to the sorting step.
I did have a lot more that I wanted to write about this, but I have run out of time and I don’t want to pay out $15 just to include a few extra paragraphs. So you’ll just have to wait until next time.
Why does Urbit need a FOFS?
Urbit needs to leverage user feedback for two main reasons.
- UX research is one of its biggest weak points.
- Its userbase is one of its biggest strong points.
By using user feedback to hedge against limited UX research capabilities, developers can get more information on how to build the apps and features that users want.
By empowering users through an effective feedback system, Urbit sends a clear message: you don’t have to be a dev to contribute here. If you’re a user, you’re only a feedback ticket away from being a participant and a co-designer.
Is a well-integrated frictionless open feedback system in itself the “killer app” that Urbit has been looking for? Probably not, but, properly implemented, it will contribute to improving existing apps, will help drive the design of apps to come, and will make the general experience for non-technical users more satisfying. I think that’s an avenue worth pursuing.
