What is dark mode?

With the introduction of dark mode (night mode, dark theme), users can adopt a dark system-wide appearance. The dark mode inverts the device’s display to a light-coloured typography and UX elements on a dark background.

There are good reasons why users choose to set their devices to dark mode:

• it’s easier on the eyes, reducing digital eye strain.
• it reduces screen brightness, saving your battery life.
• it can improve content legibility, making it easier to consume content.

Caption: Gen Z use dark mode to combat eye strain

Gen Z, our target audience, are the first digital natives, constantly connected online and spending over 5 hours a day on their phones*. With so much time spent online, they use dark mode to relieve eye strain. It’s not just this age group adopting this setting, 82% of all mobile users now have the setting activated**.

The dark mode setting is available on mobile, tablet, and PC. All users can activate the setting system-wide or through an application. This includes:

• PC and laptop operating systems – Windows and Apple macOS
• Mobile devices – Android and Apple iOS
• Email Clients – Gmail, Apple Mail, Outlook

With such high adoption of this setting, we need to ensure our email communications are readable, on-brand and error-free. Basically, we need to ensure we’re meeting user needs in their own context, in the right place, at the right time. So, we decided to look into it.

What are the challenges in fixing dark mode setting?

There are a few key challenges in implementing dark mode. These are:

• each email client and the operating system will render emails differently.
• even the age of the device can cause a problem.

To combat it, the best way to test and check emails, is through an email optimisation tool, like . This resource performs tests on over 70 email clients, including dark mode simulations.

An email may look great with the dark mode setting turned off, but tests using Litmus indicate that elements of the University email template are affected in dark mode.

Caption: The difference between dark mode on and off, colours invert

The image above details two screens with the dark mode off and on. The screen on the left displays the email with the dark mode setting turned off. The screen on the right depicts the same email in dark mode. Here key brand colours are inverted, causing the email to be displayed incorrectly.

Our university is not alone, brands are affected too. Logos, text and call-to-action buttons seem to disappear. This isn’t the outcome any brands wish for when the purpose of an email is to engage with our customers, community and so on.

So, what do we do? Develop a plan for success

Caption: A process improvement plan setting direction of work

Before any work is undertaken, we developed a process improvement plan to:

• outline the purpose of the work,
• set direction, and
• break the workload into smaller, more manageable stages.

First, we need to recognise the main issues, understand their impact, and identify who could be affected.

Who is our audience and what mail platforms and devices do they use?

Our standard email template is at the heart of our digital communications. We use the template to build engaging emails to prospective students, to communicate with enrolled students and staff as well as other groups such as our alumni community. Each audience interacts with emails differently.

It is important to understand which email client, and platform our target audience uses. Otherwise, we could focus on the wrong technology.

Caption: The University’s main target audiences and how they interact with emails

When analysing our target audience, we identified three email clients (Apple Mail, Gmail, and Outlook). Whilst younger recipients prefer mobile devices, staff and alumni prefer a mixture of mobile and desktop.

Pinpoint the crucial issues

To determine the source of the problem, we carried out extensive testing using Litmus to identify the problem.

Inconsistencies between email clients and operating systems provide different results in dark mode. Most notably colours render differently. Whilst most images are unaffected, Gmail inverts smaller images such as small social media logos.

The diagram below details which operating system and email client combinations experience problems.

Caption: The results from extensive testing to identify which email clients and operating systems experience a problem in dark mode

What is the biggest problem?

The dark mode function inverts colours. All colours coded in the email can be affected. Colours of banners, call-to-action buttons, and hyperlinks, shift in colour.

Like all brands, the University provides a range of colours to create a visual impact and to distinguish the brand. But would these colours be affected by the dark mode colour shift?

The answer is yes. The chart below depicts what happens to our brand colours in dark mode and across several email clients. The result looks like a piece of modern art.

Caption: This may look like modern art, but is the colour shift of our brand colours in dark mode

