The Nerdery is a digital strategy consultancy that was hoping to fix the issues with their meeting room scheduling system. In many instances, the current Google Calendar system is sufficient—however, issues arise when last minute flexibility is required, for example if a room is double booked or equipment is broken/missing. To reschedule a meeting, the current system requires users to be logged in at a computer and have a level of “tribal knowledge” of room location, capacity, equipment, and general presentability. The scheduling is currently cumbersome and inefficient, allows for double booking, and is lacking the information critical to scheduling. I worked to create a prototype for a scheduling system that is able to fix current scheduling woes at the Nerdery, using just 400 student developer hours.
An MVP prototype of a mobile scheduler that provides users with easy access to information on room capacity, tech setup, and location, particularly useful for last-minute rescheduling issues.
MY METHODS AND TOOLS
Competitive analysis, directed storytelling, rapid prototyping, journey Mapping, Kano analysis, annotated wireframes. Sketch, Adobe Illustrator, Axure RP.
Duration and date
1 week, June 2017
I began by doing a competitor analysis—that is, doing research on competitor products in the market to determine the baseline information—what had to be a part of the product? What kinds of questions would I ask when meeting with the client?
Our team met with the client onsite at their workplace to see firsthand the current systems they used and the meeting spaces in that particular building, to identify limitations, and to build empathy. With information gained from directed storytelling interviews with the client, our research team began by creating a large set of rough feature prototypes that synthesized the information we received from the client—from logins, search functions, and scheduling, to bigger, fun ideas like GPS-enabled room finders and company-wide iPads on the outside of every conference room that allowed for scheduling and rescheduling.
To visualize and communicate the current process as well as the ideal process, I created several Journey Maps of the client’s experiences. The first is a map of the current user journey—the second is how a projected experience might look.
Several experienced software engineers came to meet with our group to give us estimates on just how long the prototyped features we had come up with would take—they jokingly called it the “dream crushing hour,” the dose of reality required to determine what we could actually do in the hours budgeted.
With this knowledge, the team reassessed, revised, and sent a list of actual potential features to the client for survey. Each feature had two sets of questions—“How would you feel if this feature was present?” and “How would you feel if this feature was absent?”—with a range of possible answers. With this set of survey answers we preformed a Kano analysis, a method intended to glean quantitative information from qualitative data. By cross-referencing the “present” answers with the “absent” answers, each feature is assigned an attribute quality of Required, Desired, Exciter/Delighter, Neutral, or Anti-Feature. The Kano analysis is essentially an evaluative tool to assist with prioritization: using this method combined with the estimated development hours, I was able to define the tradeoffs—which features I wanted to include in the minimum viable product and which features needed to be tabled as stretch goals.
However, there were some issues with the information gained in this process—particularly, the speed with which we were working and the rounds of review that went back and forth “over the fence” led to some communication issues. If given the opportunity to recreate this process, I would focus on clarifying communications for the initial rounds of prototypes assessed by the developers as their insights were essential to the rest of the process, as well as the survey that was sent to the client. Our team was working with a previous team’s questions and wasn’t able to rewrite the survey. This led to some issues with understanding of the test, and some well-planned clarifying would assist this process immensely.
Given the needs of the clients and constraints of engineer scoping hours, the minimum viable product for this project is a mobile scheduler that provides users with easy access to information on room capacity, tech setup, and location.
I created a set of annotated wireframes to share the final concept with student software engineers, as well as an interactive prototype. Click image to view the PDF.
LOW Fidelity Interactive prototype
Using Axure, I created a low fidelity interactive prototype that meets the client request of a quick and simple way to reschedule meetings. Based on developer recommendations, the site also has administrator functionality.
Next Steps & Stretch Goals
When the annotated wireframes are sent to the student developers, the information provided will act as a starting point. The first iteration of product will then need to be tested by the client to determine the next round of improvements.
For this product to have long-term viability for the Nerdery, the new system must be seamlessly integrated with GSuite, particularly Google Calendars, and include features that facilitate easy long-term planning, prevent double booking, and assist meeting planners and attendees in locating spaces. Additional research and planning is required to determine best methods.