2

Backstory

I'm creating a tutorial/help/guidance system for a web UI. The backend of the system is a complex professional analysis & measurement tool originally launched in the mid 90's that has remained in active development since. The original version of the system was a standalone desktop application, but that's being currently completely revamped to a HTML5 / JavaScript / GWT front-end web app that polls and displays data from the backend (that is scheduled be rewritten later on, but that's another story).

The web UI uses common UI components - sliders, dropdowns, etc. - in common ways, so there should not be anything unintuitive about how the interface itself functions. However, the actual content is very profession-specific and there are no established conventions how and where different settings and parameters should be located, and how they are displayed. Some the terms are professional jargon that needs to be referenced somewhere, and some of the features you can do with the application are quite unique.

Here's what the main UI view roughly looks like. The floating layers contain settings that affect what's displayed in the main view.

UI draft

Question

I'm looking for user guidance design principles from a... let's say professional niche application's point of view. Usually, web UI usability discussions focus on widely available web apps that have a different set of questions to answer in this area. There is emphasis on onboarding, how to make the initial user experience welcoming, how to improve user retention. Which all makes sense, if you're competing with tens of other viable candidates for the online user's fleeting attention. If found this discussion helpful in that sense

But how does user guidance and tutorial design differ for a specialist professional tool whose user base can be considered committed and involved from the get-go? They still need guidance to be able to use the more advanced features of the application.

The "online help" as we knew it is half-dead, but what are its replacements? Do they differ from what's generally considered successful in the public web app world? Nowadays Google has replaced the Search box in the application help, but what about when the product is for such a niche market that it will likely not have any visible online community for this purpose?

Specific questions:

  • How to make a good interactive tutorial for people who are professionals in the subject matter, but newcomers to the particular application?
  • (stolen from another thread): What's a good way to provide access to the help system? Cluttering the UI with questionmark-icons is certainly not optimal.
  • Semi-related: can there be TOO MUCH tooltips?
  • Supposing that an in-depth online reference is essential, how should it be presented in the UI?

closed as too broad by Devin, Mayo, Graham Herrli, Evil Closet Monkey, JonW Mar 30 '16 at 10:17

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • How it differs depends entirely on the niche you happen to be working on. Broadly speaking, though, I'd argue good UX should first and foremost be trying to get rid of help systems via a more intuitive UI with more on-screen explanations. I'd argue one tooltip is too many. If it's important information, put it on the screen--not behind a tooltip. – DA01 Jun 1 '15 at 0:52
1

Get in touch with the professionals, speak to them, create personas, verify what you suppose, verify whether there's too much questionmarks for them, verify the results, have fun, keep doing it. That's the job. :)

1

Its time to get of the chair and observe how your users are using it. We cannot give you valid advice because we don't even know what the domain is.

If you can you should go and observe how people are using this application, what questions do they ask, what problems they encounter, and what are the strenghts of your software. If you go and observe 10 people, and take notes from each in the end you will start seeing common problems. You should wrote those problems in a list and then give them priority. From there you will have very good knowledge what information is important so you can emphasize on it and what not.

If you cannot do observations, try interviews or surveys. They will give you much more data than general advices from stackexchange which might not work for your domain.

This is usability: getting information from your users.

Not the answer you're looking for? Browse other questions tagged or ask your own question.