Where the brand colour Marine 1 is utilised in our campaign emails, the colour will become lighter in dark mode. Whilst the lighter Marine 2 will become darker. This colour shift will affect the effectiveness of any button or hyperlink.

The challenge is to choose colours less affected by the colour shift for each part of our email template. With the help of Steve Wise, another member of the Digital User Experience team, we reviewed the test results to identify how to resolve the issues.

Redesign of the email template

Our testing identified that simpler email template designs are the best for replication in dark mode. The areas of improvement included:

• simplify the template design,
• ensure template is accessible and renders through all email clients,
• remove background colour in content blocks,
• introduce a single image replacing the header banner and logo,
• simplified footer,
• develop different social media icons

Creating the code to target dark mode

The coding has been a challenge. Not all email clients work the same way. Each element needs specific code for each email client and operating system.

Using the Litmus system, each piece of code was tested. Some worked, most did not. We conducted a total of 3,000 email simulations before we created a stable working template.

We developed separate code to create the email style, CSS, to target specific operating systems and email clients:

@media (prefers-color-scheme:dark) controls elements for Apple Mail and iOS.

[data-ogsc] controls elements for Android and Outlook.

Specific code targeting Microsoft Outlook, ensures text inverts correctly and is readable on a dark background. Without this inclusion, Outlook may not invert text correctly.

The key with any development is to ensure that the email looks and renders the same through all email clients.

Caption: The new University email template renders correctly in dark mode, thanks to some extra code

Hyperlinks and accessibility

Hyperlinks provide a link to external content and are identifiable by underlined text. This underline can cause readability issues as it cuts through any text with a dropped tail (g, j, p, q, and y).

Through code, we can remove the underline and replace it with a padded borderline below the text.

During testing, we found that Outlook removes this border and would need more code to insert the underline to hyperlink text. More code is not better.

The decision here is to retain the standard underline to hyperlinks. It works through all email clients and is a simple solution.

Implementation

The email template will be used in a broad range of CRM applications (Microsoft Dynamics, Connect, Mailchimp), each requiring separate templates. Depending upon the system, we will implement new code to allow the template to function correctly in the CRM system.

In Summary

We are pleased with the progress to redevelop our template, to better address the challenges of dark mode compatibility.

We’re looking forward to seeing how our users will respond to the new template as we start to integrate it into our upcoming campaigns and wider communication.

Many thanks to all my contributors: Doug, Steve, Ayala and Jonny.

Links to articles and further resources:

• by 99Content *
• by Night Eye **
• by Litmus
• by Business of Apps

What is a design sprint?

In a nutshell: design sprints help solve big problems in a short period of time by exploring and discussing ideas. They help generate a strong, effective solution to a problem. In this particular case it was around undergraduate course pages.

Ironically, design sprint is not just about the design. The challenge may actually be more about the functionality or the content than the design. The process for design sprint is a very structured design thinking process, and it translates business objectives into actionable insights in just a few days.

Sounds great, right? But in reality what does it mean?

You can’t fight silos with silos

“We tend to get caught up in busy work — attending meetings, shipping one feature at a time; eventually losing sight of our north star.” –

Most organisations know what their biggest challenges are. Although, it can be tricky to reach a shared understanding of a problem, and even harder to get to a solution. This is especially true when you operate in a large organisation like our university, where responsibility and accountability to a business problem might be scattered amongst individuals, departments and directorates.

An example of organisational silos��

So, how do you align siloed teams to come up with a plan? You got it – enter Design Sprints.

We ran a design sprint

We were lucky enough that Winchester School of Art’s (WSA) campus opened their doors to us, and we assembled a small team of digital ‘experts’ from disciplines of User Experience (UX), tech development, content strategy and design, user research and product. We also invited Alastair and Adam, our academic colleagues who have deep interest in human centred design and Andreea, a 2nd year Game Art and Design student to be part of our team to add extra knowledge, expertise and represent the student voice.

