Toucan is a significant update to our existing Standard Media Player (SMP) - which has been around in one form or another since the 2012 Olympics. The existing player has been continuously updated since then and is still used across the whole of the Ö÷²¥´óÐã website, from Ö÷²¥´óÐã iPlayer to Ö÷²¥´óÐã Sounds and from the World Service to Weather. Over the last twelve months, the player delivered over three billion streams to web browsers on desktop, tablet, and mobile phones.

Why introduce a new player?

The SMP dates from 2012 and has accumulated support for many older browsers and technologies, which are increasingly being deprecated or even no longer exist. One example is the use of iframes which is used to separate the player code from the embedding page code. This technique still works but is no longer the preferred method in the web development community. Additionally, we wanted to completely redesign the user interface (UI) and take a mobile-first approach. Building a brand new UI on top of an old codebase didn’t make sense due to the incompatible technologies we wanted to use. The advantage of a new player is that we can drop all the old code, rebuild more efficiently and be more able to add up to date features and technologies in the future.

Toucan, therefore, supports many modern features that audiences expect. These include 20-second skip forward/back buttons, variable speed playback, slicker animations, and a cleaner design with mobile use in mind. Accessibility is also vitally important and has been considered from the start of our development. The player now has keyboard control – press space to play and pause, arrow keys to seek forward and back, and F to go full screen.

One major advantage we’ve brought to the new player is a componentised approach. This means that the UI is loaded separately from the main player and enables us to produce different UIs more easily if required and load the most appropriate one. For example, a child-friendly version with larger buttons or additional features could be created and used where necessary (and save download costs by not loading any UI which is not needed). Another advantage of the componentised UI is that we can build-once, use-everywhere, meaning we don’t waste effort building the same UI for multiple use-cases. The new UI that comes with the new player is already being used with the new Chromecast receiver, which has prevented exactly that kind of duplication. This UI can be seen now on your TV if you cast from iPlayer mobile (and shortly, iPlayer web and Sounds mobile).

We have also updated to a more modern version of CSS and JavaScript, and the player continues to be built on , the open-source media playback component, which we contribute back to for the benefit of the Dash.js community. New releases of Dash.js are, of course, always fully tested before making it live in production.

There are performance gains from the smaller size and more efficient build practices of Toucan and benefits from not needing to support as many older browsers as the current player does - and will continue to do so.

It’s built using , which was recently released in browsers as a native way to produce a component that can easily be integrated in diverse situations. We’ve also dropped our use of iframes in favour of Web Components’ – this is leading to a significant decrease in player load times.

Now that we have launched the first version, we will be adding all the other features that audiences need in a modern player. This includes audio on-demand, podcasts, live video, live audio, variable speed playback and much more. This will take time, but keep your eyes peeled as we incrementally develop the player across the Ö÷²¥´óÐã’s digital services.

You will soon see the new player on all our web and mobile services that playback video and audio, including Ö÷²¥´óÐã Sport, Ö÷²¥´óÐã News, Ö÷²¥´óÐã iPlayer, Ö÷²¥´óÐã Sounds, World Service and many more over the coming months as the features that these services require are built and launched into the new player.

While Toucan is exciting and will eventually replace the current player, we won’t rush to switch off the SMP. It will be needed by the audience where they are using browsers that don’t support the necessary features that Toucan requires, and we are committed to making sure that people can enjoy the Ö÷²¥´óÐã wherever they happen to be and on whichever platform they choose to use.

But for browsers that do support Toucan - we hope you enjoy that experience. Do send feedback to us at mediaplayer@bbc.co.uk.

• Ö÷²¥´óÐã Taster - Play Beat the Bot

The Ö÷²¥´óÐã's brilliant line-up of presenters and on-air talent will always be at the heart of our content. But we think there's also a role for a synthetic voice to augment them. A synthetic voice could power interactive quizzes with almost limitless questions and challenges. It could improve the accessibility of existing content. And it could help create new content individually personalised to our users.

James Fletcher, Editorial Lead, Synthetic Media and Conversational AI

Sports Quizzes

Quizzes are participation experiences in their purest form. And we know our Ö÷²¥´óÐã Sport audiences love doing really obscure and competitive quizzes, the harder the better...

The surge in DIY Zoom quizzes during the pandemic may have fizzled out, but a whole host of TV quiz shows with high production values have taken their place. Amidst quiz fever, we started to think about making a quiz that showcased our new synthetic voice and allowed audiences to participate using their own voice too.

Beat The Bot

So we created Beat the Bot, a web-based voice quiz where you have to guess the names of all the Premier League teams that have ever been relegated. You play in turn against the bot, with no room for error. The bot is never wrong.

Beat the Bot is a testbed for launching the first of many voice-enabled experiences that audiences can engage with through their browser on their desktop or smartphone using their in-built microphones. We also made sure that audience privacy is un-compromised, which is key in creating a safe environment for more experiences like this in the future.

Jamie Chung, Executive Product Manager

Does using your voice make a quiz more engaging?

We wanted to test a hunch that using your voice would give the quiz more jeopardy and deepen engagement. When it works well, using your own voice provides a frictionless experience. By reducing the effort needed to type answers and correct spellings, gameplay can happen at a natural pace. However, if the speech recognition doesn't understand your accent and you are saying the right answer, a voice quiz can be more frustrating than a text-based one. Using your voice to complete a quiz may be a novel experience for many of our users; given that this is the first voice web quiz for the Ö÷²¥´óÐã, we had to overcome some design challenges.

One of the biggest UX challenges when designing Beat The Bot was indicating to the user when it was their turn to speak. If a user isn't sure when the microphone is listening and speaks too soon or too late, it can spoil their chances of winning. So we used visual clues in the interface to alert the user when it's their turn to speak and a circular countdown timer that slows ebbs away, telling the user how much time they have until the microphone will close.

Paul Jackson, UX Designer

What did people think?

After two weeks of being live on Ö÷²¥´óÐã Taster, we had a completion rate of 67%, and 65% of people played it more than once. The mixed success of speech recognition has had an impact on playability for some people; we're aware this is an area that needs improving before voice quizzes can be rolled out on a larger scale. But the numbers of users retrying the game demonstrate that the format works. Once we can improve the speech recognition for a broader range of British accents, the format could be repeated for a wide range of quizzes across the Ö÷²¥´óÐã.

The Ö÷²¥´óÐã is committed to creating a truly personalised experience for everyone. We believe that a more personal Ö÷²¥´óÐã helps us build a deeper connection with our audiences, and helps us to extract more value from online. We have so much to offer across our products and services and one of our challenges is to help our audience discover the content we have.

We have a number of approaches to achieve this but alongside automated personalisation like smarter recommendations, we want to enable our audience to tell us what they want to see more of. So, we’re exploring the idea of enabling audiences to follow topics, a new capability that could work as a service for all of our teams and products.

This consistent and collaborative approach is not only more efficient, but would allow users’ preferences to follow them wherever on the Ö÷²¥´óÐã they are. This blog posting will try to convey the complexities around creating this new follow capability.

Context

The Ö÷²¥´óÐã creates thousands of different content items on a daily basis, ready to be consumed by people in the UK and all around the world. But how might we improve the discoverability of that content? How might we offer new content to those who are interested in it?

The Ö÷²¥´óÐã Ö÷²¥´óÐã team started working on the idea of ‘topics’ in summer of 2019. Working with colleagues from around the Ö÷²¥´óÐã, we have developed the technology to present a Pan-Ö÷²¥´óÐã topic to the audience.

