HILDA MYER-POST
Migration Situation
Case Study:
THE PROJECT
Picture this: Engage is an industry-leading student engagement platform used on college campuses all over the world. We are in the process of migrating campuses from OrgSync (a former competitor) over to Engage after our companies merged. During the migration process, it becomes apparent that a certain feature in the forms area (think Google Forms) of OrgSync is missing from the Engage platform – and a lot of campuses’ happiness and willingness to sign contracts are abruptly on the line. But that feature is not particularly secure, and does not promote best practice.
THE APPROACH
We dove deep to figure out A) why this feature was so important and B) what problem it solved and came up with functionality for Engage that alleviated (most of) their concerns. In some ways it wasn’t ideal because we were pushed for time, but we were able to come up with a solution that fit the circumstances.
I led our cross-functional team through the research and design phases and my developer colleagues took the lead through implementation. I then gathered and synthesized feedback post-release.
Interviews
THE PLAN
My first task was to really drill down and make sure I understood the issue. Yes, the feature wasn’t in Engage. But what was truly missing? What problem did it solve? I chose to interview seven different users who had Big Feelings about this feature.
I crafted the interviews around two key questions.
-
How are you using this feature?
-
Why is it important to your process?
​
I limited my plan to two questions to give myself room to probe deeper depending on their answers. I asked questions in such a way that I could get to the root of the issue, and to understand why they were as frustrated as they were.
THE RESULTS
The interviews yielded a few key results:
​
-
The feature was being used in ways that weren't best practice, but had become a core part of their processes.
-
For most of their use cases, there was not any kind of workaround in Engage.
-
The users were prickly about this topic, to put it mildly.
​
I was able to get each of the users to warm up to me (though it took some time!) and eventually came to the conclusion that a huge part about this was simply feelings about migration.
Based on the results, I started by brainstorming what the ideal response would be. In this case, the ideal response would be looking at how forms in Engage work as a whole, and find better, more secure ways to accomplish the goals set by the users. Unfortunately, we all (product, development, and I) agreed that there was not time for such a large scale response. The forms functionality in Engage was all in legacy apps and it would take more time than we had to conduct the research required for an overhaul, not to mention the actual development. We had to prioritize “fast” over “thorough” in this situation. There was too much business on the line.
Ideation & Design
EARLY BRAINSTORM
We knew we needed a solution that accomplished two things. It needed to A) account for the majority of use cases from OrgSync and B) make sense with the existing forms features in Engage. Before we even got into prototyping, we needed to scale down as much as possible to find the smallest possible story that would fulfill both of those pieces.
Did we need this feature in both general forms AND event forms, like in OrgSync? Based on my research, the majority of cases only used it in general forms, so we elected to postpone event forms (spoiler alert - we postponed it indefinitely).
Do we need to account for both authenticated and unauthenticated users? Once again, the majority of use cases were only for authenticated users, and unauthenticated users in this context posed a security risk. So we skipped that too.
We were left with a story that was much simpler to implement and still accomplished what we needed it to.
PROTOTYPING
Our next step involved a few days spent around a whiteboard (me + the four devs that made up our team), drawing out basic user journeys, exploring relevant user roles, and accounting for every possible state. Once we agreed on a design, I quickly put together basic prototypes for all of the affected screens. These prototypes were very simple - but this story was much more about what goes on under the hood rather than the actual UI.
PROTOTYPE V1 (Balsamiq)
PROTOTYPE V2 (Figma)
Release
FEEDBACK
Once we settled on the design, the developers on the team went to work making it a reality. This included implementing a feedbacker designed to gather information from campus administrators (i.e. the ones who would be turning this feature on and off). We made the feedbacker as simple as possible – it asked users to give the feature a thumbs up or thumbs down and requested an optional comment.
32%
68%
Based on the comments, most of the negative responses were due to confusion about how the feature worked, primarily from campuses who did not use OrgSync. To them, this feature seemed superfluous and unclear – just one more setting that they had to select when making a form. But to those from OrgSync, it allowed them to resume the processes they had either stopped or created strange and inefficient workarounds for.
We predicted that this would be the kind of feedback we would get. Short of doing a full redesign of form reviewers, we were not going to find an implementation that was ideal for all parties. The team checked in with each other and with product regularly about the feedback and made some tweaks in response, including adding more detailed instructions.
Reflection
Through this project, we freed up over 50 campuses who had refused to migrate until the feature disparity was resolved. We also improved relations with the majority of campuses who had already migrated. The creation of this feature saved Campus Labs hundreds of thousands of dollars in revenue in the 2020 fiscal year alone.
This design was a big learning experience for me. It was the first time as a designer that I truly felt the pressure of a direct business need and was forced to make changes to my process in order to meet that need. It taught me a lot about being adaptable and agile as a designer. And it ignited in me a desire to collaborate with Product and to consider the business and high-level road map when making design decisions.
​
If I could go back and do it all again, I wonder if I could probe one level deeper in the interview process. This feature didn't feel quite up to the normal quality of features that we put into Engage. Perhaps there was a more elegant solution that we missed? Or perhaps the situation would always be less than ideal. Either way, I am proud of the work that our team did under these extenuating circumstances.