It was intense few days. For me, it was great to see the power of bringing a group of experts to one room for 4-days and solve a problem or answer a question. It was great to see how , one of our Service Designers, facilitated everyone through a process that helped align the team around what we were looking to solve.

By the end of the sprint, the team have come up with a potential solution, sketched it, built it  –  and what’s best, they have tested it with real users.

Source: ��

Alan and I thought to share with you a summary of some of the highlights from the process, including some great little clips we took to allow you peek into what we’ve learned and what we would do differently next time. Here we go:

Day 0 – 8 May

Unlike typical sprints, we actually started the process a week before by challenging the current university’s brand proposition. We didn’t want to discard the current work done on the Undergraduate campaign and brand work, but we felt it is important to understand who we’re designing for and how we can build on it in order to create a superior experience online. The outcome of this workshop with senior managers and executives was to set out the brief for the design sprint the following week.

Day 1 – 13 May

Coming into Day 2, most of us didn’t know what to expect. Although the majority of us have participated in design sprints previously, we’ve never worked together in this way. This is because many of our OneWeb team members are new to the university, and because we are not co-located, so haven’t had the pleasure working with each other in this way.

The day was spent sharing information, assessing the opportunities and aligning the team around a common goal. We heard about 8 May workshop, I set the context to OneWeb and the university’s vision, Nick talked about user research. We had data and insights from previous work and we agreed on the design sprint objective and questions we’re looking to answer.

The latter part of the day was starting to sketch ideas individually so we can talk about it the following day. This part was very hard, especially to those of us who are very familiar with the sector and our website. We also had time constraints and had to come up with something within 40 minutes. It’s amazing what time boxing can do to push everyone to the next level!

Some of the many sketches from the day

������’s on his first day.

Day 2 – 14 May

After spending day 1 sketching and ideating, we spent the morning talking through each idea. Alan did a great job presenting each idea. We also walked around the rooms and halls and voted for the ideas that we liked the best.

Alan in action: presenting our ideas

The final casting vote was with me, as the Product Owner for the user experience. It was really hard because there were so many worthy ideas. But the decision was made and the next step was to storyboard what we’ve agreed on in more detail. That’s where we got to at the end of the day.

��Adam did sharing his thoughts of day 2.

Day 3 – 15 May

Prototyping day. We agreed roles and responsibilities in the morning and Alan reminded us all of what we’re here to do. So, with lots to do, the team worked on the prototype, splitting up the tasks and using Invision to create something we can test with our users. It was a long day, not without its challenges.

Day 4 – 16 May

Testing day. When all your hard efforts make sense. A very exciting day for the team to hear first hand what our end users really think of the prototype. Nick, our User Researcher, conducted 6 interviews.

We had issues with some no-shows, but thanks to our lovely student, Andreea, we were quick to fill in any gaps. We also used this opportunity to test it with some Postgraduate students to check what elements are common patterns to both user types.

The outcome

We felt that we were much better informed about our solution, and we’re clear about the next steps we need to to take. We had some first sketch of design principles and ways of working, which we will write up properly and communicate with you all.

We also managed to answer all our sprint questions and feedback from users brought up some additional elements that we need to take into account. The bottom line – we know what we need to do in order to make our course pages better. All of it, in just a few days.

Lessons learned

As with everything, we know there are things we should change, and areas that didn’t quite work for us.

• We had some users’ feedback on areas that we still need to consider.
• There is always a temptation to bite on more than you can chew.
• Too many user interviews, but some didn’t show up.
• We’re thinking that it would be useful to have some contingencies planned in this area.
• We all have biases and also too many great ideas!
• As a group, we like talking! Definitely less talking, more doing.

What’s next

In just a few days the team had outlined a goal, defined and validated a concept and knew what it would take to achieve that Vision to help us deliver for 31 July and beyond. We created alignment around the problem and validated solutions with real users and got actionable feedback. Design sprints can save the university a lot of money in the long run.

As part of the OneWeb programme, we are now considering how we built it into regular chucks of work and get more of YOU to be involved in this process. So, with our news and show and tells. More on this soon.