Very early on in the work on topics it was recognised that there was an opportunity to harness the power of topics by allowing the audience to choose which topics they personally find interesting so we can personalise their experience of the Ö÷²¥´óÐã and notify them when relevant content is available. Examples of this already exist with the Ö÷²¥´óÐã such as the My Sport functionality in the Ö÷²¥´óÐã Sport app; subscribing to podcasts in Ö÷²¥´óÐã Sounds and adding a programme to your favourites in Ö÷²¥´óÐã iPlayer.

The prior implementations have been undertaken in a product-specific fashion, but we are building ’follow’ in a unified way, aiming for a seamless audience and technical approach across all products. Behind the scenes, the mechanism for all these types of ‘following’ is common. How might we create an experience which harnesses all these ‘follow’ events to aid in content discovery by putting new and relevant content to our audiences quickly and efficiently?

Principles

For further background, read Matthew Clark’s blog post.

Platform Consistency

All new developments will occur within the Ö÷²¥´óÐã’s existing web technology platform unless it is not technically possible. WebCore utilises a mono-repository and because all the teams can access everyone’s code, it becomes much easier to be consistent across all our teams’ work. The graphical components are all stored in a central repository and are available to all teams to utilise and integrate into their own developments.

Reuse

All existing solution building blocks need to be taken into account and reused where applicable. If anything new is developed, it must be straightforward for other teams to utilise or develop further to meet their own needs.

Collaborate

Collaboration with other teams is key to this project’s success. This work is being carried out within a complex organisation and as such, numerous teams and colleagues will be stakeholders in it. Openness and a readiness to collaborate will pay dividends later.

The Key Considerations and Complexities:

What concepts should the audience be able to follow?

• We have chosen to do this, initially, at the topic level. For example, audience members will be able to follow their favourite musical artists, news correspondents or even locations. As topics are representations of the concepts that the Ö÷²¥´óÐã is creating content on, this feels like a more natural fit given that new content will keep being added to inform audiences on. While standalone content items can be revised (often with minor or major edits) after publication or when the story develops, this feels like too granular a level for a user to specifically follow, making a save or read later function more appropriate. To ‘Follow’ an article, for example, is more of a ‘read later’ function.

We need to understand how a ‘follow’ button should operate and how it changes state based on the current context it’s displayed within.

• We need to consider if the audience member is already following a topic or not, if we need to offer the ability to unfollow that topic or not.
• We also need to consider preferences we’ve already been given for other follow-like implementations and if it’s appropriate or not to use that data.
• It might also be applicable to present a follow count to indicate how popular a particular topic might be.
• We will also make the button mechanism available to our app ecosystem to keep the mechanism consistent across all our platforms.
• We need to build the logical components in such a way that they will operate in the same way regardless of where the follow button is presented.
• For example, if the follow button is offered on a Pan-Ö÷²¥´óÐã topics page like Manchester or Mark D’Arcy we must ensure the behaviour is consistent and intuitive.
• How will it work within accessibility guidelines?
• How will it work for our apps?

Legal constraints and how this will operate within the law

• Considering GDPR and previous preferences provided to us by our audience members, can this new capability function within the law and if not, what must we do to ensure we are legally compliant and transparent to our audience?

How will this operate within the overall ecosystem of the Ö÷²¥´óÐã Online estate?

• The Ö÷²¥´óÐã Online estate is complex and ever shifting. We must ensure we abide by open standards and reuse existing services to ensure a good fit today and for the future. Also, we must collaborate with teams internally to ensure our internal stakeholders are fully aware of our progress.

How will we ensure we don’t create echo chambers for audiences?

• We need to carefully consider how we present followed content, so that it is presented coherently alongside both recommendations and related content.
• Followed content will be shown next to editorially curated selection, therefore, we will also need to consider how we deduplicate and prioritise content.

How do we maintain adequate levels of data to be functional and keep that minimal dataset secure?

• We have a very robust data security process to satisfy. At every design step, security of the data is a key requirement.

What data do we need to record to adequately record a Follow action?

• This data must then be easily parsed and follow our own internal standards and schemas.
• This data format must be compatible with the User Activity Service — our centralised location for storing user activity data — and be registered with it.

Where is the result of following one or more topics displayed? i.e. how are followed topics surfaced?

• This is a key question for any product team. The Ö÷²¥´óÐãpage team will have different needs than for example, the Sport team. But, the underlying system must be able to cope with this in as an efficient manner as possible.
• A key consideration is how much should we develop for each delivery? We could work for a long period and deliver in a more big-bang approach, or does it make more sense to develop in small iterations accepting a changing interface and functionality to our audience?

How will this level of personalisation work within the WebCore stack’s caching strategies?

• This is less of a concern for our team as we’ll be using the outcome rather than heavily contributing to it. However, it is of great importance and so we will keep in close touch with the team working on it to ensure no assumptions are made about what is needed.

Do we have the technical capability to process a potentially complex set of follow activities?

• Our Ö÷²¥´óÐã Ö÷²¥´óÐã Data Capabilities Team is developing specific technology based on AWS ElasticSearch for this very purpose.
• This system will capture metadata about our content from various internal sources to allow us to query that metadata in novel ways to find the content we need on a per user basis.

How will the resulting follow actions be surfaced?

The Follow Product and User Experience team have broken down the approach into four separate phases:

1. Audience members will be able to see what topics they’re currently following, follow new ones and choose to unfollow others from a topic index page or the Ö÷²¥´óÐã homepage.
2. Our audience members will be able to see the topics they have followed across the News and Sport websites and apps. This will come with the new ability to manage what they have followed across the Ö÷²¥´óÐã.
3. Also, our audience will get the ability to follow a topic from the content level i.e. from within an article.
4. Follow will become a unified approach across the Ö÷²¥´óÐã online estate helping breakdown any barriers between content and aiding discovery for all audience members.

One outlet for follow is in alerts and notifications. There is a team working hard on understanding how best to achieve this whilst offering the most value to our audience. It’s a complex area so we’re keeping close on that work to ensure we’re ready for it.

Conclusion

It is early days for ‘follow’, but the ground work is already in place for it to be a great success. The Ö÷²¥´óÐã topics product is maturing and is already powering the majority of the Sport website and app. It also powers the Ö÷²¥´óÐã homepages and we’re currently working closely with the News team to help them bring the Ö÷²¥´óÐã News topics up to date and into the WebCore world.

We’ve detailed our key principles and considerations around the follow action and how we plan to implement it. It’s a challenging area to work within but all the building blocks are sliding into place, and we’re starting to look at how and when we can roll out the first phase. Following a topic is something people understand, as they’re used to doing it on social media.

We’re working hard on bringing this functionality to our audiences as soon as we can make sure it meets the level of quality our audience expects from the Ö÷²¥´óÐã. We aim to bring together all our content to all our audiences in such a way that the traditional silos of content are blurred to the point of invisibility.

A short history lesson

Ö÷²¥´óÐã GEL is the design framework for the Ö÷²¥´óÐã and was one of the very first design frameworks to be published online back in 2010. GEL sets out guidelines to allow UX designers working on the different sections of the Ö÷²¥´óÐã website to create a consistent user experience and visual identity. This was fantastic as a set of guidelines for designers and developers to follow when creating websites for Ö÷²¥´óÐã Sport, Ö÷²¥´óÐã News and Ö÷²¥´óÐã Bitesize (to name just a few). Plus, all the other experiences for mobile apps and TV.

However, as Matt talked about in his recent blog post about moving to the cloud, we’ve been going through a cultural change in the Ö÷²¥´óÐã. We’re not building separate websites under one domain name any more. Through the WebCore project, we’re now building one website. And one key part of that is the design system.

Design systems are the single source of truth for both the design and implementation of a digital product, whether that’s a website or app. GEL can now be injected into the design system instead of being left to interpretation by teams reading and digesting the guidelines.

