Read the fucking manual
Currently I’m working in a team which main focus is building applications for their own staff. B2E stuff. With these applications their staff is equipped with the right tools for their line of work.
The team that I’m working with mainly consists of developers and testers. A pretty technical oriented team. Six months ago they hired their first interaction designer to come aboard on this team.
That’s me.
A long term relationship
The staff is forced to work with the applications that their IT department builds for them. Why? Simply because there are no alternatives. Everything is custom build for their line of work.
The staff spends hours on these applications on a daily base. What you can achieve with these tools is pretty impressive. The interesting thing is, the first time I was taking a glimpse at the applications I didn’t know what I was seeing.
Literally. I didn’t know what it was. At all.
Screens were filled with features. I didn’t know what the main purpose of a screen was. First I thought everything was filled with jargon that I simply didn’t understand. But unfortunately while I was experiencing a first ‘user test’ I wasn’t the only one that didn’t understand the interface.
Their users didn’t either.
Did you do your homework?
The world of this industry was pretty new to me. So I went on the road to observe some of their IT people paying visits at their staff to get feedback for their tooling. Cool. User testing.
Well not really.
What happened is that IT people were starting to explain all the new features to their staff. After sending them a manual on how to work with these new features, they would pay them a visit for a personal interface training.
If users didn’t know what to do they were asked the question: “But did you read the manual that we attached in our mail?”. Their users were getting tested if they read the manual well enough.
If they did their homework.
Tailor-made applications
For an interaction designer at Mirabeau it’s pretty obvious that an application has to be intuitive. Of course, an application can be filled with jargon and features that are unique for a specific line of work. But even in all this jargon there is a content hierachy and a way of displaying features in the right order.
The second time I was on the road I asked the IT people not to give a training but instead, to give the user a specific task to accomplish. I asked the IT people not to assist them if they were struggling with this task but just let them fool around and think out loud while doing this.
And that’s exactly what happened. Their users were struggling. Big time.
After this test we could easily pin point all the pitfalls in the experience with this application and start working on improving the interface. And by doing so, improving the daily working routine of their staff, by listening to their needs and observing their way of working.
Building tailor-made applications.
Designing for (em)power(ed) users
The next step is to create an intuitive work flow throughout these applications. The goal is to get each user out of the ‘newbie zone’. Getting them to feel trusted with these applications without them needing to get help from a more skilled person or to consult a big manual for help.
We’ve only seen a very small group having the interest and the trust to click on features that they’ve never touched before and just start playing and discovering new stuff. We see the majority of their users only use half of the available features, since they feel trusted with them, and find workarounds to still accomplish their tasks.
The trick is to explain features in the right context to your user.
Tooltips
To explain difficult content and actions I used tooltips to explain what will happen if you’re about to click on a button.
Hints
By providing hint texts and small walkthroughs users can get introduced to new features and discover easier ways of working with an application, instead of having to read through yet another chapter of a manual. Users are guided in context.
Short keys
If users are using features a lot you might consider introducing short keys. For example, by pressing key ‘a’ in a specific screen the main function of the screen pops up. Keep in mind that this key shouldn’t have a function already.
A good way to introduce short keys is to add a line of text in the feature that the user opened with a mouse click by default.
Dynamic design
To make things even better we’re currently thinking of creating a dynamic interface which fits perfectly within a work week of the staff. Tasks that are done on Monday should be more prominent on Monday than on a different day of the week.
We can achieve this by doing research to the daily routine of their staff and making our application fit perfectly within this week, or even improving the way of how their weeks are arranged.
Next steps
Together with the team we’re working hard to let users enjoy the full potential of these applications. We’re currently in the phase of getting every user out of the newbie zone and starting to work on converting them into (em)power(ed) users.
