The End is Near
As mentioned before, we now have defined “swimlanes” so individuals have more ownership and accountability over processes and deliverables. To prepare for our final sprint, each swim lane planned out their milestones for the sprint and posted them on post-its, kanban style. When all the post-its were up, we were able to discuss due dates and plan for optimal hand-offs and overlap.
Our presentation and website processes are coming right along! This week, content outlines and layouts were presented and critiqued as well as drawings for the hierarchical navigation prototype, and a usability test plan. We’re aiming for MVPs (minimum viable products) for our deliverables and usability tests for the end of the week.
At the end of the last sprint, we planned to have weekly user tests for our designs. This week, we tested an InVision prototype for a web interface to find crowd-sourced supplemental information (tribal knowledge) about a procedure that has been assigned to a technician before the technician begins the work.
What do WADs and rap music have in common? Annotation-embedded platforms
Our takeaways fell into three main categories. We found that all users wanted to look at the WAD instructions while they were using the interface to find supplemental information. Additionally, when using the interface, users employed a variety of ways to determine trustworthiness of a post or person. This included considering upvotes, comments, years of experience, recency of credentials, and if they knew the poster. Lastly, all users wanted to take the information with them when they executed the actual task (in the future) but wanted a shortened version of the information. For example, just clips of a video or notes on the post instead of an entire video or an entire post with comments, content, and videos.
After reviewing the findings, we specifically chose responsive web to be our platform for this prototype and found design inspiration from Genius.com, an (originally rap-based) site that features original song lyrics side by side with the user generated annotations. This was implemented in the next iteration of our “tribal knowledge” prototype and is on the docket to be tested with NASA users next.
How will we evaluate all this? Metrics
Gathering qualitative data during prototype testing is fairly easy, but gathering quantitative data can be much more difficult. The problem is not new, and has been addressed by players in industry in a few different ways, most of which take advantage of some kind of product or product framework already in existence. Still, Google’s HEART framework, their Goals-Signals-Metrics framework, and NASA’s Task Load Index provide some hints toward creating quantifiable metrics. Our high-level goal is to “beat the rolodex-style, old school way of transferring knowledge by talking to knowledgeable people.” We have broken those down into the following questions or signals and their enabling metrics:
- Is it fast and easy to find relevant info?
- Does the product provide the trust necessary to act on the info?
- Does the product connect knowledge across domains or filters?
Nielsen Norman Group also encourages focusing on task completion as a metric, as it is easier to measure and different tasks can represent different metrics. We’re taking this under consideration as well.
Fun Stuff
On top of our work, we also got the opportunity to tour the Vertical Motion Simulator and the Human Vibration Lab (not pictured).
Until next week,
Team C-137