While there are plenty of design systems which are only built for one brand, ours has to serve a wide variety of destinations at the Ö÷²¥´óÐã. Destinations are the places which people come to the Ö÷²¥´óÐã to visit and they have to feel different to each other. There are informative destinations like News and Sport but also more playful ones like CÖ÷²¥´óÐã and CBeebies. This is tricky to do in a structured design system. And it’s something we’re learning to do best as we go.

Our design system is split into five areas:

• Foundations. Basic tokens like font sizes and spacing units.
• Components. These range from simple UI snippets like a button to complex ones like a navigation bar. Each component has accessibility and reusability considered from the first iteration.
• Layout components. Special components with a specific job to arrange other components in a layout, like Grids, Sidebars and the humble .
• Levers. The theming system. There are three levers (so far) in the design system: the font palette, the core colour palette and the brand colour palette. We want more levers. More on this later.
• Containers. The top-level components that assemble other components together and fill them with data to form a stand-alone experience that can be used on a page. For example, the Article container fetches the article content from the business layer, and assembles the Heading, Tag List, Rich Text and Image components to make an article.

Our community in Ö÷²¥´óÐã Design + Engineering have been building up the design system for over a year now, and we want to share with you the lessons we’ve learnt in that year.

1. Make it as easy as possible to share

We’ve taken a very different approach to the GEL design system compared to others out there. Our team, the Presentation Layer team, are not the sole maintainers of the design system. We haven’t pre-anticipated requirements and made in-advance a library of components like buttons, input boxes, navigation bars and dialog boxes. We haven’t created the design system as a versioned library that developers need to pull into their project and keep up-to-date.

So what have we done instead? We’ve done three things:

1. The Presentation Layer, our React-based rendering layer for the new Ö÷²¥´óÐã website, is a that includes the design system. Only web pages created in the monorepo can use the design system. And, most importantly, any changes to components in the design system are rolled out instantly.
2. Layouts, Components and Tokens are only created when they are needed. We typically wait until there are at least two use-cases for a component before creating it. We didn’t even have a Button component until a few months into the project!
3. Our team does not solely own the design system. Every team building with the design system jointly owns it. Working together as a community, we all build and make changes to components.

By doing these three things, every page is always using the up-to-date version of the design system and using it consistently. The design system does not stand alone. It’s built into the wider platform. So it’s not possible to build something bespoke to a particular team’s needs; everything can be shared.

2. Do things on a need to make basis

We intend to build the one Ö÷²¥´óÐã website together because previous approaches have led to fragmented results. Therefore, a top down approach of ‘we build these things and you use them’ doesn’t play nicely with this way of doing things. It shouldn’t be down to one central team to create the components all teams will eventually use. Our product teams do their own user research, so they know much more about how the audience are using Ö÷²¥´óÐã products and services than our team does. They’re the ones best placed to create new components and improve what we already have available.

We knew this approach was going to be difficult. Teams across the Ö÷²¥´óÐã are used to working in silos with autonomy to create components and features to meet their own needs whilst using the GEL guidelines as a steer. We’re essentially pressuring a move from vertical silos to horizontal shared ownership through the design system. Any new additions to the design system should be considered by how anyone might end up using them.

Because of this culture change, we’re striving to keep the components simple to start with. Remember that this design system has to serve multiple destinations at the Ö÷²¥´óÐã. If we start with something complicated then it’s only going to get more complicated and unmanageable by the time we’ve figured out how it can be used by everyone.

Keeping things simple means to avoid making components until they’re needed. In some cases it also means to not make them with all the bells and whistles until it becomes a requirement to do so. This allows us to avoid complicated discussions and move forwards in the short term.

We’re there to join the dots between all those other teams creating stuff in the design system and offer guidance and support in building and improving components. We create the standards and principles for all teams so that we can make sure accessibility, reuse opportunities and consistency are at the heart of what everyone makes.

3. The reinvention of the wheel

Prompting teams to find and use solutions already in the design system can be challenging. It’s something we’ve had to tackle whilst teams are getting acquainted with the design system.

There are some products at the Ö÷²¥´óÐã with well-established online experiences which are now rebuilding in the cloud using the design system. This can bring along with it a like-for-like mentality. Some teams (but not all) expect to create a carbon-copy of their existing experience using the design system.

There’s a whole array of articles out there which cover a topic of “what happens when a design system gets you 90% there” — these are our experiences on the subject. We know design systems are fundamentally driven by re-use. Creating something new which is similar to another pattern or component inside the library can add unnecessary weight, take up lots of designers and developers time in creating those new components and cause confusion in the future with those looking to find the right component for their needs.

We’ve been building things in isolation for years at the Ö÷²¥´óÐã, it’s sometimes hard for teams to think outside of their silo and horizontally about what the business needs in a component library. The design system, and the Presentation Layer Team are now influencing teams to think more horizontally.

A simple tactic we employ in these circumstances is to ask the teams “what problem are they trying to solve?”. This flips the priority of “we need this” to “a user needs to be able to do this”. We try to approach each new request for a component with a re-use first way of thinking. By doing this, we’re setting an example for the rest of the teams building using the Design System.

We can then have a conversation around the existing components available and potential iterations which all teams could benefit from. If we do find that there’s a requirement for a new component — we work with that team to build it with reuse considered. It’s easy to spot the same problems in different areas on our radar. We then join the dots, and get the relevant teams involved to help everyone work more collaboratively.

4. Be strict to allow for flexibility

To drive re-use, we need to be able to create components once; not multiple times for each of the different brands. So, to support the variety of destinations on the Ö÷²¥´óÐã website, we came up with a theming system we call ‘the levers’. Anyone creating a page can choose from a set of font combinations and colour swatches to theme it. And each component will work with all of them out-of-the-box.

A theming system might not seem like a ground-breaking idea, but it’s pretty powerful when Ö÷²¥´óÐã News leadership ask, ‘When can you get this video player page on the Ö÷²¥´óÐã Sport website ready to use on News as well?’ and we call pull some levers and say, ‘Hey presto – it’s already done!’

To make this work, however, we needed to be strict about what sets of colours and fonts are allowed to be used in Components. We had to resist the temptation to use our own colours in specific places.

Colours and fonts are given ‘semantic’ names based on where they’re intended to be used, rather than what they look like. For example, the text for heading text is called ‘primary’ and the colour for borders is called… you guessed it… ‘border’!

That doesn’t mean they’re set in stone, though. We’ve already had to add new colours and change them as we get newer use-cases, and we hope to add more levers in the future too. How great would it be to have different levers to change the type of motion applied to an experience? Or to help us create fantastic children’s experiences where there may be crazily different requirements for a website to cater for those types of audiences.

5. Documentation is hard, but important

One thing we always worry about is our documentation. We have a lot of it: accessibility guides, design guides, development guides, tutorials, component docs, principles, values…. And to make matters worse, they’re all over the place: on our internal wiki, in our cloud storage, on GitHub and in

Building a successful Design System and platform hinges on the quality of the documentation. It needs to be kept up-to-date. It needs to be discoverable. It needs to be easy to navigate.

Just like with components, documentation can start off simple but grow unwieldy as people add to it bit-by-bit. Taking the time to audit it, get feedback and clean it up is really important. That’s something we’re doing at the moment.

The Presentation Layer team duties are part design system curation and part support team. Having a complete and well organised set of documentation means we can run a tight ship. It helps us to automate a lot of support requests for both designers and developers.

6. Design for longevity through obsolescence

Finally, the Design System has got to be fit for the future. By designing our content and layouts as components, it’s easy to rip them out and replace them when the time comes. And we shouldn’t be afraid to do that!

