What we do with feedback

I'd like to share the redesigned topic posting screen for version 8:

Before:


After:


(Small note- actually we're introducing some hidden options to simplify the system and to get it exactly like this some of those have to be turned on – these options will become mainstream in the future when we next make a 'disruptive' release)

You'll see there are many differences here:

• WYSIWYG editor has only one set of buttons
• …and there are fewer buttons too
• 'You can use Comcode' is removed
• The 'Emoticons popup' says specifically what it does
• The 'Existing attachments popup' says specifically what it does
• …and has moved
• The attachment description has moved under help icons
• 'Convert to Comcode-XML' is gone
• 'Skip signature' is now gone, and the poll checkbox is expressed more clearly and directly

I am not writing this blog post to show off the improvement, because if anything this highlights the current version is imperfect, rather than showing off some amazing work we've done. What I care about is showing what we can do when we are given specific feedback.

These changes would never have happened if it weren't for a combination of internal testing (at a recent meet-up between myself and Robbie), and more importantly, user feedback.

We've developed ocPortal over many years now (since 2004 as a product, but actually it goes back quite a few years before then), and with time it gets a lot harder to see things with a fresh eye. Usually the way things are was done for a reason, but even if it isn't, we're used to it and glance past it. It's hard for users to understand this, but I can't exaggerate the effect. That said, when we are prodded to look at a specific thing in detail, we start to notice other areas for improvement ourselves too.

Going through the changes I've mentioned, let me prove that by saying why we never really were aware of these little usability issues until pointed to them:

• WYSIWYG editor has only one set of buttons: Originally there was no WYSIWYG editor, and when we originally implemented it it was not on by default, so the original buttons persisted
• …and there are fewer buttons too: It was pointed out to us that non-admins don't need the more sophisticated authoring features
• 'You can use Comcode' is removed: The button to add a Comcode tag was added only recently, and it never occurred to us that this means that this makes it obvious Comcode is supported and that therefore a link to the tutorial isn't necessary anymore
• The 'Emoticons popup' says specifically what it does: Hands up on this one, a case of systems-thinking incorrectly trumping use-case-thinking
• The 'Existing attachments popup' says specifically what it does: Ditto
• …and has moved: We used to have a few more links here, so it wasn't so out of place before
• The attachment description has moved under help icons: Improvements to the uploader since meant we did not need to be explicit listing allowed file types (because the selection window can limit what can be chosen)
• 'Convert to Comcode-XML' is gone: Back in the day XML was a huge buzz point, so having XML functionality in the core system was a no-brainer
• 'Skip signature' is now gone, and the poll checkbox is expressed more clearly and directly: When we originally designed the ocPortal forum, forums were extremely popular. This was before Facebook. Everyone knew how to use them, and having lots of features was considered a plus point. User behaviour has since changed considerably, and the expectation for things to be usable without learning has really increased in recent years

As you can see, a lot of these little usability issues has been because we've made other improvements over the years which has shifted the principles related areas were originally designed on. Of course, the improvements we've made over the years themselves are often usability improvements, so there is both a raised bar but also a need for the current design to be optimal for that new bar.

The kinds of feedback we get varies a lot. There are some people who worship the ground we walk on and won't say anything bad and there are just as many people that slag us off with hyperbole, and then most people fit in-between. But even people in-between, for whatever reason, don't tend to give particularly specific feedback unless they have a very direct need for something. All these feedback situations are quite unhelpful because they don't give us anything to work with. Let's give some examples:

Rude hyperbole:

• "The Admin Zone looks like it was designed in the 90s". This is a good attempt to annoy us that very occasionally someone makes. It's clearly untrue (whilst we freely admit the Admin Zone could use a few weeks work by a fresh UI designer, it's at most a few years dated, and anyone who was online in the 90s knows what a real 90s website looks like). Fortunately we've developed thick skin over the years, but this feedback is of little help because really it doesn't say anything specific enough to change (e.g. reference to particular usability problems, particular outdated design styles, etc).

Unhelpful praise:

• "Wow, you guys are going to be millionaires very soon". I really doubt that's true, but regardless I know for a fact everyone finds the odd thing that can be improved, so it's more important to us to know what than to get praise.

Vagueness:

• "This is very nice software although I find the forum a bit confusing". The forum has hundreds of things that might be easy to understand or confusing, so really we need specifics.

Ideally we'd just employ UI designers and constantly run usability test sessions. However with the average customer wanting to spend £1000 on a fairly advanced website nowadays and assuming we have a typical 5% marketing budget, that means for every website project we can afford to spend only about an hour investing directly back into the project. So we rely on our users more than ever to give us the feedback as well as finding synergies.

A lot of the feedback that led to the changes in the screenshot above came from one of our customers, and I agreed to make the changes for free because it was so good and clear (there's a lot more, this is just the result of a small percentage). It would be great if more people did this, if lists of specific little interface changes to make were commonplace.

That said, hopefully this blog post won't result in a wave of people making feature requests for the building of their own site and an expectation of them being quickly done for free – always a risk when I talk about doing stuff for free . In this blog post I am specifically talking about usability issues that affect all the users of common ocPortal interfaces, I don't want to imply that things that would be useful to less than 50% of users would get prioritised and implemented for free.