In the initial stages, I facilitated a workshop with the team to generate a wide range of questions pertaining to the product. We drew upon our collective understanding of the existing product and explored how it would function within a virtual context.
I conducted an in-depth analysis of the customer journeys for our two user types, identifying specific touchpoints to focus on. My primary objective was to ensure that the user experience remained relatively consistent and familiar, with minimal disruption to what users were already accustomed to.
Introducing this feature necessitated careful considerations across multiple aspects of our system, including the internal administrative tool, the customer dashboard, the guest-facing check-out process, automated emails sent to both guest and customers, as well as a web portal utilized by external instructors.
We faced the crucial decision of defining the ownership structure for video conference accounts: whether they should be owned by AnyRoad, the partners, or the teachers. This choice had far-reaching implications for various UX elements. Some argued in favor of AnyRoad owning the accounts to streamline training, gather more data, and enhance security. Conversely, others advocated for a hands-off approach to minimize management efforts, reduce costs, and mitigate additional liability.
In the end, we opted for hosts to have ownership of their own Zoom accounts, although our initial approach differed. We concluded that, for a small sample BETA, it made more sense for us to take ownership of the Zoom accounts, allowing us full control and enabling us to gain firsthand insight into what partners would otherwise be managing. I strongly advocated for this decision, particularly for research purposes. However, we quickly encountered scalability limitations and unanticipated shifts in Zoom's security policies.
Up to this point, our system was intricately tied to physical locations, impacting various aspects such as maps, displayed locations, timezones, scheduling, bookings, calendar views, and more. However, transitioning to an online experience posed a unique challenge. To address this, I explored several ideas aimed at minimizing development time, rigorously testing each concept with relevant team members.
These ideas included:
• Utilizing a physical location while concealing any addresses from the consumer UX.
• Crafting custom locations using a physical address in each timezone, accompanied by distinct names such as 'Online – Eastern Time.'
• Generating unique 'fake' virtual locations when creating an experience.
After numerous iterations and discussions, I successfully advocated for the allocation of engineering resources to create a new experience type that would no longer rely on physical locations.
Given our existing email system, my initial inclination was to incorporate the meeting link directly within our automated emails. This approach offered the advantage of relatively low development effort while providing users with convenient access to the link within their email inbox. Additionally, it appeared to be a straightforward UI design endeavor.
However, before proceeding, I conducted thorough research by examining expert event hosting platforms, including EventBrite and Airbnb, to gain insights from real-world practices. Furthermore, I leveraged insights from our manual stealth BETA phase to evaluate link usage behavior during setup and execution. During this analysis, I pinpointed a significant pain point: the need to update meeting links. Embedding direct links within emails introduced the challenge of ensuring that users always had the most up-to-date link, necessitating additional communication.
To address this issue, I made the strategic decision to design a new landing page, guaranteeing users a consistently valid link to their virtual experience.
