ONE O'Reilly mobile apps
Android and iOS
Allow customers the opportunity to grow their careers through online learning and conferences by unifying the two sides of our business.
Becoming ONE O'Reilly
A large chunk of my work for O’Reilly has been focused on merging our learning platform app with our conferences. Up til that point, the two sides of our business had remained largely separate.

The conferences side was using a generic third-party app that had been customized for each conference. The experience was lacking in the types of features available and there wasn’t a way to link to our platform content.

A sizable percentage of our conference attendees were unaware of our learning platform offerings even though they received a trial subscription with their event registration. Attendees weren’t activating them, because they didn’t see the value.

While on the platform side we had the reciprocal problem—our users weren’t registering for conferences.

To both increase subscription conversions and increase event attendance, we decided to cross-promote our learning platform with our conferences in one app, which allowed us to also merge our user base.

Defining Our Users
The user scenarios were quite a challenge because there were endless possible combinations that different types of users could experience. For example, there could be a conference attendee that had attended past conferences, but it was their first time activating their learning platform subscription therefore they didn’t have any learning activity to show.

While on the complete opposite end of the spectrum, there were users who had been long-time platform subscribers with hundreds of items in their history, live online trainings they had taken, etc. but they had never registered for a conference.

My job was to figure out who those users were and what all of those potential scenarios could be in order to create a tailored flow for each one.

I narrowed it down to the 10 most common scenarios for both events attendees and platform subscribers, and then got to work figuring out each user’s journey through the app from whichever starting point they were at.

Figuring out all potential user scenarios

An incredible amount of coordination happened between myself, my PM, our mobile engineers, the conferences team and the events engineering squad.

Once stakeholders—the Senior VP of Conferences, the Director of Marketing, and the VP of Sales became involved, there was a huge increase in communication. We held biweekly meetings dedicated to figuring out our value proposition, the features we absolutely needed to launch an MVP, and all of the backend constraints while I was working through the IA, user scenarios and visual design.

Wireframes for iOS MVP

At the same time all of the UX work was happening we were working on the backend to merge our user bases so we can use unified authorization to allow any type of user to sign in to the app and it will pull in their corresponding activity from the api. The engineering lift on this involved multiple teams and was so heavy that it sidelined the majority of other work.

The timelines for when the stakeholders expected to see designs and when unified auth would be ready did not match up, so we decided to release in stages.
The Process
Like most projects, this began with an enormous amount of research into best practices, user analysis, competitive analysis and heuristic evaluation of what wasn’t currently working.

This led to a cycle of initial wireframes, bare bones prototyping and testing until we were happy with the experiences; working in tandem for both iOS and Android.

Our MVPs were basically simply getting a viewpoint for conferences in our current iOS and Android apps. Users could access the list of upcoming conferences from the Discover screen.
The next release, we worked on creating basic conference schedules and speaker & sponsor screens within the app. It was the beginning of establishing our app as a guidance tool while attending a conference.

In Fall of 2019, my product manager and myself traveled to our Artificial Intelligence conference in New York City to beta test the app with actual attendees. At one point, I sat in a room with an Android engineer and made changes on the fly while mid-conference.
By Phase 3, we started to allow users to create their own personal conference schedules and save them locally to the device. This was the first step towards customization.

I created a “Your O’Reilly” dashboard as a home screen from which the users could immediately access all content personal to them: books and videos they had started, trainings they were taking, conferences they were attending, etc.
Your O'Reilly on a Galaxy S7 Edge
Your O'Reilly on a Galaxy S7 Edge
Your O'Reilly on iPhone XS
Your O'Reilly on iPhone XS
In Phase 4, we added in requested features from stakeholders like the ability for a user to request a meeting or demo with a conference sponsor, a huge selling point for conference sponsorship.

Sponsor meetup request feature for iOS

My next task was to design a messaging system and notification system to enable communication between all conference attendees, speakers and sponsors.
Android messaging and notifications system
At this point we were able to launch unified auth, meaning we could cater the app experience to the individual.

It was all falling into place, until it wasn’t…
The Results
The conferences app work ran over the better part of a year and a half. Then in March of 2020 with COVID-19 spreading, we were forced to cancel all upcoming conferences.

That side of the business was under a microscope and was re-evaluated extensively until it was decided to completely close-down the entire in-person events business.

The focus was shifted back to only the learning platform to try to make up the lost event revenue, with the anticipation of pivoting to online conferences.

Looking back, if I could change anything I would change the approach to that project. Even though it was a long-term project it always felt very rushed, like we were pushing to meet roadmap deadlines and impromptu stakeholder requests. I think that greatly affected the overall scope of the project.

An undertaking of that magnitude should be thoughtfully planned with respect to the bandwidth of every team involved. That didn’t happen. There was a lot of go, go, go and we’ll figure it out later. That affected our ability to test as often as I would have liked.

You may also like

Back to Top