Case Study | Developing a Survey Tool for DevMountain
The Situation
As technology advances so does the power and influence of the individual. The ability to rate, score and review institutions online has been a useful tool in both communities and businesses. This information provides crucial feedback for these institutions to grow, pivot, assess, or correct.
DevMountain understands this value and has taken steps to provide a tool for feedback from their students. This tool has been extremely helpful in gauging the performance of the various different products/courses with in the DevMountain portfolio.
While helpful, this tool is not without flaws. I was tasked to rebuild the experience of theDevMountain Survey Tool. There had been comments among the staff being frustrated with the current tool and it was collectively decided the tool needed a re-design.
Setting Up My Strategy
In my first meeting, I was shown the current solution for the survey tool. I took down notes and names of owners and influencers of the tool, listened to the common pain-points and considered the process I should take to start this project.
After I was briefed, I planned out the steps I would take to solve this problem. The process I decided to start was based on a combination my design experience and other processes I have used in the past. I would tackle both the Student View (taking the survey) and the Instructor View (creating surveys and viewing the results).
The Process:
Audit, Understand, Frame and Finalize.
Audit
The first step I took to start designing a survey tool was to audit the current solution. I had current instructors and mentors walk me through the survey process and took surveys that had been sent to me. I intended to look into both the instructor and student sides of the survey tool. I took notes on copy/labeling, functions/features, and visual style. These are my findings:
The first aspect that I noticed was the copy and labeling within the tool. On the Student View, there was some unclear copy on the scale tool. For example, the scale function was labeled in a possibly confusing manner. Also, the question wording was not properly contextualized.
Notes:
The slider view to the far right reads: “Super very well” (confusing)
Wording in question might not apply to student. What if the student’s friend of family isn’t interested in DevMountain products offered?
Visual is dark. Scale function is confusing. Style is inconsistent.
Next, I turned my attention to the Instructor View. This side of the tool was much more detailed and intricate than the Student View. On my initial audit of the Instructor View, I noticed that there was a steeper learning curve with the tool. I had to have someone who already knew the process walk me through the tool.
Notes:
Confusing and inconsistent labeling (ie Template vs Survey)
Visually bland and CTA isn’t clear
What is “Add Topic/Instructor”?
Understand
As I was briefed on this project and started auditing the views, it became clear that I’d need to understand the capabilities and features of the survey tool. Understanding the flow of the Instructor View and what/how data is collected and viewed was crucial to finding a solution.
I started by building a flow chart to help me understand with visuals. I went through all the features and pages of the Instructor View and created the following:
I found that there were a few dead ends and features that were unclear. For example, once a user created a survey template, they were unable to preview it. This problem creates a frustration with the user and almost a slight panic of not know exactly what they are sending to their students.
Also, the feature of adding a Topic/Instructor was unclear. I had to reach out to the person who coded the tool to find out its exact function. I was told that that feature was used as type of tagging tool that could connect certain topics and instructors to various surveys. For example, if I tagged Professor X to this week’s survey, I could then see he’s associated with that survey and as well as any other surveys he’s been tagged in. I asked other instructors if they knew about this feature. Most of them said that they didn’t but that it would be useful feedback. They could apply that data to other mentors and modules.
With these problems in mind I started to design wireframes for a new solution.
Frame
After I audited and understood the tool, I wanted to convert my findings into a wireframe solution. I began with restructuring the navigation to left side of the view. This created a new hierarchy system that would help the user know exactly where they were in the tool.
Also, when discussing/testing the Add Topic/Instructor feature, research led me to a new use for this function. It was clear that we should tag each question with an associated Topic/Instructor instead of the entire survey. By making each question more specific, we could get more accurate survey data. I changed the naming convention from “A”dd Topic/Instructor” to “Add Tags”. This was to help the user understand the function and versatility of this feature.
After testing wireframes and getting feedback it was time to move on to the final solution.
Finalize
Instructor View
On the final design, I decided to keep the label of Add/Edit Topics to help with consistency. I wanted the user to know where they were and what they are doing on the tool. The left navigation was to contain Locations and then be filter down from there. Once a location was selected the user would then select a course and from there the desired survey. It was imperative that this was a clear process. I was fortunate to have DevMountain’s style guide to help with the final design. I decided to use DevMountain’s “blue” for a the call to action and navigation.
In addition to using blue for navigation, I also implemented a collapsable left navigation. This new navigation system would help the user know exactly what they were looking at and how to navigate to and from courses.
As for viewing results, the design shows the results in the same view as the navigation and related surveys. With a function to share the results in a downloadable .cvg file.
Student View
During the process, I used SurveyMonkey to test out various styles of surveys. I found that the right questioning was less likely to confuse a student and produce better data. I made minor adjustment to the slider tool and labeling to help clarify. I then used the Instructor View to influence the visuals of the Student View.
Conclusion
As I reflect on this project, it was important to get it right. My main concern was to increase the usability and understanding of this tool. It took me six weeks to fully audit, understand, frame and finalize this solution. The end result is a more functional and friendly experience for both instructors and students.
Overall, this task was a lot deeper than I first expected. There were many iterations and changes that were not mentioned in this case study. However, this case study did include the big changes and updates. Please inquire if you have any questions about this tool or the process.
geoff.tribe@devmountain.com