is becoming a hot topic in the world of web design. As we start to embrace newer features of CSS like Grid and intrinsic sizing units, it will be easy for us to swap out our existing layout components with something more intrinsic.

We hope to talk more about Intrinsic Web Design in a future blog post.

============================================

It’s been over a year of designing, building and learning as we go. Above all, we’ve learnt that we need to be flexible as we work together with everyone from different teams. The progress that’s been made so far has been brilliant, and we’re excited about building on the foundations we’ve made to make experiences that our audiences will love.

This article is also featured on Ö÷²¥´óÐã GEL and the . 

The Ö÷²¥´óÐã Accessibility Champion Network is probably one of the oldest in the industry. This year it surpassed 200 champions. There is also an alumnus of 75+ now encouraging inclusive design and accessibility elsewhere in the industry. Here are the top highlights of many accessibility improvements in Ö÷²¥´óÐã digital products this year:

UX&D and Internal Tools:

The ‘Ö÷²¥´óÐã for Everyone’ video was published by GEL, along with draft . Neurodiversity . Internal S&SD did screen reader user research for Optimo, a new article editor for News journalists. They also reviewed and improved accessibility of Audiences, the new site for audience research, reports and data.

iPlayer and Sounds:

The web media player introduced subtitle size controls. iPlayer added an ‘Accessibility Help’ link for assistive technology users. iPlayer and Sounds both made efforts to respect an individual’s ' choice, which can be set in their OS preferences. iPlayer Mobile adopted an ‘accessible first’ mantra to work on a new player interface, available to opt in and try via the app settings. Work has included research with screen reader users and raising issues with OS providers. Behind the scenes work was completed that enabled both iPlayer TV and the new mobile player to add in-player controls for audio description and sign language. iPlayer and Sounds both have active accessibility guilds, and have integrated accessibility into processes, engineering methods, and testing strategies.

Children’s Games & Apps:

Research relationships continued with  and . It enabled and supported user research for CBeebies, CÖ÷²¥´óÐã and Bitesize games and interactive content, in turn guiding work on relevant content and the ‘Accessible Games Guidelines’. Bitesize Primary
improved keyboard accessibility across their existing practice games. They also launched 7 new games, with 8 more in development, that deliver on at least one accessibility ‘pillar’.

News:

News index pages became more consistent, easier to navigate, and introduced the Ö÷²¥´óÐã Reith font, which is clearer and easier to read on small screens. World Service sites are being re-built with accessibility embedded at every stage. This has extended the champion network outside the UK.  checked new components built for elections. And Visual Journalism considered accessibility from the start of each project. A scrolling story format that is keyboard accessible and has a toggle for animation is one example of the outcomes from that. The integrated approach shows how Catharine Green becoming Accessibility Lead was a decision that established accessibility as a clear priority for News.

Sport:

Following the example of News, Sophie Beaumont became Accessibility Lead for Sport, and an Accessibility Guild was set up. They embedded accessibility considerations into all team processes and built up a prioritised backlog of improvements. The teams have since created new pages and features that are some of the most accessible Sport experiences yet.

Weather:

A redesign of tide table pages for Coast and Sea section means they are now responsive, more legible and ‘glanceable’, and adapted for touch devices. The improved navigation for future dates also links to an accessible table version of the information with live updates provided to assistive technology. And animated indicators update in real time while adhering to an individual’s ‘reduce motion’ preferences.

Web Core:

This year a big change of direction toward a centralised approach took shape. The goal is a shared, non-versioned kit of parts, from which to create digital products and services. The team are building brand new components following the . The docs provide pragmatic advice for actual implementation with accessibility built in. This approach should also mean that future accessibility improvements roll out fast.

Voice & AI:

New tech on the block means a lot of user research. This has ensured the Ö÷²¥´óÐã’s collective Alexa skill is intuitive to navigate while reducing distraction and cognitive load. And it’s informing work begun on ‘Beeb’, a voice assistant from the Ö÷²¥´óÐã. Accessibility is a key requirement of both the user interface and brand development.

Ö÷²¥´óÐã Studios:

The commercial arm of the Ö÷²¥´óÐã may need a slightly different approach, but accessibility is still a key requirement. A redesign of Top Gear has provided the perfect opportunity to educate the team and make accessibility part of the end-to-end process of delivery.

Elsewhere:

Small changes, like improving link text in the cookie banner or checking the accessibility of a new local search feature before implementation, can ensure a better experience for many people. Though our champions don’t keep to small. Many blogged and presented this year, including Peter Gould and Nicola Quinn. They presented “How to Bake Muffins” at a #BuildTheÖ÷²¥´óÐã event open to the public. A heart-warming tale about why accessibility should be considered from the start of a project. Peter also built  in his spare time, a useful Chrome plugin already being used in-house.

Coming Up

Most Ö÷²¥´óÐã teams now ‘bake in’ accessibility. Look out for improved universal sign-in and children’s sign-in from Ö÷²¥´óÐã Account team. And also improved audience participation experiences. Research is being conducted to support insights into how children with varied and complex impairment use technology. Other research is looking at how to make interactive content more accessible for neurodiverse users. And the new accessibility guilds and groups in Bitesize, iPlayer& Sounds, and Voice & AI should make an impact throughout 2020. 

Conversations have definitely moved on from explaining ‘why’ accessibility is important. We now talk collectively about ‘how’ we deliver accessibility. A champion network that keeps accessibility part of the daily conversations is pivotal to that shift. The Ö÷²¥´óÐã sets an accessibility benchmark that many organisations strive to emulate. No easy feat in the constantly changing and evolving digital space. An active network of Accessibility advocates, our Champions, Leads, Groups and Guilds, is what makes that possible.

We are excited to announce that the opportunity to join our new Ö÷²¥´óÐã Digital Design Research Framework is now live. This will replace our existing roster this year.

We want to build strong and productive working relationships with agencies of all sizes, capabilities and research specialisms to support our user experience and design processes.

The new roster aims to help the Ö÷²¥´óÐã:

• Improve the quality of our design research, and of the products and services we make.
• Provide value for money.
• Bring diversity to our research.
• Drive the innovation and creativity of our design research.

We intend to select 5 to 10 agencies to join the roster with a life of 2 to 4 years, effective from July 2019. Over that time we expect to reward £2.4 to £3.6 million in contracts (approximately £600,000 to £900,000 per year).

If your agency is successful, you will have the opportunity to work across our digital products and services, including the Ö÷²¥´óÐã Ö÷²¥´óÐãpage, News, Sport, Weather, CBeebies and CÖ÷²¥´óÐã, Bitesize, Sounds, iPlayer, Interactive TV, and the systems and services that power these products.

More than that though, the agencies will help inform our understanding of our users to help us create new products and innovations.

What kinds of agencies will we select?

We’re looking for a diversity of types of research agency. To be selected you must be able to carry out excellent task-based user research, and then communicate your findings with clarity and creativity to inspire and galvanise our teams to take action. We want to see great research generalists and specialists on the roster — agencies that have pet passions, unique offerings and a strong focus on quality in their practice, agencies that can encourage us to try a broader range of methods and approaches to research.

We also care about your staff development, and contribution to strengthening the research industry in the UK. We hope to select agencies based in many different locations, since our projects will be based in Salford, London, Glasgow and Cardiff and we need to represent the needs of users from all over the country, and all over the globe.

What will it be like on our new roster?

We want to build strong and creative working relationships with our research agencies, and we want to be a great client.

Instead of commissioning each project separately, we’ll be creating longer-lasting Work Packages that are based either around a research methodology (e.g. contextual and ethnographic research) or around a particular theme (e.g. children and youth audiences, or Voice and XR), with input from both sides contributing to create the best research possible for our User Experience and Design teams.

