Work - Pivoting in a pandemic
Pivoting in a pandemic
Description
In March 2020, everything changed. I was working at a company whose business revolved around in-person events. I was leading the design of a native mobile app for attendees to use to find their way around, build their schedules, and achieve their event goals. Part of that product offering included a content management system event planners used to build their apps and customize them for their events.
No more in-person events meant a quick pivot to virtual. We scrambled to release a virtual event attendee website, where event-goers could attend sessions safely in their homes. Once we had launched our first version of the virtual site, our eyes turned to the planner side. The content management system was designed to build a mobile app, and we had quickly tacked on the virtual website as part of the product offering. We needed to make some changes to satisfy our customers and give them confidence in what they were building and releasing to their attendees.
Task at hand
We knew this was going to be tricky, because our industry was quickly changing and we were learning as we went. Our biggest challenge was how to communicate what the user is building and prevent duplicative tasks, while instilling confidence. We identified the following as our biggest challenges:
Our planners are venturing into the unknown; we need to educate them and define the utility of the website and mobile app.
We knew there was some existing confusion around publishing, and that each platform (website and mobile app) needed to be able to be published independently.
Lack of feature parity between the website and mobile app for an unknown amount of time.
Discovery
We began by conducting an analysis of our current systems and the event planner user journey through them. We worked with product to map out what we knew was upcoming with the virtual website and began conversations to understand how that connected with the existing mobile offering. We were working with a lot of unknowns, both on this project and in our lives.
Concept design
During the discovery process, we identified five different approaches we could take. While the company’s primary focus was on delivering the attendee-facing virtual website experience, we knew we were going to need to handle this project a little differently than usual. We decided to take our strongest approach, and create a high level concept to see how it resonated with users.
Wireflows for our concept
Concept screens for planner interviews
Principles of the concept
Educates on the utility of the Attendee Hub website and mobile app, and guides through set up, if needed.
Allows for setup of both platforms simultaneously.
Pages and content can be shared between platforms, or not.
Page preview provides a clear indication of what you are working on, and further educates on utility and functionality.
Concept testing
Our research team set out to understand how well the concept meets planner's needs and solves our problem statement: How might we clearly communicate the relationship between the web and app experiences and prevent duplicative tasks while allowing the planner to deliver engaging experiences to their attendees?
Wins
12 of 12 found the page preview capability "very useful"
Overall concept of building cohesive web and app experience once without duplicative efforts
Flexibility to create web-only or app-only pages
Flexibility to launch web and app independently
Recommendations
Consider more holistic organization of Pages to match planners' mental model "web and app are similar experiences"
Consider enterprise clients' customization needs
Stakeholder buy-in
We were pretty excited - our concept resonated extremely well with users and we felt confident in our approach. Now that we more clearly understood which direction we could take with our design, we pitched the idea to stakeholders. We were met with a lot of agreement in our approach with one potential caveat: the in-page static preview, which we were calling the “backbone” of our concept, looked expensive. We quickly put together some ideas for how the in-page preview could work, and met with the development team to discuss. We learned what we had feared. With the way our backend data is architected, generating the in-page previews in our design concept wouldn’t be technically feasible. We were crushed, but viewed this as just a roadblock. How would we be able to overcome this technicality, and still solve our problem statement? We went back to the drawing board, but armed with stakeholder, development team, and user feedback to iterate on our idea.
Concept pivot
We knew the main area we needed to address with our newly found insight was the pages area. Without a preview to communicate the structure of the website and app, we needed to do it with how we grouped the setup of the pages. Above, we explored several ideas, and finally landed on the direction of the one in the bottom right. We tested that direction with planners. It didn’t test as well as our initial concept, but we could fix some problem areas and move forward with it. One thing to note that we went really well during this testing session was iterative prototyping. We learned pretty quickly that there were a few key areas in the design that just were not resonating. We had previously explored other design ideas for these areas, and collaborated to change the prototype from one test to the next, often working within an hour to update the prototype between sessions. By doing this, we were able to get the designs to a place we felt comfortable moving forward with.
Where we landed with the pages area
Next steps
With the pages area nailed down, we have begun to explore other areas within the builder to unify the builder experience. We’re working closely with product to plan how to break down this large-scale project into smaller chunks and get those pieces on to development teams. As the virtual product offering continues to evolve, we work with other designers and product teams to educate on the plan for this structure to scale.