Prototyping Lead +
I'm a firm believer in owning and presenting mistakes, so here was ours: we put the cart in front of the horse.
We really wanted AR Hololens app. That plan ran into several problems, and while we tried to solve that problem we lost focus of our user and their needs.
Myself and another UX research oriented colleague built the product over the course of a month. In order to do this effectively, we prioritized getting prototypes to a testable state. At first we started with extremely fast cycles: two full designs and usability tests within a week. It was crucial to test primary functionality, and to design crudely and minimally in order to achieve such short cycles.
The initial goal was to understand reputation signals, so I designed a crude Reddit-like forum.
The format was naturally wrong.
Upvoting and downvoting was too subjective.
Technicians would only be motivated to use a product if it assisted them in the context of following WAD prodecures.
I revised our design scenario, and made sure the UI was built around the context of a techician following a WAD. I took inspiration from an unlikely source: genius.com. I thought annotating the WAD with technician tips served our user better.
A larger screen such as a tablet is preferable, and supported by our research.
If a note is editable, it's also important for technicians to be able to see the edit history.
People want to see who wrote a note, or where it was sourced from.
We moved towards a tablet interface, and we were also more thoughtful about how tribal knowledge may manifest in different media type other than notes. Video, for instance, was supported in this iteration.
I addressed how notes may be used in the context of a team huddle. Here the team can see that their colleagues marked a note to review in briefing. They can assess whether the note will be useful within the work they're about to execute.
Framer was used to ensure that we could prioritize both rapid iteration, and modularity when we established components we wanted to keep. The tool offered fantastic versatility, allowing me to switch between coding, and designing components interchagable. I even wrote a whole Medium post on it.
Elements could be easily made interactive, and then modular and reusable everyone using class components.
The product it intended to resolve the needs of both technicians as well as NASA as an organization. Like many products, the more adoption this has, the more useful it would be. By focusing on the needs of the technician, the intent is that the product achieves a critical mass of user input necessary to its utility. As more technicians reference notes or respond to questions in closeout, the product should become smarter. It should gain some awareness of the context informing which notes are useful, and where. Notes may be more useful in some facilities than others, or in some conditions, such as bad weather. In turn, the product would become better at recommending contextually-relevant notes to technicians as more contextual insight is gained.
Making the product usable at the mobile level also adds a layer of versatility necessary for adoption. While a tablet is an ideal interface for the solution, we wanted something technicians can use right away, with no dependence on their supervisors to acquire hardware.