We intend to award Work Packages to the successful agencies roughly once a year. In order to match agencies capabilities with the packages available we’ll be utilising the information submitted throughout the tender process, alongside other considerations such as pricing. More information can be found in the Framework Agreement (Section 2, available via Bravo Solutions).

What is the selection process?

Joining the roster is a two-stage process. Firstly there is the Pre-Qualification Questionnaire (PQQ), which assesses the technical capability and experience of each agency. Following this, successful suppliers will be invited to participate in the second stage; Invitation to Tender (ITT).

PQQ stage

First you’ll need to complete a few Pre-Qualification Questions. These are mandatory pass/fail questions about your company and questions relating to the minimum capabilities and experience suppliers are required to have.

We do the rest of the PQQ assessment with two A3-sized posters, which need to illustrate your capabilities and experience. One poster should showcase your qualitative research work, with the other showcasing a research specialism of your choosing.

These posters are the main way for you to shine — it’s your chance to differentiate your offering and skills, so please think carefully about what examples you use and how you communicate them to us.

We’ll then be using the Selection Criteria to shortlist a minimum of the 10 highest scoring agencies to participate in the Invitation to Tender.

ITT stage

The ITT gets into what you could do for us with practical exercises and a visit to your agency. It will consist of three assessed parts; written response, presentation/research challenge and a facilitation exercise.

The Ö÷²¥´óÐã will be visiting supplier offices for this part of the process. The facilitation exercise will take place prior to the visit to your premises as part of the research challenge.

A week prior to visiting your agency, we will send you a research challenge brief. On the day, you will give a credentials presentation, answering a few pre-defined questions we have (e.g. how you approach projects with clients), and you will deliver your response to our brief. We will pay you a small fee in recognition of the work you’ve undertaken for the challenge. As part of this brief, we will also ask you to facilitate research with participants (that we will recruit for you), and to send us a video file of this facilitation.

We want to give you as much opportunity as possible to show what you can offer us, and we hope our process will do this, whilst keeping the amount of work you and we need to do to humane levels!

After evaluation of each ITT response, agencies will be advised of the outcome by late June 2019.

How to get started

Firstly, take a look through the document below for a more detailed overview of the process.

You’ll need to make sure that you’re registered on the Ö÷²¥´óÐã’s e-tendering portal , where you can find all the tender documentation. Please ensure you carefully review all of the published material. Please note that the ITT and Framework Agreement are provided for information only at this stage.

You can then throw your hat in the ring by submitting your response to the Design Research Roster PQQ by Monday 18th February 2019.

The Ö÷²¥´óÐã will be hosting a Webinar to discuss the procurement on 24th January 2019 at 2pm where you’ll be able to raise any questions regarding the Ö÷²¥´óÐã’s requirements, or the process itself. You can register .

If you have any questions and are unable to make the Webinar then the PQQ document gives you guidance on how they can be raised, and the deadline to submit them. A recording of the webinar will also be made available after the event.

Good luck!

In making such changes we have consolidated the number of market instruments that we offer data on in order to bring audiences an editorially-led experience that focuses on those entities that are newsworthy and drive the markets. In short, this means our broad audience now benefits from an improved user experience albeit covering a scaled-back amount of market data and related pages. This simplified offering ensures market data is explained through our editorial, and our editorial is illustrated by our data.

The new ensures our audience can access market data information on all devices, in a fully responsive design, with interactive price charts across a range of time periods, and supported by Ö÷²¥´óÐã Business editorial. As part of the project to refresh our market data service, we have launched new pages on more than 500 popular company shares, and provided our Business editorial team with the ability to create new company share price pages in minutes as the news agenda demands.

Accompanying the share price data and company news are 15 major global index pages covering the UK, Europe, US and Asian markets, five commodities pages providing information and news on global oil, gas and gold prices, and pages on four of the world’s main currencies, namely pound sterling, the euro, the US dollar and the Japanese yen. A quick overview of all this data and the day’s upward or downward trends is provided on an overview page.

Clicking on any item in the overview table, or searching for a share price in the company search box, presents the user with a dedicated page to that company, currency, commodity or market that features a detailed chart covering data movements over the current day (intraday pricing), the past month, the past three months, past year and past five years for comparison purposes.

Having launched the first iteration of this new market data service, we are now building a Company A-Z page, investigating ways to make the interactive nature of our new pages more obvious, considering the introduction of top share price risers and fallers as well as sector listings, and working on a new editorial tool that will enable our journalists to more easily embed a range of market data within stories.

Phase 2 - Beta

Sometimes what users say and what users do are very different! With this in mind, once we had a design in place we created a working prototype to further test a couple of things with our beta group of around 2000 people.

The first question: what impacts will this navigation pattern have on how people currently use the app?

We gathered anonymous data on how long people used the app for, how much content they would read/watch and we were happy that users seemed to be getting more out of the app as a result of the bottom navigation. We also got some firm pushback on the amount of space we were taking up on people’s screens that influenced the future steps we would take.

The second question we had was: do people hate it?!

The user tests and survey were great to validate that it's not a bad idea but we didn’t get any really negative feedback. Putting it in front of our larger beta audience, who are certainly not afraid to speak up, really put the bottom navigation under the spotlight. From our beta users, only 3 out of almost 2000 expressed any negative feedback about the bottom navigation, which really gave us confidence before any large-scale experimentation could happen.

Examples of the feedback we received and incorporated into the next phase:

Phase 3 - Experimentation

This time round we built a bottom navigation that wasn’t too far away from production ready. However, before we could fully invest the time to make the bottom navigation fit for purpose we had to answer the following questions:

1. Do people consume more content as a result of the bottom navigation? A successful experiment would show that people consume more as a result of the bottom navigation.

2. What should go into the bottom navigation? For this experiment there would be 2 options surfaced to a percentage of our users: one variant contained video content and the other Live content. The variant that led users to view more content compared to the current production app would be considered a success.

3. What impact does this have on the amount of time people spend in the app? A hypothesis we had going into this project was that a bottom navigation bar might increase the speed in which people can access content. Taking this into account, a reduction in the amount of time people spend using the app isn’t something we would normally aim for but would be improving user experience.

To answer these questions we set up a couple of different variants of the bottom navigation and put them in a multi-variant test to compare their performance against production (no navigation bar) for 4 weeks.

Decision

Once the 4 week test had finished we looked at the results. We could see from the data that as a result of the bottom navigation people would consume 7.4% more content using the Video variant and 8.5% more content using the Live variant.

We also saw that time spent in the app was reduced by an average of 4% because of the bottom navigation.

Overall these results made great reading and gave us the confidence that proceeding with the ‘Live’ variant of the experiment was a good thing for our users.

After some weeks making the prototype fit for purpose we have now released the bottom navigation to our audience. Since the release we have seen the same pattern where people are reading/watching more in the Ö÷²¥´óÐã Sport App. People are also spending less time in the app as expected. We love the thought that our users are getting more of what they want, when they want it and are glad we took the time to get this right.

So far we have seen over 350 reviews of the latest release. From this only 6 people have expressed any negative feedback about the bottom navigation with an average review of 4.4. It's a good start for the bottom navigation but not the end. We will be listening to our users, doing more with navigation in the app, implementing improvements and making tweaks for as long as we need to.

We hope you enjoy the new update.

The News front page is something of a behemoth, frequently receiving well in excess of 100m page views from 18m browsers each week. Making significant changes to a product that popular is always challenging, and one of our main challenges as we undertook an overhaul of the page was to ensure we caused as little disruption to users’ news experience as possible. Over the past year, we’ve completely redesigned and rebuilt this page to achieve a set of user experience, editorial and technical ambitions. We’ve made the page much faster, clearer and more visual for millions of readers across the world.

