2

We're building a call center app where there will be multiple portlets on a page, each with its own function. For example, when the call center agent logs in they might see a Work Queue portlet, a Recent Customers portlet and others.

Each portlet represents a different function, and when a customer implements this product for their call center they can choose which portlets their agents will see.

My questions are:

  1. Is it better to have a single help button in the header of the page, or a separate help button for each widget?

  2. If we have a single help button in the page header, is it better to go to a help topic for the page or pop a menu where the user can choose a topic?

Any insights from similar situations would be much appreciated.

  • Provide a global help menu with options tailored to the current view. – plainclothes Aug 26 '16 at 14:42
1

There is no globally-applicable answer to the "single monolithic help file" vs "context-based help" question: as with so, so many UX issues, it depends on the type and complexity of the app itself, on the quantity of help text to be supplied to the user, and on the type of user and their level of expected familiarity with the application. Either strategy might be appropriate, depending on the specifics of your application; each has advantages and disadvantages you'll need to consider when making this decision.

Ultimately the goal is to get the user the help they need, with a minimum amount of digging through stuff they don't (at the moment) need.

Monolithic help

(This applies to anything from a single help page, to a separate structured help site with its own subnavigation.)

Advantages: easy to find, always in the same place. Least amount of interface clutter (just one button). User has the ability to read through the entire help file(s) if they choose to, to familiarize themselves with the overall structure of the application, or to search through the help text to find every mention of a given topic. Lends itself well to help text that is conceptual ("here's what this feature does, and why") rather than UI-specific ("here's what you need to click to perform this task"). Allows for cross-reference, searchability, topic indexes, and so forth.

Disadvantages: Uncontextualized. The user has to leave the context of their task, find the particular section of a (potentially large set of) help text that contains the information they need, then find their way back to the task. Monolithic: in large applications, many users only care about a subset of the functionality, or you may have different types of users each with their own needs. A monolithic help file works against this; you can't easily tune the help text to different user types, for example, or omit information for one group of users that may only be relevant for a different group of users; this tends to be less of an issue with context-based help because there the user's context naturally leads them towards the relevant information and away from the irrelevant.

(But note: In your specific case, since your product is configurable to omit certain features, the help file or files should follow this configuration: if a given instance of the product doesn't have a Work Queue portlet, then any section of the help text that references the Work Queue should be omitted from that instance.)

Suitability: In general, monolithic help is more suitable for more complex applications, and those with a relatively low-churn userbase: individual users new to the app can read through whichever portions of the help files they need to familiarize themselves with the overall structure; once they have a handle on things they can ignore the help link, or only refer to it for obscure or unusual tasks, and won't have a bunch of separate context-help icons getting in their way.

Context-based help

Advantages: context-based (obviously). The user has a question about a thing, there's a help button on that thing, which tells them how to use that thing.

Disadvantages: Demands brevity. Contextual help needs to be very specific to the related task, there's not a lot of room for cross-reference or discussion of the higher-level structure of the application. Potential for interface clutter (lots of separate help buttons). No cross-reference or easy searching of text is possible. Help which may relate to more than one feature needs to be applied to every one of those features, which can feel repetitive. Help which relates to interactions between multiple features tends not to fit well in this model.

Suitability: In general, contextual help is more suitable for simpler applications, where the help to be provided is more of the quick-hint variety -- if your help text is mostly of the "how to use this particular screen widget", putting that help in the context of that widget is very useful. Applications with lots of user turnover tend to be suited to context-based help (because there is a greater likelihood that a given user will be new to the app and not know what's going on.)

What not to do

Don't try to split the difference, or disguise one type of help as the other, or do both at once. If your help text is long and complex, don't stuff it into contextual popup windows. If your help text is highly widget-specific, don't make the user dig through a set of navigation in a separate help site to find the relevant widget they were looking at in the first place. Don't include tautological or space-filler help: if a given widget is self-explanatory, don't add a context-help link to it just because six of its neighbors have one too. (Remember the best kind of help is not needing help in the first place: as much as possible your interface should be intuitive without the user needing to "read the manual".)

0

I used as an Assistant for a startup that basically functioned as a Call Center but the agents didn't call, but texted the people who needed help.

Here, there were a lot of questions that were repeated and agents required help frequently.

For the start, there was a single help button which was based on FAQs which had a list of topics one could select/search from.

After a while, the page was getting populated with a lot of queries and difficult to manage. Hence, every query was identified using Machine Learning and the FAQ corresponding to it was presented to the agent without the needing to search.

Time is an important factor for Call Center Agents. Also, they happen to get frustrated quite sooner due to targets, deadlines and pressure.

Depending on how extensive your help can get, if it is limited and won't need to scale, you could take the single button approach which has a single page for help contents with tabs for each category.

If however you feel, it will scale exponentially to a point that the Agent will need to search and think of words to search with, it might be essential to have help situated for every widget with maybe a Question mark besides the widget that shouldn't be placed in a way that it is clicked accidentally.

While the single button leading to a common help section is good, it cannot be scaled and might waste time for the user to need to stop his flow and go specifically to search a problem.

Help section for every widget can be a possible solution if you do not have too many widgets and it is only clicked if the user decides to click on the help and not accidentally, since it can cause more frustration.

So the answer truly depends on the content and emergency of that help. I believe it should be quick and descriptive and shouldn't have the Agent think or put a lot of stress to find the help.

-1

as per my understanding you should go for second option. Because as per recent trends mobile app should have minimalist button. Because too many buttons confused the user. So it's better to give one button and then give categories or list of topics on which they want help.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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