First post here, but long time reader. I've had a look around, but couldn't find anything that exactly answered my question, so I'll jump in...

Here's my scenario:

Our business has a web app, used by engineers in the construction industry. A part of the app allows engineers to report issues from site, both to notify subscription groups, and to enable management to take ownership of the issue.

Current workflow:

  1. User selects from three top-level categories
  2. New screen: User photographs the issue
  3. New screen: User tags image (effectively a subcategory of the top-level category)
  4. User taps 'Send' -- Photo then broadcasted to subscription group dependent on subcategory

The problem:

  1. The correct tag/subcategory is not always chosen by the operative. Probably a quarter of the time, they choose the accursed 'Other' category.

  2. Office users then spend time moving issues out of 'Other' and into the correct tag/subcategory.

  3. There appears to be the added problem that field engineers expect some of the tags/subcategories to be under one top-level category, when in fact they are under a different one. So, they select the 'Other' option!


Granted, this idea of choosing a top-level category, taking a photo, and then tagging with a more granular subcategory is pretty poor design. My first thoughts are to scrap the top level categories altogether, and replace with a single 'Report an issue' option. Or, at least to bring the top-level categories onto the same page as the bottom-level tags / subcategories.

I just wondered if anybody had any other ideas on how to improve this design? If anybody has any examples to hand, it'd be really useful.

Thanks in advance.

3 Answers 3


field engineers expect some of the tags/subcategories to be under one top-level category, when in fact they are under a different one

A potential solution to this would be to remove the top-level categories as you said. I would recommend grouping all the categories into a single list and implementing some sort of search functionality.

If you would prefer not to get rid of the top-level categories, you could leave them in the list as dropdown headers. E.g. a user encounters a pipe that is leaking onsite, searches "pipe leak" and is brought to "Water > Faulty Piping"

  • Many thanks for this - makes a lot of sense. Combining into one list would help to avoid problem no. 3. I was reluctant because this would give rather a long list of options (approx 20). Perhaps that could do with shrinking a bit! It'd be nicer if all the options could be displayed at once on a mobile screen, without the need for scrolling - but maybe that isn't possible. Can't say it isn't fun to take on some existing software and try to solve these issues!
    – Joe
    Commented Apr 21, 2017 at 6:54

There appears to be the added problem that field engineers expect some of the tags/subcategories to be under one top-level category, when in fact they are under a different one.

I will also start from this statement. This is more of an Information Architecture issue.

One way to fix that is to create a card sorting sessions with your engineers and ask them to categorize properly the issues or even make their own categories. Their mental model is different than your mental model and this will help you understand how they think.

More about card sorting: https://www.usability.gov/how-to-and-tools/methods/card-sorting.html

  • Thanks Dimitra. Yes, I think you are right about the Info Architecture. Card-sorting for the top level categories could indeed be useful. We're constrained a little by regulatory terms - so really the engineers should understand the terminology, but you are right, this is not necessarily a given. Thanks again.
    – Joe
    Commented Apr 21, 2017 at 7:02

Let's start from the ideal long-shot scenario. The best experience for the engineers would be to:

  1. Take a photo
  2. Send it
  3. Image recognition would know what the category it falls

Because of a simpler approach I assume you will have to follow, you need to ask for the category the engineer, so the journey is more like:

  1. Take a photo
  2. Categorize the photo
  3. Send it

Now, because you want to limit uncategorized photos, you can follow few tactics, each of them having trade-offs:

Require selecting a category (mandatory step) and:

A. Do not allow for "Other". The con is that some photos will not get sent

B. Allow for "Other". No improvement in limiting uncategorized photos, only flow improvement.

C. Allow for "Other", but require providing a comment on what category is missing - this will create a feedback loop, for evaluating and adding missing categories

D. Allow for adding categories by engineers - watch out for data quality - duplication, typos issues, etc.

  • Allowing points C and D would provide you more information on the "other" feasible scenarios. And down the line with that information you could narrow down the categorization options. Commented Apr 20, 2017 at 16:33
  • Thanks Jakub - the long shot would indeed be nice! I don't think D would be possible - or might open a can of worms. We're in rather an old-stool industry, and most of these guys don't really want to be using 'technology' at all... They'd literally rather hit the wrong category and leave a comment -- then they are still reporting an issue, and the issue is still going somewhere. So, from their point of view, the user story is fulfilled. It's just a pain for the back office staff, and is not conducive for effective BI if the categorisation is all over the place...
    – Joe
    Commented Apr 21, 2017 at 7:00
  • 1
    For the back office, the goal is to reduce their workload per issue. If you use solution C, you could use simplistic deduplication mechanisms, that would suggest to a person from back office how free-text engineer's comment is matching the existing categories. You could start with no rocket science, just by checking if comment includes word matching some category. Regardless, think of cost/effort for the whole organisation - is it more important to catch all issues VS process the correct ones.
    – JakubTutaj
    Commented Apr 21, 2017 at 20:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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