BBC | 2022
A new way for watch party users to safeguard and manage the data they collect along the way.
I stepped into the UX Designer's role overseeing the UI during their absence.
The designs were in the early stages of development and I worked in a multi-disciplinary team to make improvements.
When personal data is used to deliver rich, personalised services, it's not always clear to users how their data is collected and what happens with it.
Some organisations, like the BBC, have been exploring human-centred alternatives, including Personal Data Store technology.
A Personal Data Store is decentralised to store data securely.
Users would have increased visibility and control of their data. They'd decide who could access it to protect their online identity.
To improve practices around personal data, we needed to understand the value to users.
A pilot would demonstrate the capabilities of using Personal Data Stores to that end.
How might we enhance a BBC service safely and securely with a Personal Data Store?
A watch party service called BBC Together, was adapted to work with the current version of Personal Data Store technology (from Inrupt).
My understanding of the work to date was built through active listening and reading documentation.
To contribute effectively, I wanted to understand:
- User needs
- Technical constraints
- Stakeholder requirements
- Time limitations
This project formed part of a wider initiative to inform large scale change.
It was essential that the pilot fulfilled user needs, but we also needed to consider:
- Public interest
- Business needs
As a public service, the intention was to influence policy and legislation to improve industry standards.
Informing policy required insight into how the concept would benefit the public as a whole. Including the feasibility for both audiences and service providers to adopt the approach long-term.
Similarly, to commit to further developments, the BBC needed insight into the value for audiences and to understand the potential for scaling up.
The pilot would act as a proof of concept to stimulate progress across portfolios.
Insight from users would be fundamental to developing standards in the public's interest.
Previous research found high-level value in the concept and technology.
This pilot would allow users to determine tangible value by exploring some of the features in more depth.
The pilot was aimed at a watch party audience.
Aggregated insight from surveys indicated the audience at the time was predominantly under 35.
We also knew that specific types of content (like stand-alone entertainment and drama) had higher rates of shared viewing.
Understanding the user needs around watch parties formed a large part of initial research objectives.
I joined this project while a draft version of the pilot was being built. The plan was to iterate on the designs and prepare for in-depth research.
We explored two work streams:
- Improvements for the build
- Aspirational features for broader research objectives
The designs would be tested with the audience through an online community and a series of moderated interviews.
A core architectural challenge was in developing an experience for two disparate services:
- BBC Together (a watch party service)
- Data Pod (for managing your data)
The team identified two points of friction:
Setting up the Data Pod dominated the start and disrupted the flow.
During testing, participants were deterred from using the pilot.
In the navigation, access to the Data Pod was discrete and often overlooked.
A tooltip highlighted the Data Pod on entry, but:
Overall, the risks included a lack of insight regarding the Data Pod, which was critical for achieving core objectives.
After analysing the designs, it was clear there was a wider issue in the general hierarchy.
The hierarchy was built for BBC Together, and restricted Data Pod content.
Any focus on the Data Pod would seem out of place in a hierarchy built for BBC Together.
To understand the existing approach, I looked at:
There was a desire to convey ambitions for the technology, but there were limitations.
In the future, the Data Pod would be a separate product from the watch party service, which wasn't possible for the pilot.
A separate product would be dedicated to meeting user needs that the pilot's hierarchy was restricting, including:
The pilot's hierarchy wasn't built for the Data Pod as a product, but the pilot still needed to meet the needs of one.
Access to the Data Pod needed to be clearer in the navigation without deterring watch party users.
Criteria for success included:
Testing the designs in research would allow us to gauge the response, and inform the live experience.
I analysed the architecture of similar utility services (like password vaults and cloud storage systems).
I also looked at the requirements for the navigation from a content and technical perspective.
By mapping the content structure for the navigation, I could determine where a Data Pod service could belong.
The result was a more balanced structure to give both services room to serve their distinct functions, while sharing the same interface.
Taking the Data Pod out of BBC Together also reduced complexity by removing a layer of navigation.
The Data Pod was the focus of research objectives, but needed to remain unobtrusive to the watch party experience.
The visual style and mechanics would convey the level of importance.
I looked at how users currently moved between services and accounts by identifying patterns in streaming services, social media, and operating systems.
I also received regular feedback from the team.
There were several options to consider for the interaction. Including:
I also looked at previous designs including a side drawer.
To improve access to the Data Pod, I proposed we introduce a second logo to create a new top-level navigation for the pilot.
A logo for the Data Pod (located next to the BBC Together logo) would:
The main concern at this point was in breaking a familiar interaction pattern.
Overall, the proposed solution was well received and we decided the concept was developed enough for testing.
Insights from research would help to improve the designs going forward.
I noticed the name of the pilot, 'BBC Together', didn't align with the new balanced navigation and copy.
Choosing function over form, I proposed changing the name of the pilot to BBC Together + Data Pod.
Several names had been explored in the past - but the team learned that:
We decided to test the new name in upcoming research.
At this point we had changed the copy, name of the pilot, and navigation.
The outcomes from moderated research indicated an improved awareness and understanding of the Data Pod. But there were opportunities for improvement.
In the navigation, the ability to interact with the logo was unclear. And although there was some improvement, the Data Pod set-up process was still deterring participants.
We re-designed the set-up process with a content-led approach. And for the navigation, I continued to develop the interaction states.
To improve the navigation, I explored several interaction patterns and states including a switch, buttons, and tabs.
All the options I presented to the team were seen as an improvement, but the tabs were considered the clearest.
No issues were revealed in subsequent research and the tabs were used in the final pilot.
The User Researcher and Content Designer analysed insights and stakeholder feedback to determine the structure and content for the set-up process.
For the visual design, I considered two potential approaches:
- Giving both services equal weight
- Leading with BBC Together, with some weight to the Data Pod
I collated sketches and mock-ups as a starting point.
Analysis outcomes suggested prioritising BBC Together.
I created BBC Together branded screens with Data Pod branding where appropriate.
The changes reduced complexity and prevented the Data Pod from overwhelming the set-up process.
In the initial designs, information about the Data Pod overwhelmed the introduction.
Following the changes, BBC Together was more prominent, but there was a lack of information about the Pod.
The plan was to create a discrete explainer module to inform users about the Data Pod.
Following several iterations and rapid testing, the pilot went live with a much shorter and balanced set-up process.
There were two entry points aimed at different mindsets:
The direct entry points to the pilot prioritised BBC Together and a watch party audience. And there was an optional explainer for anyone curious about the Data Pod.
There was a second entry point through BBC Taster - a platform for experiments.
The Taster audience was more likely to have an interest in the technology. Information about the Data Pod was more prominent on this screen.
Rapid testing indicated the solutions for the set-up process and navigation were significant improvements.
The changes alleviated frustration and understanding of the Data Pod improved.
Communicating the value of a Data Pod succinctly continues to be a challenge, particularly in the context of a service. But the Data Pod explainer tested well with participants, indicating a step in the right direction.
Thankfully, many of the structural challenges were unique to this pilot and the early stages of development. The need to balance two services in a single pilot is unlikely to reoccur as the concept scales up.
During a watch party, the user was either a host or invitee.
There were two problems:
- The invitation screen offered the ability to send or receive contact requests, which wasn't technically possible.
- The invitation screen was identical to the waiting area.
By talking to the team, and stepping through the host and invitee journey's, I could better understand the problem.
The invitation was conflated with the idea of a waiting area, but couldn't have the functionality of one.
There was potential for much confusion.
We needed to:
- Align the host and invitee experiences, to allow contact saving
- Create a shared view on entry to prevent confusion
My initial reaction was that the invitee needed a waiting room to align with the host's journey.
However, there were no user needs to justify one.
After discussing it with the team, I chose to explore two options:
- A waiting room for both host and invitee
- No waiting room for either host or invitee
For both approaches, the invitee also required a distinct invitation screen.
I used an empathy map to understand the type of content an invitee might require on a watch party invitation.
Receiving an invitation to a party is usually a moment of joy. I styled the screen with this in mind.
After discussions with the team around feasibility, I sketched ideas for the visual design.
I considered using a simple, quick animation to highlight the moment without disruption. But with time limitations and accessibility considerations, I settled on a simple ticket shape instead.
While adding a waiting area to the invitee journey, I ran into potential friction.
What would happen when the invitee was in the waiting area and the host started the show?
There were two options:
- The invitee could be automatically taken to the streaming area
- The invitee could choose to leave the waiting area
Neither approach seemed ideal. With the first option, the invitee could be taken away in the middle of saving contacts. With the second, they could miss the start of the show.
I looked at potential solutions, including:
If the invitee was automatically taken from the waiting area to the stream, a persistent modal could allow the invitee to finish saving contacts.
However, all the options so far had time restrictions.
To create some flexibility, I looked at adapting the media player.
By adding contact saving functionality to the media player, users could save each other as a contact any time during the watch party.
After adding a waiting area to the invitee journey, the host and invitee experiences were more aligned.
For the alternative journey (without a waiting area), I moved all the functionality in the waiting area to the side panel in the media player.
Without a waiting area, users would go directly to the streaming area.
They could invite people and change their preferences anytime during the watch party, without having to leave.
To invite people to the watch party, the host could launch a modal using an 'invite' button available only to them.
I added programme information and altered the styling of the modal for consistency.
After removing the waiting area, we had a second option for aligning the host and invitee journeys.
The invitation screen was well received and pointed out by several research participants as a positive part of the experience.
As the pilot developed, the screen was simplified and adapted to align with the rest of the experience.
I presented the two options (with and without a waiting area) to the team.
We decided to test the option without a waiting area in research. And with some adjustments, the approach was used in the final pilot.
There were two problems:
- Multiple identities
- No Data Pod identity
There were multiple brands to consider:
Juggling multiple identities was an existing challenge across the BBC. And the addition of the Data Pod compounded this problem.
In the original designs, the Data Pod didn't have a brand identity. The global BBC brand was used to fill the gaps.
Without a clear ability to identify the Data Pod, it couldn't be evaluated effectively by users.
To aid recognition and prevent confusion, we needed to:
- Shape the brand identity for the Data Pod
- Apply the brands consistently
To develop a brand identity for the Data Pod, we leveraged a toolkit of illustrations.
The toolkit was commissioned specifically for communicating the future of data stewardship.
I took elements from the progressing Data Pod designs, and used the toolkit to develop the brand identity.
As the team developed the Data Pod screens, I combined the logo they used, with the illustration style.
The background colours for the Data Pod were established, but the palette was missing a highlight colour to aid recognition.
I considered blue tones for the Data Pod, to create some distinction.
After concerns were raised around the stereotypical use of the colour blue with new technology, I switched to the warmer palette used in the illustrations.
After testing different colours for sufficient text contrast, I suggested using the yellow as a highlight colour.
The consistent use of colour provided some familiarity for the Data Pod UI and identity.
While working on a Data Pod explainer module with the Content Designer, I continued to develop the identity.
We prioritised cognitive ease and readability for the subject matter.
The illustrations, bullet points, spacing and layout helped to make the information more approachable.
The original designs used elements of the global BBC brand. The global brand was necessary for certain parts of the experience, such as signing in. For other parts, it was potentially confusing.
I removed the global BBC brand where relevant and worked with the team to apply the appropriate branding throughout.
There were some screens where the appropriate brand identity was unclear. Including when allowing BBC Together access to the Data Pod. The screen went through several iterations.
After I applied the Data Pod brand, the team could focus on developing the content.
I worked with the team to apply developments to the Data Pod identity. We also simplified the content and layout.
I worked with the Producer designing the Data Pod screens to:
- Optimise layouts for development
- Create a consistent menu element
- Apply the yellow highlight colour
During the pilot, users could save each other as contacts, and the Data Pod area provided a list of them.
After working with the Producer to optimise the UI and visual design, we used 'Version 1' in research.
I then simplified the screen for the build in 'Version 2'. At this point, the brand identity had developed further.
Although we needed to maintain separation of BBC Together and the Data Pod, the need for a single promotional image for the pilot was unavoidable.
The promo needed to convey both the watch party and Data Pod aspects - but earlier attempts had swayed in one direction.
I continued to develop the image and introduce more of the BBC Together brand.
I created four options, which we tested to refine.
Most participants found the fourth option more representative of the pilot and it was used for the live experience.
We worked on different parts of the experience in parallel and met regularly for updates, collaboration, and feedback.
As the work came together, I oversaw the integration into research prototypes. I maintained consistency across the UI and visual design, and inserted the appropriate transitions and animations.
I supported research planning by providing feedback and supplying stimulus.
The interactive prototypes were used in moderated research sessions. I supplied the link to the prototypes and was on hand to make any necessary adjustments and take notes.
I also supplied static images for feedback from an online community, and for rapid testing.
The team would come together to analyse feedback in Miro and determine next steps.
The research insights would inform tasks for subsequent sprints.
As confidence in the designs increased following research, I integrated the relevant elements into a separate prototype for building.
We collaborated with the relevant Engineers responsible to ensure designs could be replicated.
It was challenging to determine when designs were ready for building.
We began developing a process for signing designs off, including:
We had a single file for several workstreams, (including research stimulus), which caused some confusion for the team.
I spent some time labelling designs and prototypes, which prevented some confusion.
The general practice now is to create a separate file for the technical build.
Unfortunately I wasn't involved in the project for the final iterations and delivery. But I was able to take part in some testing to resolve technical bugs before the pilot went live.
Some designs didn't make the final experience, but priorities were met and the pilot went live for over 6 months.
The results of the trial are in the process of being analysed to determine next steps.
Personally, I found it extremely rewarding to work on a project that was tackling large scale issues and exploring new ground.
In companies the size of the BBC, change is a long-term process. The technical achievement alone is worth celebrating. But it's also gratifying to hear news of this project and the wider initiative make its way across the organisation and beyond.
The project has helped platform the conversation and pave the way for more ethical data practices.
An overview of the pilot and technology can be found in the following BBC News segment.
I learned many things during this project. The most significant was trusting my ability to, identify priority areas, shape tasks, and deliver outcomes that consider all relevant perspectives. I developed a self-starter mindset.
I also learned that the devil really is in the details. Seemingly simple UI changes can have a big impact on meeting user needs and project objectives. In this case, gaining insight around the Data Pod was pivotal, and small UI changes raised its profile without disrupting the core experience.