Separate fields for problem/solution

Context

We currently have one field, Comments, which is acting as a catch-all for various pieces of information. There are various pieces of information that could go in there, and we currently get a mix of problem, diagnosis, and solution mixed together (if included at all).

Constraints

  • We get quite minimal information added into the comments field at present
    • Average word count is ~6 words. Over 1700 devices with empty problem description. Over 2700 with between 1 - 4 words.
  • We have to strike a balance between capturing the data in exactly the format we need and overwhelming people with too many fields for data entry. Good UI/UX can help alleviate ‘field overload’.
  • ideally, we’d have a set of predefined problems/solutions/etc per category, rather than relying on freetext input at all, which always brings its own issues - this is a wider ORA question

Design decisions

Spreading the load of data capture between hosts and Restarters should help improve the data capture, particularly asking for further input by Restarters after the event has finished.

Possible pieces of data capture:

  • Problem as reported by the participant (i.e. self-diagnosis, e.g. ‘it doesn’t turn on’)
  • Problem as discovered by the repairer (i.e. diagnosis, e.g. ‘dead hard drive’)
  • Solution if discovered

You could argue that both participant and repairer could contribute to both cataloging the symptoms and providing the diagnosis of the problem. It’s perhaps not as simple as problem/diagnosis/solution.

The ideal would be for a given category of product (and possibly even model of product), to provide dropdowns/suggestions for each of these, although to be begin with it will continue to be freetext.

Possible analysis

What are some could stories we could tell with this data available?

Changes to existing data

As and when new fields are added, some post-hoc data scrubbing would be needed to analyse the comments field and to break it up into its constituent parts as per the new fields. It wouldn’t have any affect on environmental statistics.

Since this is going to be a work-in-progress for a while, here are a few of my initial, but definitely not final, thoughts for discussion:

  • I think it’s useful to have “Problem as reported” and “Problem as diagnosed”, so we can eventually use that as knowledge (e.g. if it looks like X it could really be Y), but I think we should omit the “by the participant” and “by the repairer”, to avoid an “us & them” implication.
  • Definitely a “Solution”.
  • “Notes” for miscellanea.
  • Maybe a “Parts” too, so we can record what was needed (whether it was actually found and used or not).
1 Like

Inviting Restarters/fixers to get involved in the data collection opens up many new possibilities, for sure! We suppose the important part is not overwhelming event organisers/hosts if they do not have super eager/active fixers.

As Neil points out

That said, we’re excited to see where this goes. Perhaps we could have a special group of volunteers dedicated to this particular question, testing different techniques and determining how workable they are, and how powerful they are in terms of data analysis and insights?

1 Like