What we wanted to achieve

The reasons for rebuilding the News front page can be split into three categories: technical, editorial, and user experience. On the technical side, we wanted to move the page to the Cloud to ensure scalability and to reduce our reliance on ageing in-house servers. We also wanted to build the page from components that could be shared across the Ö÷²¥´óÐã, whether that be in News or from other products such as Sport or iPlayer, for efficiency and to work towards a ‘one Ö÷²¥´óÐã’ technical goal. And we wanted to improve the page’s technical performance so that it is both faster and lighter.

Editorially, the goal was to enable our front-page editors to curate and present news content along thematic lines rather than in ways that correspond to the individual sections that the newsroom is structured around. We wanted to enable our editors to be able to mix and match stories from all over the newsroom when they were curating the page. In addition, we aimed to improve editorial’s ability to change the layout during major news events, and to more clearly promote the different types of content on offer such as our and Live coverage.

For the audience, who in contrast to typical News site usage are primarily viewing this front page on desktop devices (60% of page views), it was important to make better use of on-screen real estate by enlarging the page to full width on a 1280px display. For all users, the design goal was to make the page more visually engaging with better-quality images and clearer signposting, while driving users into content journeys and encouraging repeat visits. For mobile visitors in particular, we wanted to deliver faster load times.

The bottom line is we wanted to create a faster, cleaner, simpler, more flexible and more interesting page.

How we’ve gone about it

• Slice design

The new front page is based around repeated usage of several new ‘slices’: containers that house either 5, 7 or 13 stories. They run horizontally across the full width of the screen. When there are 13 stories present, editors can switch between four modes to dial up the volume and provide more coherent curation during major news developments. These slices are built in a way that ensures other teams can easily add them to their products and plug in their own content to quickly create a new module. For example, the General Election team were able to include four new slices on their Elections 2017 index to give equal promotion to top political news from each of the UK nations.

On the front page, we’ve configured our slices with an eye on balance and rhythm, to make sure more users find stories they’re interested in, and to keep people scrolling further down the page. The main news agenda is juxtaposed against the ‘Must see’ content, which is typically broader in focus and which in turn contrasts with the more weighty content of ‘Full story’ that follows.

• Promo design

Within each slice, story presentation differs depending on the type of content. We initially launched with just one method: an image, headline and optional summary text. Since launch, we’ve added a feature promo that has a stronger visual impact for in-depth analysis of stories, and a live promo that shows the latest updates on the ensuing live page. These different promo styles make it even easier for the audience to identify different types of content, and by setting expectations about each piece of content we are making it easier to decide what you want to read. We have more promo styles in the pipeline for other content types, as well as plans to multi-variant test (MVT) iterations of our existing promos. 

Other design tests carried out on users included multiple variations of font size on our top stories during the rollout of the 13-slice module. We found that during exceptional news events font size makes very little difference to engagement, but on more ‘normal’ news days a larger font on the main news story more clearly communicates the hierarchy of the page and thus attracts more users to that news and its related stories.

• Further personalisation

Frequent users of the page will note we also added a second component of personalised news. In addition to the old page’s local news, which presented three top local stories to those users who set their location in the page, the new page also offers regional news based on your selection of UK nation: England, Scotland, Northern Ireland or Wales. So for those wanting a more representative overview of news affecting them, the new page now offers a wider range of global, national, regional, local and broader interest news.

• The rollout

In order to minimise disruption to users, we steered well clear of a big bang release and instead opted to make many incremental changes to the previous front page. We gradually replaced multiple old modules with single new slices starting from the top of the page, until such time that it was agreed we should start migrating our domestic and international audiences from their old page to a new page where the new slices were already in place alongside further visual and technical upgrades. The migration itself involved redirecting audiences in steps, starting with 1% of the audience, then 5%, 10% and so on. Users were automatically redirected to the new page with no possibility to opt out as the old page needed to be deprecated.

What impact it’s had

It’s good news. The front page is now better at getting people to content: bounce rate (the proportion of visits that result in a user leaving the Ö÷²¥´óÐã News site without visiting any other News page) is down 2% and overall 26% of all article views in News are now driven by the front page, up from 22% on the old page. The page also does a much better job of getting people to video content, with 32% of video page views coming from the front page versus 10% previously. It is also making people come back more often: front page users now come back on average 9% more often during a week than they did with the old page design.

Regarding our technical goals, the new page is much faster and lighter. The first meaningful load on mobile devices happens up to 50% faster, lazy-loaded images load twice as quickly on mobile and 70% faster on desktop, and the total bytes downloaded onto users’ devices has been halved on mobile and cut 75% on desktop. All this while adding bigger and improved-quality images. Our lead engineer Joseph has written in more detail about this in .

What next?

We are continually striving to improve the page for our audiences to ensure that as well as understanding the day’s news agenda, our users are also finding content that is important and relevant to them, and their satisfaction with that experience encourages them to keep returning and consuming more content. We have various projects and plans underway:

• We are starting to experiment with pre-loading onward journeys so that people who click on a story have the gratification of it loading instantly;
• We have further multi-variant testing plans aimed at identifying additional incremental improvements to our promo strategy;
• A new type of slice is currently in development that will provide clear information and links for other ways to access and contact Ö÷²¥´óÐã news – via the app, newsletters and social media;
• Recent accessibility testing of the front page highlighted additional steps we would like to take to improve page navigation and content signposting.

As well as these next steps, the strong performance of the new News front page implies it makes sense to use it in more places across the Ö÷²¥´óÐã, so we are working with other teams to explore what that might look like.

By applying lean UX practices in our design work, the UX&D team have collected many insights around pain points that users of our in-house online production systems can experience. However, when we compared our research activities a consistent pattern emerged: our users - mainly editors and journalists - are exposed to a large number and range of tools. But our research was giving too much importance to just a limited number, namely the ones managed by the product teams we were working with. This meant that on a regular basis, our research was not uncovering the real causes of our users’ problems and pain points.

Picking a Service Design technique

With this in mind, at the beginning of this year I started to look at approaches that would allow us to both widen the focus of our research, and gain a view of the tools from the standpoint of the users. We had already applied several mapping techniques to internal tools - such as  from Adaptive Path - but we had been focusing on specific tasks, e.g. uploading a video to used in an article. This time, with the aim of learning about totally unknown issues, we wanted to understand the full range of tools people were using and how they used them - not just thinking about predetermined sub-tasks with specific software. By looking at examples from other companies facing similar problems, and from personal experience, a Service Design approach seemed a good choice because of three main characteristics:

• The use of ethnography, as we needed to immerse ourselves in the world of Ö÷²¥´óÐã staff.
• Co-design techniques, to involve users in designing the solutions to their own problems, from their own perspective.
• Holistic thinking; the ability to see the tools as part of a wider ecosystem.

Among different service design tools, I realised that the would be best suited for our purpose, as we wanted to visualise the different phases of a service from the user perspective, and map those phases back to the software and the technical systems working behind the scenes. In order to use the technique, we needed to shift our approach and adopt a service perspective. We started by looking at our systems as part of one unified digital service, which was helping staff in putting their content online successfully. The visible part of the service were the tools, the invisible part were APIs and backend systems. Anything related to the tools, from training to tech assistance, would have been part of the service and its phases.

A process of change

Although it may appear basic, this assumption changed the perception of our own work. We had to employ ethnographic observation and contextual enquiry more accurately than ever before, and Service Design pushed us to acquire new skills and sensibilities in the area of strategic design thinking practice. I was enthusiastic about this point, as it fitted with the way our design team could work with the product teams in a truly cross-functional fashion. This implied going beyond what we were already doing as UX designers, which consisted in applying Lean UX within pre-set agile teams, as exemplified by model for design teams in Software organisations. Familiarisation with Service Design was therefore the first step in this long process of change.

