New World Service Front Pages: Lessons from our first steps
Some things we learnt while delivering three new front pages, with a new pod, working on a new application* — from development, UX and product perspectives.
*for most of us
On Monday we went live with 3 new BBC News World Service front pages on Simorgh, our new single page application for the World Service. The work on these front pages was started at the beginning of April, meaning it has taken just over 3 months from design to live.
Teams across News have done a great job of focussing on what is required for these pages to go live, but at the same time have extended Simorgh to support multiple page types (articles and front pages, and soon media pages) as well as the 41 languages of the BBC World Service.
These new front pages also represent an updated way of working within News. We’ve shifted to cross-functional pods (a small team with a clear remit), clearly differentiating those focussing on core application and infrastructure work from the front-end feature pods. The new release process means we can release to live multiple times a day — proven already by the introduction of hreflang meta-tags half an hour after the pages went live.
The pages are designed and built mobile first — evident in both the optimised design for mobile (only 8% of the audiences of these first sites are non-mobile users) and the amazing performance level the team has achieved. Performant web pages are key for our World Service audiences, particularly in regions where connectivity is bad and there is no access to WiFi. This prioritisation of mobile is also noticeable in the desktop layout of these pages — a single column of stories, unlike a traditional news front page. We will iterate on the desktop design as we introduce more features and continue to learn about user behaviour.
Collaboration between disciplines has been excellent throughout, particularly for accessibility, with UX and development teams working together to build some of our most accessible World Service pages ever.
Designers and developers have paired on features, making design decisions in the browser and ultimately speeding up the process. We used existing BBC design patterns to ensure consistency across different products. There are many complexities around designing for so many languages, particularly around fonts. Whilst building these pages we road tested an approach to scalable design, which involved thinking upfront about how to support the 41 languages — it proved effective.
Here are some lessons we learnt over the last few months.
Lessons we learnt: PRODUCT
[1] The scope indicated a culture change
It was important that the scope of these front pages was clearly defined, so that it was very clear how these pages differ from the web pages we are replacing. The team know the current pages well, so it would have been easy to assume the requirements were the same.
Goal: Get 3 front pages live as early as possible
Scope: Minimum requirements for these pages to go live
The scope also indicated a culture change, introducing the idea that we can release a simple first version of a feature or page, then iterate on it based on what we learn from user feedback. For example — not adding a link to the section divider in the first releasable version, then later introducing the links in a way that works for the audience.
Version one:
- includes Section divider does not include Section divider linking to index
- includes Tracking page views does not include Event tracking
- includes New typography styles does not include Custom fonts
- includes Simple timestamps does not include Relative and localised timestamps
[2] Be clear about your motivations and you’ll find other people start making the same decisions you would
I found that as well as being explicit about the goal, sharing the wider motivations for wanting to achieve that goal enabled the team to make better decisions on a daily basis.
In this case the goal was about being able to prove that we could deliver value early (in order to learn from our users’ behaviour) and to do this we needed to focus on core functionality. This included the developers pushing back against any potential complexity introduced by new features and adopting a workflow that helped maintain focus.
It was clear we were all on the same page once the team started asking questions like “is this required for version one?” and consistently used the ‘version 1’ label in Github to prioritise work. It felt like a shift had happened — the team were engaged, motivated and clear on what to work on. We had taken an important step towards a sustainable focus on delivering value to our audience. This article by Marty Cagan neatly describes the importance of having a team that functions in this way: https://svpg.com/missionaries-vs-mercenaries/.
Lessons we learnt: DEVELOPMENT
[1] Knowledge sharing is key
The main obstacle we encountered at the beginning of this project was the fact that majority of the developers were unfamiliar with the application we were working on. In our pod of seven developers only two had prior experience with Simorgh and its component library Psammead (both OSS — contributions are welcome!).
To overcome this we organised knowledge sharing sessions. We had a couple of sessions which were useful to everyone in the pod, from those who had not used React much before, to the more experienced developers. We also did some group code reviews, so everyone would have a chance to ask questions and get used to the code structure.
[2] Adapting to change
Suddenly increasing the number of developers working on a project can be tricky and we had to find good ways of working together. We had to establish cross-team code reviews, and try to agree shared technical approaches. The team dynamics soon settled and the idea of “merge and fix forward” was adopted. We also decided that if the number of comments on a PR gets out of hand, it’s time for a face-to-face discussion.
Our code is not perfect, but we are constantly making changes and fixing forward, while also being able to release shiny things, like the new front pages.
[3] Being realistic about browser support
Coming into this project we soon realised that we needed to rethink our browser support levels. The browsers we initially wanted to support weren’t far off from the ones listed in this blog post written when the last front pages were built over 7 years ago! Instead we used user metrics to focus our development effort where it would deliver the most user benefit.
This is of course a balancing act, focusing entirely on the ‘ever green’ browsers would allow us to deliver to a large proportion of our audience, but isolate many of our users who simply don’t have access to modern browsers due to their devices. Ensuring we cut off the browser support at the right level, and degrade gracefully where possible is key to serving our audience as quickly as possible.
Lessons we learnt: USER EXPERIENCE
[1] Establishing a cross-discipline approach is essential
By pairing up with developers, we could quickly respond to any technical limitations in the designs and work together to find a solution. All the while, using user research insights as our guiding principles. We also took this collaborative approach with our accessibility lead. Involving them early in the process meant designs were vetted and documented. This mean we delivered a consistent experience for all of our users and also saved time.
[2] Scalability is a key thing to consider upfront
When designing for web today, we have to think about the experience across different devices. In World Service, we also have to think about how designs will work in multiple languages. Designs can look different depending on the characters, from those with a uniform height such as Tigrinya to those with long ascenders and descenders. Not to mention we deal with languages that read right-to-left such as Persian and Arabic.
This is why it’s important to design for scale from the beginning. It means we only have to document designs once and developers only have to build components once. This doesn’t just save time and resources, it also makes things more consistent for users who switch between languages.
We’re hiring! https://bbc-news.github.io/join-us/
Written by:
Clare Evans, Drew McMillan, Jamie Blaut, Jonathan McKee
Thanks to the World Service Front Page Pod for all their hard work:
Amy Walker, Andrew Nowak, Clare Evans, Denis Hernandez, Drew McMillan, Isaac Odhiambo, Jamie Blaut, Jon Booth, Jonathan McKee, Laura Pison, Ruth Ogendi, Tom Anderson