If you would like to understand more about this project and how it fits in with the wider OneWeb transformation, you can read my blog post: “We’re building better course pages, here’s how you can help”. ��

What were the goals of the course pilot?

In a world of frequent disruption, innovation and change, we are looking to the future of higher education and how the University can play a bigger role in this space, ��by developing digital products that fit with our values and strengths, but also by meeting the needs of our users. Specifically for this pilot phase, our aims were:

• Develop governance for course pages
• Encourage more prospective students to take the next step. For example: come to an open day, or apply for a course

OneWeb Mission Patches

Where are we now?

We just wrapped up the last 10 weeks of the project. We focused on:

• Research – understanding the landscape and gaining insights
• Initial proposition, design and development of our governance and workflow, and building and testing course page prototypes ��
• Understand users’ needs and gain a deeper understanding following the stakeholders’ workshops last November

What we did

The first two weeks were full of planning, gathering and understanding – coming to this project with a true open mind and as few assumptions as possible. We kicked off this project with Institutional Research (IR), we also spoke to FARs and their teams, and started on detailed research and recruiting participants.

In recruiting for our user research, we used the following criteria:

• Undergraduate applicants
• Predicted high achieving grades
• Specifically interested in our sample courses chosen for this pilot
• Have the predicted grades that these courses accept
• Domestic students

The testing was conducted remotely on desktops. There is another piece of research planned for mobile phones only. The three designs we tested were:

• AS IS – our current course pages

Politics and Spanish and Latin American Studies – current (As is) course page��

• HEFCE () – design based on the current , which is already based on solid research ����

– HEFCE course page��

• RAD – stands for Radical design – completely different than what we currently do and heavily utilises the persona work developed ��by IR on this specific audience. We wanted to forget the way it was always done and explore ideas for how else we could do it. We also wanted to introduce more input from current students and highlight how they can make a difference in the world with their degrees.��

– RAD course page��

We ended up recruiting very targeted prospective students. The initial questions were about understanding how they feel about the pages. Down the line we plan to do more specific usability tests to find out more about their actual needs and how effectively our course pages meet them.

What we learned

We learned a lot about the opportunities for governance, workflow and design, and how much digital can help alleviate some of the pains in the current system. Some insights we distilled were related to first impressions, formats, page structure, use of space and well-crafted content that goes beyond the information and transactional element of it.

Other learnings:

• You can never spend enough time with the people who are ultimately going to be using your product / services. There’s just no parallel to spending time with real users. ��
• There are problems that are never anticipated. Again, perceived need could be completely different from actual need.��
• The stakes are higher. Getting the course pages right from the outset and ticking all the boxes from a Search Engine Optimisation (SEO), strategic, technical, brand, content structure and governance point of view will give our University a competitive advantage in an extremely crowded marketplace.

Things we didn’t have time to do

Our Alpha is finished for now. We are really hoping to take it to the next phase (Beta) and keep updating and improving a real product. There’s a bunch of things we would have liked to include in this Alpha version, but didn’t have time to. ������’s some things we’re thinking about doing next:

• More SEO research – ranking, keywords and content
• Mobile testing with our users
• Design iterations based on user feedback
• Usability testing
• Develop an information architecture based on findings from our card sort work
• User journey testing to offer additional level of detail with our RAD designs ��
• Amend governance workflow and retest
• Provide more instructions to colleagues who are Single Point of Contact (SPOCs) and Fact Checkers

Next Up

We are currently in the midst of developing our proposition further and we will keep you posted on this pilot and wider OneWeb developments. We are hoping to carry out more Show and Tells in the future, ��as well as completing some of our testing that is already in-flight, and some that requires more of a deep-dive research approach.

So ��for our findings from testing. In addition, if you missed our Show and Tells, you can access the��presentation slides here.

Side note:

We are sorry that due to technical difficulties with the audio, we are unable to share our Show and Tell recordings. If you have any questions, please get in touch.

Thank you for reading.