Online forms maintenance was stuck in a cycle. Small changes had repeatedly been made to address larger pain points and over time the process had broken down. A team of web developers managed client form changes but client services believed users wanted more control. I led a research initiative intent on identifying current pain points in their interactions with our service and aligning development goals with user needs.
Client Services wanted a service design that would enable clients to edit the content of their web forms. This 'self-service' approach acted as a springboard for research.
I started by looking at how 10 competing and non-competing online form editors were doing self-service to understand more about the what was available and how feature sets and publishing were getting handled.
Another UX Designer dug into the larger competitive landscape on a product level and prepared a short presentation for the group at the upcoming creation session.
Coming into the project there were many assumptions held internally about what would make the process better. By holding a prototype creation workshop with key stakeholders, we were able to put these assumptions into a testable format. The greatest challenge here was getting the stakeholders to create prototypes with S.M.A.R.T. objectives (Specific, Measurable, Attainable, Realistic and Timely). Since the prototypes were presumptive, the goal was not to get the UI exactly as it would appear in the final product, but rather to create something aligned with our thinking but that our clients could feel free to give open criticism.
During the creation session, teams were encouraged to build around focused objectives and tasks. Following the session, I worked with the teams to firm these up and match the prototype experience to best meet the desired objective. Each one required several rounds of iterations to get where they would accomplish our goals. In the end, we had 5 artifacts, each meant to explore internally held assumptions about what our users needed.
I teamed up with our User Research Lead to create a detailed interview guide for the engagements. We included several standard formalities and agreements as well as a brief introduction to the plans for the day. We were to interview each participant in 3 parts. Our guide informed us how each section would occur. We went through several iterations of this guide following feedback sessions with our consultants.
We held a series of discovery interviews with Account Managers, Forms Developers and other internal stakeholders to a identify rough understanding of common user roles. Ultimately, our goal was to find 15 participants across 3 target persona types.
The user researcher worked with client services to gather 30 possible users who we could talk to. Together, we conducted 15 minute screener calls to better understand each user's role and their relationship with the current product. We ended up with 13 participants across 3 institutions.
This type of interviewing was new to our team so we wanted to run a few pilot sessions in a "safe" environment." By looking around the building, we were able to find a few willing volunteers who were familiar with the application update process but not well aware (yet) of the project in development. We recruited 3 folks from different parts of the company and spent and hour with each of them running them through the background interview and a few of the artifacts. The UX team watched remotely while our User Researcher, Leo Frishberg and myself piloted the interviews.
Section 1: Broad interview with questions about the participants background, life goals and work history.
Section 2: Contextual inquiry observing the participants interacting with our product as they would during a regular day at work.
Section 3: Interacting with the presumptive prototypes guided by a series of open questions. We recorded the audio from each session and I took photographs of both user workspaces and of the prototyping interactions.
We ended up with nearly 45 hours of recorded interviews. The interviews were transcribed and placed into a spreadsheet. We then printed them out on large sheets of paper and created a makeshift 'war room' where we posted them along the walls of a long hall. Myself and the rest of the UX team along with interested stakeholders were invited to participate in identifying trends either on their own or as part of a series of group analysis sessions.
In addition to the transcribed data, we poured over dozens of photos from the artifact sessions and contextual inquiries. These provided further insight into what a day in the life of a college administrator feels like.
Based on the data obtained through the interviews, we constructed models of how each participant interacted with their colleagues and peers on campus and how those interactions influenced behavior inside our building. The maps were the building blocks for the workflow diagrams that would eventually become part of the Personas.
The interviews validated 2 of our 3 our assumptions about persona types. The third was altered to more closely align with the data. Using a card-sorting exercise, we were able to identify about 15 different possible 'content buckets' that would present different set of traits about each persona. Our goal was to create documents that would allow anyone from engineering to marketing to understand and empathize with our the people we were designing for.
The context scenarios are short narratives that place the personas into a future situation where the interact with the finished product. In order to identify a range of categories upon which to base these, we held a small card-sorting workshop with stakeholders. The scenarios enabled the team to think beyond the limits of near-term realities and explore purely excellent user experiences. I wrote many of the scenarios myself and worked with 2 others in their penning of additional ones. We had regular editing workshops to refine them and ended up with a solid 25.
The UX team assembled to analyze the context scenarios and to identify interesting trends and opportunities. We performed a card-sorting exercise to further narrow down key interactions indicated by the scenarios. As we sorted we began to build a roadmap in step, stretch and leap phases. Step features are near-term features essential for getting the product off the ground. Leap features are 2 years out; and stretch features highlight pie-in-the-sky, long-term goals. With these defined the next step was to build them into a functional prototype.
With the roadmap making sense, I designed a prototype that would allow our participants to interact with a functional version of a our proposed software. We planned to meet with a select set of previous participants as well as a handful on influential new participants to gather feedback. The prototype exemplified a mix of near-term and long-term features of the roadmap. Based on feedback gathered during this round of interviews, we were able to re-arrange our plans to best meet customer needs.
Additional analysis of the prototype sessions gave us the opportunity to learn what features required additional fleshing out and what needed to be moved up or down the development road. Based on this new feedback, I further refined the development roadmap and added additional details explanations of the features and functionality.