How we did it

After deciding on the technique, our next task was to select an area of the business to study, which would offer tangible information within the limited timeframe we had available. We focussed on shadowing journalists during their daily shifts in the Ö÷²¥´óÐã Birmingham Newsroom.

Our observations confirmed that teams were using a far wider set of digital tools. While our assumptions on how editors and journalists perceived our production systems were on the whole confirmed, we also saw that their working practices included not just digital software, but also other things such as 24/7 tech assistance, specific News software, broadcast management platforms, video-editing, emails and training. We were then able to identify potential pain-points that weren’t specific to any single tool, but rather arose through the interaction between non-digital elements (such as phone calls and print-outs) and software. This level of detail is something we wouldn’t have achieved solely through traditional interviews and testing focussed on usability issues and software usage.

Decoding together is key

The next stage was to collate and present our data. We saved all of our findings digitally, making them accessible to everyone, then focussed our attention on the high number of tools and the ways in which teams interacted with them. We then went through a huge set of field notes, pictures and recordings, transcribing all the notes on post-its and print-outs on the wall in order to capture the full environment journalists work in.

We were now able to transfer this information onto service blueprints, showing the different phases of a journalist’s ideal working shift. We shared these with the Product teams, in one-to-one meets with business analysts’s and product owners, feedback sessions with developers and designers, and via email to wider groups in order to initiate a conversation with our colleagues across the UK.

Key findings and outcomes

Although the blueprints only covered a few profiles in their first iteration, they immediately resonated with team conversations, data from other streams of research and software trials, strategic plans, and first-hand knowledge in the team. They had the benefit of making the pain points of the users clear, but more importantly, they made manifest how tools were perceived as a unified service, especially to people new to the organisation.

In our daily design activity, the key outcomes of the blueprints have been:

1. Strengthening of cross-functional initiatives, such as our shared pattern library for increasing consistency across the tools

2. A clear business case for small design quick-wins - for instance adopting a common vocabulary (e.g. document status names) across the tools

3. A solid foundation of user knowledge, which could be used in interdisciplinary activities such as Design Sprints

In the longer term and in regard to organisational change and improvement, the outcomes were:

4. Developing the capability for UX teams to tackle complex issues and share actionable understanding in cross-discipline teams

5. The development of a circle of trust with the journalists and the editors, and a push for adopting a co-design approach more consistently, to include even more users in the design of features and priorities

It was encouraging when we discovered that people were spontaneously taking snapshots of some of the wall items, and including them in their documents and presentations. This was a sign we were working in the right direction for introducing and sharing a new approach within the organisation, and that there was an appetite to reflect together. By creating these blueprints, we've learnt some new skills and practice in co-design and ethnographic research. We've evolved our design-based approach to complex problems. This is extremely helpful for putting the user needs at the core of our everyday activity and influencing the long-term strategic thinking of our organisation.

What did not work

After some specific feedback around the first version of the blueprint, we realised that we were incorporating far too many details in the posters, and the ‘story’ we wanted to tell subsequently came across as too deep. The blueprints were difficult to read and empathise with, and this stopped people really engaging. As a result, we are currently working on a second version of the posters. We aim to improve their legibility and storytelling, so they are clearer and easier to take in, with more actionable insights focused on specific software issues that everyone in the product teams can familiarise with.

Although we engaged users and journalists, we have not yet managed to kick-off any long-term co-design activity. This is definitely part of our next objectives.

Next Steps

The idea is to go further with exploring and mapping areas of the Ö÷²¥´óÐã in this way - involving more users and members of the teams in the discussion, and including co-creation - where people using the tools would be more actively involved in their definition. The months ahead are promising, as our department has put in place a new strategy for integrating all of the tools. Plus, the Ö÷²¥´óÐã UX&D team have included Service Design in its objectives for this year, so it will be a good time to experiment and put these approaches to work within the organisation.

At the beginning of my career, I was designing without much involvement from the rest of the team. I thought designing was my responsibility and I didn’t want other people to alter my visions. A couple of years later, I started to realise that when a Product Manager was coming along to research sessions, I didn’t have to fight so hard to sell my ideas anymore. The ideas they were coming up with were much more human-centred. Instead of fighting against them, I could use and build upon them. I now understand that involving the team and opening up the design process is crucially important to craft great experiences for the users.

Involve the team and stakeholders when doing research

To make your product or service more human-centred, the people you work with need to empathise with the users. The first step to make this happening is to invite them when you meet with users so they can witness and experience their feedback and comments. This is particularly efficient because people tend to believe and care more about things they engage with directly, rather than things reported by someone else. Applying this method with the team at the Ö÷²¥´óÐã has been so successful that the Developers even started to talk to each other about the users over lunch breaks!

In addition, it helps people to understand what you do as a UX Designer, which increases the level of trust they have in you. This can be particularly beneficial when working with a new team or client. You’ll also spend less time defending your design decisions as people will better understand where they come from, and how they will benefit the users. I found that Developers became more flexible once they understood why things need to be changed, and it helps Product Managers to find the right balance between user and business needs for the strategy.

Tips

• Inviting people to short sessions makes it easier to convince them to accept
• Share your findings during standups every time you meet with a user
• Show a short video clip of your usability tests during a team meeting or standup
• If no observation room is available, limit the number of people meeting the user to maximum 2, or it may be overwhelming

Involve the team and stakeholders when analysing the findings

Once your team and stakeholders empathise with your users, the next step is to make sure the research findings are understood. This is important to make sure they will get used to shape the roadmap and strategy. In the past, I often created personas and that I presented and stuck on the wall, but most of the time the team wouldn’t engage with them. Involving the team – especially the Product Managers – when analysing and visualising the findings turned out to be much more efficient. People assimilate information better when they engage with it than when they passively consume it.

To make the team engage with the research findings, I like to organise workshops in which we collectively analyse the research findings and create artefact such as . In addition to helping everyone assimilate the findings, it will speed up the analysis process – less documentation to create and more people to go through the data.

Here is how you can proceed:

1. Clean up your research findings’ notes
2. Create a user journey before the workshop and stick it on the wall. You can add touch points and persona on it, or do it during the workshop.
3. At the start of the workshop, distribute your research findings notes to the workshop participants and assign participant(s) to a user.
4. Ask the participants to write the pain points and happy points on red and green post-its and to stick them on the wall.
5. Ask them to group similar post-its together and to give a title to each group.
6. This is your Mental Model Map - take a picture!
7. Ask them to map the group’s titles on the user journey. If it makes more sense for you, you can map all the pain and happy points under the user journey.
8. This is the start of your Experience Map! You might want to clean it up and complete it.

You can follow a similar approach with your favourite analysis method, map, or persona!

Tips

• Keeping the workshop short will make it easier to convince people to accept
• Make the workshop useful for you as well (e.g. it helps you to analyse the research findings)

I recently organised a similar workshop with the team and it really had a positive effect on helping the team understand and use the research findings. The map helped facilitate discussions and discover new opportunities for the product. Many of the research findings have also been used by the Product Owner to shape the roadmap and strategy.

Conclusion

In order to maximise the impact your UX work has on the strategy and make the design process run faster and smoother, don’t be scared to open up; especially if you work with a difficult team or stakeholders. Involve others when you do user research and analyse findings as it will help you gain trust, make the entire team and stakeholders more human-centred and help you better understand the goals and interests of your colleagues from other disciplines, which is the key to better collaboration.

Which techniques do you use to collaborate with your colleagues? How do you influence the strategy? Let’s collaborate!

