Girl Scouts | Volunteer Systems 2.0 Redesign
Girl Scouts of the USA (GSUSA) had engaged an outside vendor to re-platform their system for registering and renewing members, as well as managing event registration and account preferences. They also needed to update the experience to integrate best-in-class eCommerce solutions, and best practice user experience standards both in terms of usability and accessibility.
Project Summary
Overview
Girl Scouts had a collection of software solutions to manage not only its member registration and event management solutions, but also disparate and duplicative storehouses for its people data, often employing third-party solutions for registration, event and people management that did not talk to one another. This led to duplicate emails and inefficient, patchwork solutions that did not convey a single, unified entity, calling for the need of a branded, functional and scalable set of components for use across national and council products.
My Role
Lead UX/UI Design stakeholder for project, responsible for overseeing the work of an outside team of UX/UI designers provided by a vendor partner, ensuring that flows, wireframes and interaction design conformed to industry best practices and upheld the level of quality Girl Scouts expected in a digital experience. UX Lead involved in acceptance testing, workshops and iteration, as well as Lead Evangelist when it came to ensuring design and functionality was satisfied across other streams of interconnected product work happening within Girl Scouts. Responsible for spearheading, researching, building and maintaining a piloted, robust set of accessible components —the first Girl Scouts product design system—to be evangelized and applied to other products in the Girl Scouts digital product ecosystem.
A federated model of disconnected systems.
Though I came into the project after the Discovery phase, I reviewed all documents gathered by the Business and vendor, audited the original Volunteer Systems (1.0), and visited my local Girl Scouts Council (Girl Scouts of Northern New Jersey) to interview the Council CEO and Marketing/Website stakeholders about their current tools.
Key insights included:
1. The first Volunteer Systems was built on a separate platform, Force.com, which opened the registration system in a new browser tab when accessed on council websites (users could not directly register as a member or sign up for an event through the national site—everything had to happen via Council website or Council calendar.). For events, most Councils were using third party websites or solutions such as Eventbrite and Doubleknot. All of those solutions required staff to copy and paste people data (names, emails, etc) from one solution to a central database, which meant data was often duplicated or lost between solutions.
2. Girl Scouts of Northern New Jersey, like many councils, was not able to access Volunteer Systems at first, which is what led their staff to adopt third party software. Once those solutions were instituted, Councils were loath to abandon them. This contributed to a proliferation of secondary sites and destinations that did not look like or function as if they belonged together.
3. Staff, Councils and volunteers wanted a single source of truth for data management and had identified Salesforce as the tool to use. They also wanted a single transactional system for events and registration, and to employ a Single-Sign-On (SSO) solution for users to access not only their Girl Scouts account, but also a list of events, troop data and more without having to sign into multiple solutions with multiple passwords.
4. Staff and Business Leads requested the new system accommodate mixed carts, in which users could purchase both memberships and events during a single transaction.
5. Whichever solution was decided upon had to be mobile responsive. Volunteer Systems 1.0 was decidedly not responsive or mobile-first, and neither were many of the third-party solutions being used by Councils.
Our technical development team proposed a solution to leverage Spartacus (a headless commerce solution) for the front-end of the new Volunteer Systems (2.0), layered on top of Salesforce for people data and SAP Hybris and Oracle Netsuite for transactional data, with SAP Gigya handling SSO.
Better understanding our service and its volunteers.
Another helpful exercise for letting me understand our volunteer needs and those using the Girl Scouts service was participating in and co-leading a Volunteer Service Design Workshop during the first two months of my tenure at Girl Scouts. Collaborating with stakeholders from the organization's Volunteer community, as well as a Customer Experience lead, we used affinity mapping and card sorting to define our service, the products and benefits Girl Scouts of the USA offered to Council staff, volunteers, parents and girls—and what they offered back in return. The two-day workshop was hugely successful and resulted in us walking away with a Service Design Ecology map that is now being evolved into a clickable prototype.
Defining systems for, well, the system.
My research complete, I plugged in with the vendor's UX team (a UX Lead, two UI Designers, a Visual Lead) alongside a new GSUSA Product Manager to swiftly realize that no one had provided them a set of breakpoints for the new product or a review/approval process for its design artifacts. Until that point, User Experience and Product Design at Girl Scouts of the USA was seen strictly as UI or visual design without a clear, accepted and adopted UX process; usually, GSUSA relied on a vendor partner to define that. With an in-house Product team, GSUSA was in the position to finally define process and standards for the first time, and that meant we could use Volunteer Systems as the first project through which to educate and evangelize common UX/UI best practices and processes the organization could leverage for their digital products.
To start, working with the Product Manager, I defined a set of common breakpoints for GSUSA products, as well as a basic review and approval document for both internal and external projects, providing the breakpoints and the latter review process document to the Volunteer Systems vendor.
Additionally, as our team had been planning to create and maintain a GSUSA components library separate from this project—Girl Scouts of the USA's first product design system, to be named "Campground"—we agreed to use the new Volunteer System's functional components as a way to pilot it. I communicated to the vendor that while functional design would be defined by the product requirements, impending flows and wire-frames, all visual design would stem from the in-progress design system, a product I would spearhead and collaborate upon with GSUSA's brand owners, the national Marketing Communications department (Case Study for "Campground" coming soon to this portfolio.)
Many users, a single system.
Having worked through GSUSA's Service Design Ecology in the aforementioned workshop, I was in a perfect place to understand user personas for which we'd be designing VS2, and how each of them would be journeying through the system.
1. GIRLS and CAREGIVERS Parents, but also guardians that fall outside that label) were our key user persona. Girls had to belong to a parent/caregiver's Household account until they aged out as an ALUM, and then could have an account of their own. Girls and Caregivers had to be Girl Scout members and were not subject to a background check..
2. VOLUNTEERS ran the gamut between unaffiliated adults (without girls in Girl Scouts), Girl Scout Alums and Parent/Caregivers. Types of volunteers include Troop staff (Leaders, Co-Leaders, Cookie Chairs, etc) and Episodic Volunteers (volunteering for a single event, for example.) Volunteers had to be Girl Scout members and were subject to a background check.
3. MEMBERS were adults that simply wanted to belong to Girl Scouts without volunteering, whether or not they had a girl. Adult members were not subject to a background check unless volunteering.
4. NON-MEMBERS were adults that simply did not want to belong to Girl Scouts, but wanted to attend events that include non-member status, whether or not they had a girl.
One of the key considerations I wanted our team to keep in mind was the taxonomic difference between being a Girl Scouts Member and having a Girl Scouts account (in Volunteer Systems or on a Council website.) A user could have a Girl Scouts account without being a Girl Scouts Member; a user could not be a Girl Scouts Member without having a Girl Scouts account. This clarification would become very important not only for event pricing, but for personalization, member access and adding people to a user's household or to an event.
That in mind, we split the Volunteer Systems product into four unique sprints and began crafting user flows and wire-frames for each:
1. REGISTRATION: The process by which girls and adults sign up for a Girl Scouts membership, find a troop, create a troop or volunteer..
2. RENEWAL: How Girl Scouts Members renew or upgrade their membership, renew volunteer role participation and/or troop participation.
3. gsEVENTS: The process by which members and non-members can search and register for physical and virtual events by a particular council and register for camp.
2. ACCOUNT PROFILE: The hub through which account holders can manage their Household, Troop or Volunteer involvement, membership and events. Also where users can manage any outstanding payments or search order or event history.
Key challenges and solutions:
1. One of the largest flows we had to think through was how to create a mixed cart from Troop and Event Search, allowing users to combine both into a single transaction. We landed on a tabbed Search UI that allowed the user to toggle back and forth to define parameters for both searches, and then apply separate filters once within the Search Results screen by toggling, as well. Tapping the secondary button at the bottom of the results let the user jump back and forth between searches, too, and tapping the primary button there or in the mini-cart on the side let them log in and begin adding details.
2. Retaining a robust results/map experience on mobile, where screen space was limited, was a second challenge. Together, our vendor and internal Product team researched real-world mobile search results and map experience from Google Maps, Home Depot, Target and other big box retailers. Rather than present troop and event search results as a single scrolling list of divided text, we decided to run with a modular, card approach to presenting information across the experience, allowing cards to reflow between breakpoints. Rather than leave results as a paginated vertical list on mobile (as it was on desktop), the first six results cards were presented as a horizontal carousel (in which the cards could be expanded or collapsed, depending on the user's desire to see more details or see the map experience), after which a user could tap into a scrolling list of cards with incremental loading at the bottom.
3. The original plan was to incorporate volunteer roles into the standard adult registration flow...but the Business had concerns that Council used different descriptions for the same volunteer role (i.e., Girl Scouts of Greater New York described "Cookie Chair" differently than Girl Scouts of Heart of California), and so we would not be able to apply a "one size fits all" approach to role descriptions. Our solution was to build a dedicated flow specifically for volunteers, dynamically adjusted to whichever Council the user was affiliated, allowing for expanded details, horizontal scrolling/swiping through expanded role cards, and the ability to quickly add multiple volunteer roles to a user directly from their Member account.
4. The biggest contribution I had was being able to leverage my background working on B2B and B2C eCommerce solutions to apply transactional best practices to the Checkout flow. This included adding a mini-cart/cart summary; a progression bar to set progress expectations and allow a user to return to previous steps; employing expandable/collapsible drawers for each item in the user's details and cart, incorporating progressive completion where as a user filled out details for an item, the system collapsed said item and then opened the next, moving through all items in the cart; allowing the user to dynamically add existing/captured data from their account (name, address, email) to forms, eliminating the need for users to retype information multiple times; dynamically updating totals and subtotals and providing success and error messaging for required fields; traditional credit card features such as additional billing address, UX messaging about security and CVV, and hiding the user's credit card number.
Key challenges and solutions:
1. The main consideration for designing the renewal flow was to establish top-down levels of renewal to make clear to the user which option, when selected, might affect the tier below. For instance, a user could select and renew a Girl Scouts membership (top level) without selecting a Troop membership or volunteer role below (second or third level, depending.) But selecting the Troop membership ALSO selected the Girl Scouts membership because the second level was dependent on the first.
2 Additionally, we provided sticky call to action buttons, proper status taxonomy ("awaiting placement," "active member", etc.) and clearly defined system messaging to ensure users understood how to renew a membership or role, where they stood in that process, and how to move forward.
Key challenges and solutions:
1. One of the main obstacles we faced for the new events registration system was managing stakeholder expectations and hesitation towards change. Stakeholders requested a calendar interface, similar to what they used at their individual websites for local events. The final solution for the new events registration system was to leverage a scrolling list of cards keeping consistent with the treatment used for Registration. The reasons behind this amounted to:
- Complexity and Scalability: Due to the volume of results that might be displayed on the gsEvents results page (though each member may search per zip code or council, adjusting filters could widen that search to a regional or national number of events), it would not be feasible to display events results within a calendar interface. Due to the lack of real estate offered by a calendar interface, the results would become overwhelming and pertinent information would be lost. In place of a calendar interface, we chose to implement a list pattern utilized by industry leaders that present event results at scale (Eventbrite and Ticketmaster).
- Loss of Map/Location Functionality: Utilizing a calendar view would not allow users to access the map displaying the location of the results in relation to each other.
- Creating Consistent Search Results Patterns: Given that troop and events search results are present on the same screen (separated by tabs), we wanted to create a consistent search results pattern for our users to reduce friction.
Ultimately, we helped satisfy the expectations for both Business and Councils by assuring them that while we would retain the calendar interface for local events on Council websites, the above reasons meant that gsEvents would retain the scrolling list of modular cards.
2. We spent a lot of time outlining the aforementioned difference between Members/Non-Members and Logged In Account Holders/Not Logged In Account Holders, particularly in terms of managing pricing tables and for which events a user could register (Members Only, say.) Adding the pricing table made it clear to users what they were buying and what they would be expected to pay. Additionally, it helped work through how a Member might invite other Members or Non-Members not in their household to said event (say she wanted to invite her daughter's best friend to an event, whether or not the best friend was a Girl Scouts Member. Or if she wanted to invite grandma.)
3. We also worked through status messaging for events, and how product detail pages would adjust to reflect events that were Active, Coming Soon, Canceled, Virtual Only or Waitlisted. The UI and components would dynamically adjust or be suppressed based on the number of available spots and changed status.
4. Concerned that exposing the location of the event might attract the wrong element, we approximated the location of the event (unless it was a public, third-party event) and presented it to the users in event details housed within their Account profile following a completed registration. We chose this same solution for Troop meeting locations when a user registered for a Troop..
5. We leveraged the capabilities of SAP Hybris to allow users to purchase additional items within an event (sessions, merchandise, activities) that would be dynamically added to their order invoice.
Key challenges and solutions:
1. The main challenge when setting up the user's Account/Member Profile was that of taxonomy and organization, figuring out which data elements to show on her main Account hub, the various tabs beneath, and which actions could be taken by a user at each level of the overall profile.
2. Because the scope did not include a redesign of the header, we needed a secondary navigation for the Account hub, to allow a user to jump between Household, Troop, Events and more. A dropdown field was placed at the top of the mobile experience, while a left-rail was added to Desktop. This secondary navigation will be folded into the global navigation for GirlScouts.org during the UX/UI work on that project stream.
3. Other features added to the design of the Account/Profile included allowing users to search, sort and filter past and upcoming events; pay off balances via toast messages or within the event detail itself; apply for volunteer roles directly from an existing Troop without having to perform a search; split a household; and assign additional caregivers to girls within their household.
4. Earlier in the project, the Business asked for a higher-level portal named MyGS into which elements from the Volunteer Systems Account hub would feed and dynamically update, along with key data from other Girl Scouts volunteer products such as Volunteer Tool Kit (resources for troop leaders, managing troops and meetings), gsLearn (online videos and training resources) and Digital Cookie (individual cookie sales for girls and troops.) My role was to design the proof of concept, working with an outside experience consultant and the technical leads for VS2. While this experience may still be leveraged post-launch of Volunteer Systems 2.0, for now it remains a concept and the Account/Profile hub for VS2 remains the main destination page for specific Household and Member information.
Testing and iterating within our household.
Liaising with our Business Leads and establishing a cadence of review and approval critiques (in person and remote), I partnered with our Product Manager to finalize and approve VS2's user flows, wireframes and visual designs (based on the application of our piloted system of components.) Once handed to the vendor's development team, I shifted my participation into the role of GSUSA's UX stakeholder during a set of four week-long user acceptance testing (UAT) cycles, the first two of which were in person, the second two remote due to COVID-19. The sessions involved a specific number of Council leaders (a "Council Action Team") to work through testing scenarios, identify bugs and opportunities, and create a backlog for the developers and designers from which they could iterate. My role was to weigh in on UX/UI requests and in some cases, partner with the vendor's UX design team to rapidly create new solutions which were then tested and approved based on stakeholder feedback.
Unity and cohesion for a community with a mission.
Creating a singular platform for tasks and journeys that were once parceled out to disparate pieces of software, Girl Scouts of the USA's new system of record provides a one-stop-shop for girls, volunteers and caregivers to access not only membership details, volunteer roles and event management, but eventually merchandising and personalized growth and training opportunities. Without having to leave the Girl Scouts digital ecosystem for other third-party solutions, girls and caregivers will be able to start, renew or reinvigorate their Girl Scouts experience through a frictionless, usable and responsive experience that looks and functions the same across both national and Council websites.
