User Experience Design
2 User Experience Designers
This project was for a major feature in a tool for higher education instructors and students. Primarily it would be used in english composition courses for undergrads. Instructors could create assignments, manage activities, give feedback, and monitor their students through this tool. Students could upload their work, compose within the tool, review feedback, review course activities, and monitor their progress.
While I was the designer on this product from the ground up, this particular project focused on the peer review aspect. The task was to entirely design a digital experience to help instructors administer peer review as part of a multi-draft writing assignment in their class. Some of the things to be considered were how to group students, monitor the groups progress, allow multiple non-instructor roles to give feedback on a paper, and how to help students know where they are in the process.
We worked with our internal team and sponsor users to really understand the duties of a system administrator, in particular in the context of having to go through the process of doing a security update.
We spent time doing interviews, synthesizing our findings, and vetting those with our sponsor users to make sure that we were really able to understand their role and daily duties.
Working through empathy maps helped us refine the persona of the system admin and develop a persona for a security/compliance admin.
And compliance admins:
- Want updates done asap
- Deal with outside auditors
- Have a high pressure position with large financial implications
For the system admin we learned that they are:
- Stressed about time
- Risk adverse
- Extremely cautious and thoroughly test any update
Now that we were beginning to understand our users better, we needed to understand their problems with this highly complex situation.
Initially we were tasked with making the actual updating and installing process easier. As we began to work with our users we started finding that there were numerous pain points, and not all of them revolved around installing the update.
The team was able to uncover 3 distinct areas in the process, finding out if you were vulnerable, fixing the vulnerability, and reporting that the fix was done. In these categories we found many more granular steps and specific pain points, but find, fix, and report became our foundation.
For the Find category, what we were learning was that it took upwards of 2 weeks of research on any given update to find out if it would fix your problem, work correctly in your unique environment, and if you had to do additional updates to get it to work. This is all in addition to waiting to see what update gets release, and you are vulnerable the whole time.
Fixing brought a whole new set of problems, such as fixing any dependency your update needed, and scheduling for potential downtime with your servers.
Reporting varied by industry, but some of the more highly regulated industries had to spent enormous amounts of time in the command line pulling logs to prove that they were compliant. One of our users quantified his situation for us.
"I spend 25% of my time during the first half of the year prepping for our audit in July. That may not sound like much, but multiply that by 50 hours a week, at a manager pay rate, with all the weeks required, and that is a lot of time."
So coming out of all of our interviews with our users we realized that we could have the biggest impact on finding updates, followed by reporting. Fixing was initially where our project was focused on making the biggest impact, but we found that the biggest pain points that consumed the most time were not in the realm of fixing. Additionally fixing proved to be an interesting case that gave our team a surprising challenge that caused us to push for a pivot.
Our initial ask revolved around the idea of making updating a 1 button solution, or as easy as an iPhone to update.
We ended up having a small and a large change to the project that we had to work out with our stakeholders. The smaller pivot was that instead of focusing only on getting an update installed, we found new pain points for finding and reporting, and that these were ripe opportunity spaces.
The larger pivot though directly had to do with the ask of simplifying the updating process to a 1 click solution. Over and over from our users we were told that they could utilize scripts to accomplish this already, and that they wouldn't do it with their own scripts, nor would they be comfortable with an IBM solution. The process was simply too sensitive, and the admins were only comfortable if they were ultimately in control.
Realizing that we couldn't move the needle that far, the team began brainstorming smaller scale solutions and vetting the concepts with our users. These included things like letting the system tell the user what the dependencies were, and installing them on it's own. Letting the user set the update start time, and starting automatically. And if the server needed to restart after an update, let the user know, but let the server restart itself. These solutions resonated with our users and walked that line of making their life easier, but not making them give up too much control.
As a team we formulated a presentation on these findings, brought along quotes, user research, and our proposed solutions to present our case for a pivot to the team. Some of our users attended the presentation too, and together we were able to convince our stakeholders of a new direction for Project Monocle.
Now that our stakeholders agreed that a pivot was needed, as a design team we had to give them a vision on how this project would move forward in a new direction. We did this by creating hills, which are user focused statements of intent written as user outcomes. The design team held several working sessions with our stakeholders and users to ultimately settle on 3 hills for the project. Each hill was focused on of the Find, Fix, and Report categories.
This whole opportunity space is ripe with pain points and areas that our design team could focus on, so we realized the hills were going to need some context . We gave our stakeholders insight into all of our findings and show them what we focused on and what needs to be examined in future work.
We also developed a set of design principles to guide us through the rest of the project and this gave our stakeholders and users insight into how we were going to proceed to tackle the hills.
For the remainder of the project we immediately moved to mid-fidelity wireframes and utilized Invision to make a prototype we could test with our users. The UX designers worked directly with our researcher to use modified RITE testing to quickly iterate on our prototype.
This RITE method allowed us to make 3 iterations of our prototype per week, each version getting tested by our users. Not only did this method help us rapidly improve our designs, but by quickly acting on user feedback we built strong trust with our users. From one week to the next they were seeing their feedback being incorporated, and this kept them highly engaged with our team.
Towards the end of the project our team delivered a coded prototype that highlighted key features of Monocle. Making Monocle extensible was a key component, for the scope of this project we were dealing with 1 type of security update. However, we built Monocle in such a way that it had a framework that could be scale to include other updates such as OS updates. We had learned that these admins are foremost concerned with problems, so we included a layout and filtering that allowed the admins to drill into the problems immediately. A dashboard was designed, that was role based and could be customized. This meant that now more people could access Monocle and get job relevant information without having to go through an administrator.
The real power of Monocle was that we brought all the update information into the GUI, including dependency information. This eliminated the need for a user to search IBM's repository in an attempt to find the necessary information. This information was proactively served to the user inside Monocle. The user could also see any dependency relationships that needed to be taken care of, and schedule the updating process through Monocle. Then Monocle could automatically take care of the updates on it's own, while not requiring the user to give up more control than they were comfortable with. None of this was possible before Monocle. A few of the key screens can be seen below.
This project was presented with our stakeholders, with several executives present. Our users also attend the presentation, and laid a strong business case for Monocle to be picked up and brought to life.
"When is the release date for Monocle? I already have reserved a portion of my budget to purchase it."
Due to the response and success of the project, this was the first IBM Design incubator project that became a hallmark project. This meant that our 6 weeks of work was so well received that a new team was formed to continue to build this into a real product that is released into the market. A team of designers was formed along with business and technical support to continue work on Monocle.
Additionally our design team was asked to present the work to some of the executive leadership of IBM Design as a success story. Our work and our process became an example that has been used by leadership to highlight the benefits of IBM Design Thinking throughout the company.
Additionally we are exploring 4 possible patents for the work done with Monocle.