It’s 27th July 2012 at 8.43pm. I’m in a caravan with some friends on a weekend away in Anglesey. We have gathered round a small 15’ inch telly to watch the Opening Ceremony of the London 2012 Olympics.

The spectacle is fantastic. As I marvel in awe and swell with pride I'm also extremely inspired. One particular moment of the ceremony struck me most, though. Sir Tim Berners-Lee (the inventor of the World Wide Web) comes along, sits down at a computer and types ''. 

In the context of the Opening Ceremony the sentiment rang true across the World that the Olympics had arrived and it was for everyone, no matter who you are or where you lived. It also reminded us of the one key principles of the web: Universality.

This sentiment made a permanent impact on how I approach my work as a Designer here at the Ö÷²¥´óÐã and, importantly, how we have approached our work in GEL.

The full launch of our this month signifies the beginning of something special.

The new website is  to provide a way to create consistently amazing online Ö÷²¥´óÐã products and experiences that are accessible to all, no matter who they are or the technology they use.

The site aims to help anyone creating online experiences to re-use our best practices, methodologies and front-end techniques. Affording more time for innovating new and exciting features for our audience.

So how do we make a Global Experience Language work for everyone and what does it mean in practise?

Introducing our Foundations

The best example of this is with what we call our Foundations - the Grid and our use of Typography & Iconography. These are a consistent requirement across all our websites and apps. It doesn’t make any sense for designers and developers to be re-thinking and building these over and over again.

An example of how we solved this is shown with our Ö÷²¥´óÐã-wide implementation of Typography.

Typography at scale

All over the Ö÷²¥´óÐã's website we have text; lots and lots of text. Headlines, articles, video descriptions, football stats and scores plus much more.

Making sense of how we present this text so it's readable, useful and consistent across every device is a big challenge.

Myself,  and our other colleagues came across this challenge 18 months ago when creating the different features for events like the 2014 FIFA World Cup and the 2014 Commonwealth Games. We were communicating well, and collaborating through pairing, but our workflow didn't feel as good as it could be.

Luckily, we have GEL, which provides a thoroughly researched set of Typography Guidelines. At the time this was in the form of a PDF, and provided 8 different type sizes and line heights which then needed to be applied to the correct elements on the website.

Taking inspiration from  & , we realised that if we provided a memorable name for each of these sizes, it might make communication between Designers and Developers an easier task - also saving time and providing more design control all in one go.

So for each set of sizes and line-heights, across devices, we came up with a name until we had a list that suited the Typography scale. We wanted something future-friendly but still related to typography, so we took names from traditional type measuring techniques dating back to as early as 1582.

• Canon (.gel-canon)
• Trafalgar (.gel-trafalgar)
• Double Pica (.gel-double-pica)
• Great Primer (.gel-great-primer)
• Pica (.gel-pica)
• Long Primer (.gel-long-primer)
• Brevier (.gel-brevier)
• Minion (.gel-minion)

So instead of a type definition being described by designer as '32px on devices that are 600px wide and above' it would simply be 'this is Trafalgar'.

This was one step towards creating a simpler dialogue between Designers and Developers, by reducing the need for complicated redline documents and improving the chances of iterating in the browser.

Reducing duplication

We then abstracted this typography implementation away from the Ö÷²¥´óÐã Sport codebase, thinking that we might be able to make it re-usable for everyone. This proved to be successful across the Ö÷²¥´óÐã Sport & LIVE pages that we were working on at the time.

We then attempted to make the abstracted typography code work for all of the other Ö÷²¥´óÐã teams and products. Our biggest challenge came with Ö÷²¥´óÐã News.

Ö÷²¥´óÐã News needs to support more than 30 different languages, 15 of which are non-latin such as Burmese and Arabic.

This forced us to re-think our implementation and allow customisation of the fonts and values used. For instance, allowing line-heights to be increased for a scripted font with particularly high ascenders and descenders.

Growth and re-use

We made the code available on our main  account so that it could be re-used by as many teams as possible.

We have since had 30+ developers and designers contributing from across 11 different teams. The Typography repository has now been made  and at the last count was being used by 18 different codebases.

With this sort of work alongside the GEL website we can really make a difference and the benefits are clear - by using GEL and re-using our foundational code, our audience gains from a consistent and familiar experience and we can save time and focus on adding new and innovative features to our offering.

We have since taken the principles and approaches we used to create a reusable implementation of Typography and done the same for the . Work is underway to create a similar implementation for .

The GEL Foundations will hopefully make an impact to our content and reach as many of our audience as possible, from caravans in Anglesey to , the limits are endless.

If you would like to give us feedback on this work, please add your comments below or via the . Big thanks also go to for his contribution to this work.

What is GEL?

The first Ö÷²¥´óÐã web page was published in 1997. We had boundless enthusiasm for this new medium and certainty that the internet was important. But we were growing organically and unsustainably. Within a few years we had around 470 sites. And we needed a more effective approach. Hence the introduction of GEL, a shared experience language and framework used across all Ö÷²¥´óÐã digital services. GEL standardises the design of common interactions and defines the foundational elements such as the grid, iconography and use of fonts. As a result, we now have a much smaller number of sites – and thanks to GEL, all of them share consistencies in the way they work, look and feel.

In 2010 we published a website showcasing GEL. Due to limited resources we were not able to build with a content management system. This meant we couldn’t update the site’s content. Given web design’s rapid rate of change, the site and it’s content began to date instantly. Meanwhile there was increasing need for GEL guidance which gave rise to many internal sharing and storage solutions. A new entropy threatened, albeit behind the scenes.

A new GEL website

In 2014 we began to rethink our website. Our goal was a site that would assist and inspire the digital design community. We started by researching our audience. How would they use it? What should it provide? Who else might it benefit? The site would need to be constantly updated – so the need for a content management system was a given. We knew the resulting experience had to work on every level, so we spent a lot of effort on the technical solution, editorial (the quality of writing and content) and the information architecture (how content was structured). We also wanted to strip back the front-end styling to a more “bare bones” presentation. So our small GEL team set out on it’s quest.

With perseverance and the borrowing of technical skills from colleagues across Ö÷²¥´óÐã Digital, last year we began to publish our first beta pages. We’ve since been testing and iterating like crazy. And today I’m proud to announce the official launch of our new responsive website. Take a look: 

What does it do?

The site provides two core services. Firstly, the publishing and maintaining of our . These are collaboratively authored by designers across a range of products. This shared ownership ensures a design pattern’s reuse. Reuse affords us more time for innovation as opposed to remaking the same pattern over and over again. But GEL, like any language, is constantly evolving. Our new site provides “living” guidelines which document a pattern’s evolution. This means our designers can be sure they’re using the most up-to-date information.

The site will also showcase the great work we do in Ö÷²¥´óÐã UX&D. The section features our own editorial content with short films explaining our department’s approach and creative methods.

Who is the site for?

Most immediately the GEL website will benefit our design teams by enabling them to move faster and further, together. It will also aid understanding of our work for colleagues across the Ö÷²¥´óÐã, and beyond. This website is for anyone creating online experiences. Its content will grow to become a substantial design resource anyone can draw from.

What’s next for GEL?

For the Ö÷²¥´óÐã to remain a vital public service in an 'internet-first' world of constant change it needs to become more flexible and efficient. GEL will determine an appropriate degree of consistency to accommodate this. We are focussing on how sites can be built and function the same, as opposed to just looking the same. This presents significant technical and cultural challenges, but once addressed will increase our efficiency in providing excellent digital services.

So welcome to our new GEL website. This is the start of what will become a comprehensive resource documenting the development of our design language, whilst simultaneously increasing the Ö÷²¥´óÐã’s creative efficiency.