Freedom Signal: Phase 2
Software as a Service
Embedded Files
To understand how we got here and the user research that guided our process, please see Phase 1 of this project.
Phase 2
Goals & Deliverables
Facilitate Team Ideation Meeting
Produce and User Test Low/Mid Fidelity Wireframes
Presentation of Findings
My Role: Facilitate stakeholder Ideation meeting, wireframing, prototyping, user testing, and presentation of findings
Collaborators: Joan W. (Co-UX Researcher), Milleigh V. (Project Manager), Lucy W. (Software Engineer), Pete D. (Software Engineer), Liz R. (Technology Director)
Timeline: 2 months
Tools Used: Zoom, Notion, Affinity Diagraming, Google Suite, Miro, Figma
Phase 2
How might we redesign the user interface to meet the advocate needs, and identify which improvements to focus on this release?
Leading Our Ideation Meeting With Stakeholders
Facilitated through Miro
Knowing that we had a great deal to cover and were working with developers and managers less familiar with these concepts, Joan and I decided to use Pomodoro time blocks to facilitate activities for this meeting. We broke each of the 4 activities into a 50-minute time block with 10-minute breaks to rest.
Ideation Meeting Goals
Give the team a sense of how everyone is using the software
Organize Pain Points (most to least impactful)
Cluster and then have stakeholders ideate on the pain points.
Establish "How Might We?" statements:
Generate many potential ideas to narrow down and prioritize into an action item list for developers.
Determine Minimum Viable Product (MVP) for release 2.0 timeline.
Warm-Up Exercise
Sell Your Bad Idea
To get everyone comfortable with the Miro collaborative online workspace we began the day with a fun warm-up exercise. We chose "Sell Your Bad Idea" to help the team step outside their comfort zone and practice brainstorming ideas in a low stakes and humorous way. Split into two groups, each had 5 minutes to come up with as many selling points for their bad idea product as possible and select one team member to pitch it to the other group.
Affinity Diagramming Revealed The User's Deeper Needs
Pomodoro #1 : Clustering
We began by working as a team to cluster the user's reported pain points, from the Executive Summary, and identify themes. To better understand patterns, we labeled each sticky note with the organization(s) that expressed it during the research phase.
We used blue sticky notes to clustered pain points and discussed how the user wish list items might improve or be a workaround for these points of user frustration. Wish list or feature request items were added with green sticky notes, as we identified their causes.
To further categorize these groupings, product features were labeled with orange sticky notes and sections of the interface with yellow sticky notes. Once everyone felt up to speed on our problem space we began to establish "How might we… " statements.
How Might We Examples
How Might We...
How might we help the user stay organized?
How might we help advocates work as a team?
How might we make sure advocates are set up for success?
How might we help organizations allow more people to have access to the software?
How might we help advocates build trust with victims?
How might we get volunteers to stay engaged with the software and organization long term?
How might we ease the feeling of guilt that they could be doing more to help more people?
How might we help users trust the software?
How might we help users to trust the volunteers in their team more?
Pain Points - Related to Features
On a second Miro board, we asked everyone to do the same clustering exercise However, this time instead of by feature, orange sticky notes labeled user feelings, and yellow sticky notes represented their emotional needs. By asking the team to consider the emotions of our users, we were able to build empathy which would situs in the following ideation process.
Pain Points - Related to Feelings
Pomodoro #2 : Easy Fix vs Deeper Need
With "How Might We..." statements ready, I presented the difference between building a feature-heavy product versus addressing the deeper need behind these many user pain points and requests. To do this, I presented this simple idea generation workflow.
Using the grouped pain points and feature requests, I highlighted with a pink sticky note a "face value fix" that would answer the user request. Following that, I brainstormed out loud with my teammate to generate the possible deeper needs in purple, based on research presented in the Executive Summary.
Idea Generation Workflow Example
Sticky Notes From Example
User Pain Point
User Pain Point
User Pain Point
User Pain Point
This example came from frustrations the Evangelist Persona expressed toward difficulty sharing information and working as a team. It was particularly meaningful because the ability for all team members to login and see notes in the potential victim's profile already existed in the Freedom Signal platform. The deeper problem was that volunteer members of this persona group were told by managers that it could not be done out of a fear that inexperienced users might "break" the software.
User Request
Face Value Fix
Surprising Outcome
As with several data points received during the research process, further analysis was needed to understand that the need here was not giving access, but building trust and education through training.
To address the deeper issue and add real value, my co-host and I verbally brainstormed solutions to resolve the greater need that prevented this persona group from working more successfully.
Deeper Need
Deeper Need
Deeper Need
Deeper Need
Deeper Need
Deeper Need
Pomodoro #3 : Working As A Group
With everyone on board, we broke into teams of three to start creating as many solutions as possible for each pain point grouping. At the end of this process, we asked each team to present their solutions and reasoning. By actively engaging the project stakeholders, my co-host and I were able to build much higher buy-in for solutions moving forward.
The "Ah-ha!" Moment
When the team had finished grouping, seeing these pain points through the lens of the user, understanding their goals and priorities, fears and motives, the energy of the meeting changed. Together, we were able to outline some truly innovative improvements. Many of which were far less resource-intensive to implement than the originally planned new features, and would not have been possible without the knowledge of all the stakeholders together in the room.
Pomodoro #4 : Prioritization Chart
We asked the team to agree on where each of the ideas they created should be placed on this variation of a Prioritization Chart.
We asked them to consider:
What breaks the process? What affects the most people? What only hurts the process? What requires the most dev effort.
Surprising Outcome
The proposed new feature In-App Calling had been believed to be a necessity for this software update. It was to my surprise that during this step the team moved it to the bottom of "Want to have" when they considered their effort against how it would impact the user's process.
Chart Layout
From the top down, each section is labeled:
Breaks The System
Effects Most Users
Want To Do This Release
For Next Release V3
Nice To Have
From the left to the right, each section is labeled:
Useability
Knowledge
Feature
Once the team was in agreement, I blocked off everything except for the items in "Breaks The System" and "Effects Most Users", identifying the critical priorities the team themselves had narrowed down based on the user's needs and their feasibility in the timeframe for development. With this established, all other changes to the software would be secondary to these main goals. Before concluding our meeting, we assigned tasks responsibilities to teams and distributed supporting documentation.
Usability (visual design team)
Message Interaction screen layout
Visual indication if the folder contains something unread
Standard editable extendable folders and clear distinction in the UI
Outreach page flow
Knowledge (administrative team)
Onboarding materials
Support / Tutorial text in the application site
Features (dev team)
Indicator for New or Reply
Default editable and extendable permissions controlled label set
Summary note at the top that anyone can edit.
Team ability to take notes on a case thread with author identification
Heads Down, Get To Work
Sketches & Wireframes
As Joan and I transitioned into designing the Freedom Signal layout, we decided to divide our work in order to meet the short timeline to prepare for user testing. Joan would begin sketching for the Outreach and analytics section, and I took on the inbox, along with the case fIle/conversation sections of the interface.
Building Our Asset Library
Working Collaboratively
To get in a flow together on Figma, Joan and I began building our asset library to ensure the testing wireframes had consistency regardless of their fidelity level. Joan's strong background in visual design was instrumental here, as you can see the standard assortment of text styles and gradations allow for flexibility without distracting the user.
We followed Atomic Design principles to build our components library, starting with Atoms, Molecules, and assembling Organisms before building our pages.
Asset Library - Atoms
Asset Library - Molecules
Asset Library - Organisms
Case File Section Components - Organism level
Figma - Prototype Layout Screens
Observing 8 Users During Testing
Performed on Figma over Zoom
Usability Study Methodology
This usability study was conducted on a clickable medium-fidelity wireframe prototype of the desktop interface for Freedom Signal. Designs and prototypes were built using Figma so that we were able to collaborate in realtime while communicating over Zoom. Together, Joan and I used the Magic box scenarios to create tasks for users, ranging from simple navigation to performing specific tasks.
In total, we performed 8 one hour User Tests over a week span, and after each session, Milleigh, Joan, and I debriefed to evaluate the process for design improvements, making iterative changes between morning and afternoon testing.
All testing was conducted through Zoom, by having participants open the wireframe prototype from their own computers, sharing their screens, and perform a few tasks.
Example Tasks
Outreach Tasks
Explore
Create a New Campaign
Conversation Tasks
Reviewing the first-time response for needs, and updating Case File
Transferring/receiving Case File
Understanding existing Case File status at a glance
User Testing Samples
UT Clip 01.mp4UT Clip 02.mp4Surprising Outcome
Clarity is key. I found that setting the scene for the user is really important when dropping them into a medium-fidelity prototype. At this level of detail, users have a lot more visual distraction than I had expected, and any filler text or missing visual feedback left them confused.
While it was really helpful to see my layout through someone else's eyes, I had to adjust my expectations for the tasks requested.
Key Learnings Busted Assumptions
Example 1 : User Eye movement
While there was a variance between existing users and new users, eye movement when understanding the Case File screen was consistently in a left to right pattern, and dividing the screen into the top and bottom sections. This observation of user behavior suggests that the tools in the interface that you most want users to be aware of would need to be in the top left and top center sections of the Case File screen. The tools that users must interact with to perform the core function of the software may be on the right side or the bottom half of the screen (ie. Text Conversations and optional tools).
However, I found that the order of which sections users went to for understanding the victim's needs were different.
User eye movement understanding new Case File screen
Profile Data Section (left top)
Support Needs Section (center top)
Text Conversation (right)
Profile Data Section (left bottom)
Case Notes (center bottom)
User eye movement when understanding victim needs
Support Needs Section (top center)
Text Conversation (right)
Profile Data Section (left)
Case Notes (bottom center)
This observation suggests that the clear title “Support Needs” (item #1) gives the user visual direction that it is the correct area to find the information desired.
The second eye position suggests historical habits, with existing users, of reading through the text conversation (Item #2) to understand the potential victim, even before reviewing their profile.
In future versions of the software, there may be strong value in testing a screen layout with “Support Needs” and “Case Notes” combined into one section.
Example 2: Auto-Populating Profile Data
Surprising Outcome
Users only wanted auto-population of victim profile data from ads (Item #1) if they could edit it after confirming or disproving it with the victim through conversation.
Historically, this has been expressed by users overwriting the phone number in Project Intercept V1 with victim information.
Users also responded positively to having a blank input field (Item #2) on the Profile section of the Case File to add an additional piece of custom information.
Stakeholder Presentation
At the conclusion of this project, we again assembled the entire team from Seattle Against Slavery to present our findings. This presentation provided an overview of phase 1, the results from the user testing, and usability recommendations for future releases.
Project Success
Outcomes & Reflections
Feedback After Release
Joan and I were invited back for a Freedom Signal 2.0 premiere in mid-December to see the end result of our work. We were both pleased to hear customers who had been migrated over to the new version gave excited reviews, commenting on how the software felt more robust while also simpler to use.
Professional Recommendation
"Justin is a fantastic UX professional who helped my small team develop our first framework for UX and understanding our users & their needs. Justin was part of a months-long UX research project along with his project partner, Joan, and together they helped our small engineering team in a crucial growth period. Justin and Joan researched our users, conducted countless hours of interviews, developed user personas, as well as wireframes for new features, which they also tested with our users. They gave us valuable learnings and a foundational framework of understanding our users that we carry into our future work. I was very impressed with their thoroughness, professionalism, and commitment!"
-Liz Rush,
Technology Director
Seattle Against Slavery
Reflections
At the beginning of this project, I had been in search of a nonprofit in which I could invest my time and grow my skills as a UX professional. I had not expected to become so impacted by this cause and the valuable work Seattle Against Slavery is doing. Having originally committed to 10 hours a week, I quickly realized the volume of work I had agreed to far surpassed those hours. As the weeks grew longer, I found myself even more committed to delivering the results needed to impact this product.
I feel that during my 3 months working on this project, I helped to establish a culture of UX research and design for the Freedom Signal team and laid a foundation through leadership and sharing the guiding principles of the UX design philosophy.
During this time, I learned the importance of attaining stakeholder buy-in, the value of investing the needed time in communication to guide the team through user interviews, research debriefs, ideation workshops, prototype iterations, and usability testing. I am also very thankful for the valuable insight and guidance from several UX mentors throughout the process that guided my approach.
If I were to do it all again... I'd definitely use Microsft Word to transcribe the interviews to text!
View Phase 1
Facilitating user interviews, data analysis, behavioral personas, stakeholder presentation and report
My sincere thanks for all the support and feedback to make this project happen.
Thanks go to the users and participants that graciously took the time to do user interviews and usability testing.
The staff at Seattle Against Slavery:
Liz Rush., for entrusting us with your software and your user base.
Milleigh Vo., our project manager, that organized everything and was with us every step of the way.
Pete Dunlap and Lucy Waggoner for giving us the fantastic experience of working with awesome developers.
Mentors that shared their time to and knowledge of user experience and user research industry standards.
Ian Wyosnick - Senior Researcher at Smartsheets
Amanda Menking - Director at University of Washington, MHCI+D
Jeroen Bet - Associate Strategy Director at Smashing Ideas
And most of all, Joan Williams, my incredible UX co-designer on this project.
Page updated
Google Sites
Report abuse