Designer · Charles Reynolds-Talbot

Be safe; be human

Fri, 20 Mar 2020 15:26:37 +0000

Principles for sane working in insane times

After a full week working from home due to the (COVID-19) coronavirus pandemic, I have observed great differences in human behaviour. Some caring. Some seriously lacking in the human department. It’s clear that with uncertain times, comes uncertain behaviour. CEOs, directors, leaders, managers, etc, need to put the self-created work-machine to one side and remember that everyone they work with is a human being.

8 Principles for sane working in insane times

I’m responsible for a team of 16 people who are all working remotely now, from home. Putting the challenges of technology aside–like getting video conferencing to work consistently–many are struggling. It’s not like they haven’t worked from home before. But they’ve never had to do it for an entire week, not knowing how many weeks they’ll have to keep going for while the world around them is becoming a scarier and scarier place.

When we’re all in the office, we’re on common ground. Everyone’s environment is the same, we’ve got oversight on what’s happening around us and we don’t get that fear of missing out. In isolation, we do share some common ground in that we’re all remote. It’s clear, communication works better when everyone is remote, compared to a few people remotely joining a co-located team. But, one thing that’s not common anymore is the environment each individual is in.

Some people live in houses with a garden, others in studio apartments. Some already have their children home with them, some don’t have children at all. Some are sharing their home-work space with their partners, others have got access to separate quiet spaces. Each individual’s working environment is now different, so you need to be accommodating for a variety of needs and set standards that support the many.

Looking after your people is your job

As a CEO, or director, or leader, or manager, or someone who is responsible for a team of people, it’s your job to look after them. The worse thing you can do, is assume everyone’s environment and circumstances are the same as yours or impose yours on others. I have said a lot to my team this past week to reassure them and intentionally put time in place for the community to come together. The following principles should to be considered by everyone responsible for a team to reassure ways of working.

1. Everyone is still working, just remotely

Your team shouldn’t feel like they have to compensate for working from home–it’s still work. No-one has chosen to work from home for weeks while everyone else is in the office. Everyone needs to adapt and you need to accept that things are different now.

2. Forget the 9-5

I don’t care how many hours my team work right now. The normal 9-5 office hours are imperfect anyway. How many actual hours of productive work do you think people do in the office once you account for all the distractions, context switching and impromptu meetings? “Have you got five minutes for a quick chat”, almost always turns into an hour long conversation. If your team are delivering outcomes and bringing their whole self when they are working, it doesn’t matter if they only work four hours one day.

3. Children are an unexpected reality

I’ve heard of people being docked pay by their employer because they had their children at home this week. The majority of people are going to have their children at home with them from now on. It doesn’t mean they’re not working. Parents working at home with children are dealing with a context-switching-hurricane work environment. It’s volatile; they’re trying to entertain and educate their children and do their paid job.

You need to allow parents greater flexibility to deal with the unexpected reality of caring for a small human. This flexibility doesn’t need to stop with parents. You should apply it to your whole team. If someone needs to stop work and get out of the house for a few hours, in the garden or to the park, they need to feel they have permission to do so. You can give them that reassurance and reassure yourself: the work will happen, just later.

4. Partners are new teammates

Most of the time people would never choose to work with their partner. But a lot of people are now stuck sharing workspace with their partner. They’ve got a job to do too. If they’re in the background of a video meeting or need to take a call at the same time: it’s okay. It’s no different to the background noise and people when you’re in the office.

5. It’s okay to slow down

Work shouldn’t have to be crazy at the best of times so it certainly doesn’t have to be crazy now. There is a lot going on in the world, when suddenly, all of the news feels relevant. You can reassure people–they don’t need permission to take they’re foot off the accelerator and slow down. If someone needs to take a break and come back to something later: do.

6. Be open about your own struggles

People tend to follow authority. As a leader or manager, that means you. The way you work will dictate how your team thinks they should be working. So be open about your own struggles. It’s okay to show weakness and it might actually strengthen your team’s view of you.

7. Make time for communities

Outside of project work and meetings it’s good for your team and the community to make time to get together (remotely). This can be centred around a specific topic or could just be set time for random chat. These side-conversations used to happen naturally in the office whereas now, they might need to be forced a little. Create sessions for a daily coffee chat or a weekly social. Let people know, it’s not mandatory, it’s not another presence prison. If no-one attends the end of week social because they’d rather use that time to be with their families sooner: that’s okay (I know, I’d prefer that).

8. Be safe; be human

None of this is extraordinary, it’s just simple human touches. In times like this, it should be clearer than ever: work is not the most important thing in the world. I hope everyone is looking after themself and their’s. Be safe; be human.

Share the human things you’re doing with your teams: tweet me @charles_rt

The Dark (Mode) Web Rises

Wed, 28 Nov 2018 20:50:37 +0000

This is part 3 in a series about why we need Dark Mode to be an inclusive design consideration.

Molly Watt
Apple need a Dark Mode
The Dark (Mode) Web Rises

In 2016, I met Molly Watt.

I was inspired by Molly and her experience of living with Usher Syndrome; a condition that has left her deaf with 5–degree vision in one eye. I wrote about my immediate desire to solve some of the problems Molly faces with using digital products.

Then, in 2017, I wrote a follow up post on how Apple (and others) need a Dark Mode; a system-level preference setting that would affect the interfaces of native, third-party apps and websites.

This year (2018), we were gifted with an update to MacOS: Mojave. Mojave shipped with a system-level Dark Mode preference setting. Finally!

Turning on Dark Mode in Mojave made instant changes to the system interface and the native Mac apps. Soon after, third-party apps started to release updates that took advantage of this preference setting too; making their interfaces work in Dark Mode. But, there was still a gap: websites.

Whilst the Safari app supported Dark Mode, there was no change to the content of the websites viewed through it. Glaring white websites were still glaringly white. It felt like a giant leap in the right direction but a small step short: until now.

Give yourself to the dark side

Please, allow me to introduce you to the prefers-color-scheme CSS media query.

Media queries are used to modify a website depending on specific characteristics (print, size, orientation, etc).

Now, we have one to detect if a user has set system-level preferences to use a light or dark colour theme.

MacOS Mojave has system-level colour preferences

This feature is not yet ready for use on general release browsers but it’s coming soon. Safari Technology Preview 68 added support last month so hopefully, it won’t be long before this finds its way into a mainstream Safari release.

Add support for Dark Mode on your website

Developers can (and should) start getting their websites ready for Dark Mode. You can install Safari Technology Preview now and start designing the perfect Dark Mode theme using colours that compliment your brand and work consistently across your website.

A simple example, to get you started:

@media screen and (prefers-color-scheme: dark) {
  body {
    background-color: black;
    color: white;
  }
}

Dark by default

You might notice that my own website is dark by default. I have made this decision as it’s not only my preference but I know it works better for Molly and for users in certain scenarios (browsing at night, migraines, hangovers, etc). Designing for the few, makes things better for the many.

I’ve used the prefers-color-scheme CSS media query to target the light preference. If you are using Safari Technology Preview on Mojave and have your preferences set to light you’ll see the light theme of my website.

You do this using:

@media screen and (prefers-color-scheme: light) {
  body {
    background-color: white;
    color: black;
  }
}

The future is dark (a good thing)

I am a designer at the UK government. This series of posts started as a result of wanting to influence the design of GOV.UK (a typically white website) so that it works better for users like Molly Watt.

So far, I haven’t got very far with this. Every potential solution seemed to come with a degree of risk and complication when considering the design principle: this is for everyone.

I reckon that using prefers-color-scheme CSS media query is a risk-free low-impact solution. It will give GOV.UK a Dark Mode for the users that prefer one and remain the same for everyone else. I’m going to prototype this and start pushing to make it happen.

I’m hopeful that, the more websites (and big brands) that implement and blog about their Dark Modes, the more chance we’ll have of seeing this feature across all browsers (not just Safari).

Other platforms need to start introducing their own system-level Dark Mode preference setting to work this way too.

Look out for a similar feature coming to iOS soon.

I can’t wait to see how websites take advantage of this new CSS media query. Share how you use it: tweet me @charles_rt or toot me @crt.

White rabbit

Thu, 25 Oct 2018 18:39:02 +0100

Lately, I’ve been following the white rabbit relentlessly in the hope that if I keep going I’ll eventually stumble upon some life-changing Trinity.

Follow the white rabbit.

This Matrix Metaphor is representative of both the unpaid work I’ve been doing on the redesign of my own website and the paid work I do for UK government.

I’ve spent time worrying about why certain things aren’t working properly and investing too much in trying to find solutions. I’ve blindly ignored good advice telling me to stop—the effort required isn’t worth the reward—and after a while only a mad person would keep going. I am that mad person. Convinced, no. Obsessed, with following the white rabbit in the hope of achieving some self-gratifying win that might make all the effort feel worthwhile.

It’s time to be a quitter.

A lot of times it’s better to be a quitter than a hero…people automatically associate quitting with failure, but sometimes that’s exactly what you should do. If you’ve already spent too much time on something that wasn’t worth it, walk away. You can’t get that time back. The worst thing you can do now is waste even more time. —Rework, Don’t be a hero, Page 118-119

For the work I’m doing on my own website that means quitting the crazy rabbit hole of confusing code and ideas I was falling deeper into. I’d lost sight of the goals I was trying to achieve. I’m rolling back a number of files and will revisit the redesign with a clearer, fresher mind another time.

For the paid work I do that means quitting too. Not quitting my job but quitting getting too involved in certain aspects that, right now, can’t be influenced positively.

Next week is half-term. I’m going to take some time off to spend it with my family. I’m also going to reread Rework that contains advice I’ve been ignoring.

Reset. Rework. Then, keep going on what matters.

Three week sub-1:30 half marathon training plan

Fri, 21 Sep 2018 16:03:51 +0100

Week	Monday	Tuesday	Wednesday	Thursday	Friday	Saturday	Sunday
Week 1	Rest	13.1M Race Pace Test	Cross Train	6.3M Intervals	Rest	Parkrun PB Attempt	13.1M Steady
Week 2	Rest	45min Farklet	Cross Train	Rest	13.1M Progressive	Parkrun PB Attempt	13.1M Steady
Week 3	Rest	45min Farklet	Cross Train	6.3M Progressive	Rest	Parkrun Steady w. Strides	Manchester Half Marathon

Better responsive iframe for embedded YouTube video

Thu, 09 Aug 2018 08:03:51 +0100

I started to include embedded music videos from YouTube on a couple of blog posts, just for fun.

This presented an interesting challenge; YouTube videos are embedded in iframes. You can give them a fixed height and width which ensures they display correctly but then they overflow the screen on a smaller viewport. Alternatively, you can specify a width of 100% which makes the width respond as intended but there’s no way to get the height to comply and maintain the correct aspect ratio.

I searched online and found a couple of solutions; neither of which I was keen on.

Extra HTML

The first common solution I found involved adding an additional div.wrapper around the iframe and applying CSS to both. Whilst this does work, I didn’t want to have to add extra HTML for stylistic purposes. I should be able to do this job using CSS only, on the main element.

Javascript 😒

The second solution involved the use of javascript which I wasn’t interested in. If I can get away with it, I don’t want to use any javascript on this site.

A better solution using calc()

After [a lot of] trial and error, I discovered a great use for calc(). The calc() function lets you perform calculations on CSS property values.

The clever part that makes this work is knowing the width of my main content containing block: 512px. I don’t need to worry about the iframe being responsive beyond this width. I know the width it should be. I can specify the appropriate height for a 16:9 widescreen aspect ratio.

I set width: 100%; as this should always be true even though I know the exact width it makes things simpler later. I then set height: calc((512px / 16) * 9);. Technically, I don’t have to do this. I could calculate the height manually as it won’t change when the width is above 512px but I’ve left the calculation in so you can see what changes later to make the magic happen. (512px / 16) * 9 equals the correct height for a 16:9 widescreen aspect ratio when I know the width is 512px.

When the viewport is narrower than 512px, I use a media query to make the iframe respond accordingly. The width is already set to 100% so I don’t need to worry about that. It’s the height I need to start responding at the correct size to maintain a 16:9 widescreen aspect ratio. The width of the viewport is suddenly very relevant to help achieve this. I am able to find out what the width of the viewport is by using vw as a measurement unit.

vw is equal to 1% of the width of the viewport and the browser knows what this is whenever it changes. I can use the measurement of 100vw in my calculation to track the width of the viewport and serve up the right height to maintain a responsive aspect ratio with height: calc((100vw / 16) * 9);

iframe {
  width: 100%;
  height: calc((512px / 16) * 9);
}
@media (max-width: 512px) {
  iframe {
    height: calc((100vw / 16) * 9);
  }
}

That’s it: a better responsive iframe for embedded YouTube videos using CSS only, on the element.

Dat’s the way I like it

Fri, 03 Aug 2018 19:10:07 +0100

I committed to supporting a decentralised peer-to-peer web by serving my site over dat:// as well as https://. Since starting this I have been stumped as to how to make my url over dat:// friendly, because dat://59278ae8cc9d27492b4a0a5d4392ff3c913aebd8fa079760ce732f26b70c4eef (open in BeakerBrowser) is just mean.

I could see other sites had achieved this. Beaker’s own site does exactly what I wanted with dat://beakerbrowser.com/ (open in BeakerBrowser).

I read several docs about it and kept getting confused to the point that I’d give up, hoping to return later with a fresh mind and try again.

Eventually, I have succeeded and it is ridiculously easy so I’ll share a simple step-by-step guide so you don’t have to do through the same pain.

Create a folder called .well-known in the root of your https:// served directory.
Create a file called dat in that folder.
Add the following code to that file, replacing {key} with the mega long dat URL key to your site. Fe, dat://59278ae8cc9d27492b4a0a5d4392ff3c913aebd8fa079760ce732f26b70c4eef
```
  dat://{key}
  TTL=60
```
Save and upload to wherever you host your https:// site.
Now, visit your site in BeakerBrowser but use dat:// instead of https:// as the URL and automagically it works 🎉

dat://charlesrt.uk is finally working and it turns out it was easy peasy hotdog squeezy.

This is my baseline

Thu, 26 Jul 2018 16:47:08 +0100

I’m throwing caution to the wind and forgetting about global CSS resets like normalize.css and Eric Meyer’s reset.css because:

I’m not convinced I need to make use of everything in these resets (I don’t even know what <kbd> is 🤷‍♂️) or support all the browsers they attempt to. Does it matter if someone visits my tiny website in IE8 and something doesn’t look perfect? I’ll give you a hint: no.
They’re pretty bloated because they’re trying to fix everything for everyone. I don’t need 341 lines of code before I’ve even written a line of my own.
There’s no point in resetting something that I’m just going to override later. I should declare the values I want to set and forget the reset.

This is my master plan: to lay only the CSS foundation I need to—when I need to—and layer on my opinionated component styling to serve as my own default for building websites: my baseline.

My Baseline

This post is out of date relative to the CSS I’m currently using on this site. I will update this and create a repo as soon as possible.

:root {
  font-family: system-ui,
               -apple-system,
               BlinkMacSystemFont,
               "Segoe UI",
               "Roboto",
               "Oxygen",
               "Ubuntu",
               "Cantarell",
               "Fira Sans",
               "Droid Sans",
               "Helvetica Neue",
               "Apple Color Emoji",
               "Segoe UI Emoji",
               "Segoe UI Symbol",
               sans-serif;
  font-size: 16px;
  line-height: 1.5;
  overflow-wrap: break-word;
  -ms-text-size-adjust: 100%;
  -webkit-text-size-adjust: 100%;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  -webkit-tap-highlight-color: transparent;
  background: black;
  color: silver;
}
body,
blockquote,
figure {
  margin: 0;
}
main {
  display: block;
  max-width: 512px;
  margin: 0 auto;
  padding: 0 1em;
}
h1,
h2,
h3,
h4,
h5,
h6 {
  font-weight: bold;
  font-weight: 800;
  line-height: 1;
}
h1 {
  font-size: 4rem;
  margin-top: 4rem;
  margin-bottom: 4rem;
}
h2 {
  font-size: 2rem;
  margin-top: 4rem;
  margin-bottom: 2rem;
}
h3 {
  font-size: 1.5rem;
  margin-top: 2rem;
  margin-bottom: 1rem;
}
h4 {
  font-size: 1rem;
  margin-top: 1rem;
  margin-bottom: 0.5rem;
}
p {
  margin-top: 1rem;
  margin-bottom: 1rem;
}
a {
  color: aqua;
}
a:link,
a:visited {
  color: aqua;
}
a:hover,
a:active,
a:focus {
  color: yellow;
}
img {
  max-width: 100%;
  height: auto;
}
figcaption {
  color: gray;
}
pre,
code {
  background: navy;
  color: gray;
  font-size: .875rem;
  letter-spacing: .05rem;
  padding: .125rem .25rem;
}

Let’s break it down.

Images

One of the immediately obvious problems viewing my website using only native browser styling is how images are rendered: huge. Well, full size to be fair, but in all circumstances that full size is much bigger than your average viewport. On mobile it’s just ridiculous so let’s add some CSS to take care of this.

img {
  max-width: 100%;
  height: auto;
}

By using max-width: 100%; images will confine themselves to the <figure> element and stop overflowing the viewport. Aspect ratios are kept in check with height: auto;

Before

Clearly there's a problem with lack of default img styling.

After

Much better. Now you can see me, Chris and the legendary Jake Knapp.

Margins

Now my images are in control it’s clear there are some unwanted margins present. It might be necessary to play with the content rhythm later but that’s a conscious design decision that’ll need be made. In the meantime everything should be aligned consistently.

body, blockquote, figure {
  margin: 0;
}

Before

Browser defaults have made design decisions for me.

After

Consistent alignment but too close to the edge.

All content is now aligned to the very edge of the viewport and is only constrained by the width of the users browser. This isn’t ideal and can make for some lengthy reading lines.

I’m going to solve this problem by wrapping the dominant content of the page in a <main> element with a maximum width of 512px. This keeps line lengths appropriate for better readability. The content block is centred with auto margins left and right, while a little padding keeps content off the edges of smaller viewports.

main {
  display: block;
  max-width: 512px;
  margin: 0 auto;
  padding: 0 1em;
}

Better

If only, browsers did this by default.

Typography

I’ve already started to address some typographic defaults by setting a maximum width on the content to maintain a readable line length. Time to get serious.

System fonts are the new black. All browsers should use system fonts by default. This means my website will use the same core font as the device you are using. Fe, San Fransisco on iOS or Roboto on Android.

Let’s go through them:

system-ui is future proofing this concept and the latest versions of Safari and Chrome already use this so eventually we don’t have to maintain a huge stack.
-apple-system, BlinkMacSystemFont is for Apple device users and dynamically uses the correct font depending on size between San Fransisco and San Fransisco Display.
"Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans" take care of every other operating system I could find.
"Helvetica Neue" is for legacy Apple devices.
"Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol" force the use of the devices emoji fonts which are often more up-to-date than the browsers.
sans-serif if all else fails.

Not all browsers share the same font-size and line-height so setting defaults for this ensures consistency and provides a base to build off. 16px and 1.5 are a great default for better reading.

On occasion, I display full URLs as part of links in content. If lengthy, these can overflow the <main> container and cause some unwanted side-scrolling. overflow-wrap: break-word; stops this from happening.

The text-size-adjust declarations stop mobile browsers from scaling your text causing rendering issues. Why they do this: I don’t know.

It’s good to use font-smoothing to make text lighter and easier to scan. This also helps prevents occasional flicker on load or scroll and takes some load off browser performance too.

Finally tap-highlight-color hides the flicker that happens when you tap an element on mobile devices. I’ll need to ensure I have suitable hover states later so users get feedback to their interaction.

:root {
  font-family: system-ui,
               -apple-system,
               BlinkMacSystemFont,
               "Segoe UI",
               "Roboto",
               "Oxygen",
               "Ubuntu",
               "Cantarell",
               "Fira Sans",
               "Droid Sans",
               "Helvetica Neue",
               "Apple Color Emoji",
               "Segoe UI Emoji",
               "Segoe UI Symbol",
               sans-serif;
  font-size: 16px;
  line-height: 1.5;
  overflow-wrap: break-word;
  -ms-text-size-adjust: 100%;
  -webkit-text-size-adjust: 100%;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  -webkit-tap-highlight-color: transparent;
}

Before

This looks a little unpleasant and the browser doesn't understand the latest unicode [emoji] characters.

After

A much better default.

Colour

Colour choice can be highly opinionated—such as my desire for ‘dark by default’ user interfaces—but there’s sound reason behind it you can read more about in Apple and others need a dark mode for people like Molly Watt.

Where possible, baseline colours should aim for strong Level AAA contrast ratios. Whilst Level AA is the minimum, there is rarely a need to go so low and higher contrast can be better for everyone. However, go too high and you could be introducing unwanted glare.

Be mindful of the colours you choose. This is where colour choice is less about opinion and more about responsible selection and use.

Another thing to be mindful of is links. Links are the cornerstone of the internet so it’s surprising they’re still not handled well by default.

Hover states should always be honoured regardless of whether the link has been previously visited or not. On that subject, visited links don’t need their own distinguished style; they should be styled the same as regular links. Don’t forget about focus states for keyboard users.

:root {
  background: black;
  color: silver;
}
a {
  color: aqua;
}
a:link,
a:visited {
  color: aqua;
}
a:hover,
a:active,
a:focus {
  color: yellow;
}
figcaption {
  color: gray;
}
pre,
code {
  background: navy;
  color: gray;
}

After

Dark by default; Level AAA colour contrast.

Font size and margins

A lot of CSS resets aim to do just that: reset. They take away any browser styling and make everything the same so you can declare the values you want after—but. You can do this anyway. There is no need to reset a value. Just declare your own from the outset.

I enjoy working with multiples of 8 and only tend to deviate for certain elements. You can achieve good progressive size and spacing this way: 8px 16px 32px 64px 128px.

I use rem as it’s easier to work from my root em measurement which is 16px.

h1,
h2,
h3,
h4,
h5,
h6 {
  font-weight: bold;
  font-weight: 800;
  line-height: 1;
}
h1 {
  font-size: 4rem;
  margin-top: 4rem;
  margin-bottom: 4rem;
}
h2 {
  font-size: 2rem;
  margin-top: 4rem;
  margin-bottom: 2rem;
}
h3 {
  font-size: 1.5rem;
  margin-top: 2rem;
  margin-bottom: 1rem;
}
h4 {
  font-size: 1rem;
  margin-top: 1rem;
  margin-bottom: 0.5rem;
}
p {
  margin-top: 1rem;
  margin-bottom: 1rem;
}
pre,
code {
  font-size: .875rem;
  letter-spacing: .05rem;
  padding: .125rem .25rem;
}

8 16 32 64 128.

Making progress

Wed, 25 Jul 2018 10:23:59 +0100

Things are still looking basic but I'm making progress

I’ve had some time away and I’m mostly relying on train journeys to make updates so progress has been slow but I’m getting somewhere.

All of the important content from my previous website build has been migrated and is better structured from a directory perspective. Redirects are in place to ensure I don’t break the web and I have a Gulp task running to compile Stylus (my preprocessor of choice) into CSS.

I’m ready to think about my design goals and how I will structure the content better for the user so that navigation is contextual and I’m getting across the right message and flow.

Before that, I’m going to consider what a good baseline CSS should be.

Style.less

Wed, 11 Jul 2018 09:54:15 +0100

No style here

Right now, things are looking a little basic.

Style Attribute {
  🤷‍♂️
}

The plan was to get the website up and running and let your default browser styles do the work, then carefully layer on top the bare minimum required to achieve the design goals I set.

You’d think I would have done more research into Hugo before choosing it as the framework to rebuild my website. It turns out it doesn’t natively do any CSS preprocessing. I don’t know why I assumed it did—I guess because so many static site generators do.

This isn’t the end of the world—I do know how to write in vanilla CSS—I’ve just gotten used to writing in syntax, like less, and taking advantage of the power that has to offer, such as variables, mixins, etc.

Not to worry. I’ll take a small break to add some sort of Gulp task and do some of the mundane work that needs doing first; like migrating all my old blog posts and making sure redirects are in place so as not to break the web.

Design goals

Wed, 11 Jul 2018 09:40:39 +0100

Design decisions will be based on a combination of the assumptions I make on what people might want, and the message and flow I want to get across.

I also want to achieving the following goals:

move away from Jekyll and build my site with Hugo which I’ve had my eye on ✅
use only contextual navigation; no “I don’t know what I want” menu
focus on typography; include emoji (the universal language of the future) at every opportunity 😉
allow for long and short form posts
create an owned space for my content to exist first before sharing to centralised social networks.

I’ll add to and revisit this list of goals as I go.

Hello World

Wed, 11 Jul 2018 08:24:18 +0100

A screenshot of my zero dawn refresh served over the peer-to-peer web via Beaker Browser. It works!

I have been meaning to redesign my website for a long time. I want to do more than just another re:skin so I am starting from scratch and designing the site live; partly to open my process to others who want to see and learn, partly to hold myself accountable so I do it properly.

Live design: means more than just having my code commits in the open on Gitlab. Instead of large wholesale design changes magically appearing on the internet, each individual change I make can be tracked live over dat:// the peer-to-peer web, enabled by the Dat Protocol. If you use BeakerBrowser you can turn on live reloading, to experience changes and blog updates auto refresh, as they happen. This, essentially, allows me to create a live blogging engine without any additional code.

You will still be able to refresh [the old fashioned way] over https:// if you use any other browser.

I can’t promise I will blog about the reason behind every design decision: but I will try.

This, is all part of my commitment to support a better, open and decentralised web for the future.

Drafts Zero challenge

Wed, 24 Jan 2018 13:51:40 +0100

This morning I wrote a response to Jake Knapps article on going fast to stay authentic. He was so right! I’d been writing all wrong.

The message is to not overthink your writing. The majority of the time, the thing you write first time—in the moment—is good enough. Spend too long deliberating and you run the risk of watering it down.

After sharing this to Twitter, I realised you run another risk—you never publish at all.

Too many drafts. How familiar is this view?

You might have heard of Zero Draft; your first unstructured attempt to write down your thoughts as they flow from your mind. A lot of mine—and maybe your—drafts never become more than that.

Today, I propose a challenge to achieve Drafts Zero.

Every day—excluding weekends—I am going to spend 15 minutes (no more) on finishing and publishing a draft, starting with the oldest.

Drafts Zero

It doesn’t need to be perfect, it needs to be done!

Get it out in the open and forget about it. Maybe no-one will read it (no-one will read it in your drafts), or maybe it will spark an interesting conversation. Maybe it will even inspire someone else to do the same.

I write for me, and with that mindset I might be happy never publishing, but I’m not. I want to validate my assumptions and ideas. I want to be challenged on them. Plus, every now and then, someone Likes what I write—we all want appreciation, don’t we?

I’m weirdly excited by this experiment. I hope you get involved and join me. Let’s get social and spread the word with the hashtag #DraftsZero every time you publish. I will write about how the challenge went at the end.

See you in the open.

This idea probably only works with short-to-medium-form content. I wouldn’t recommend you write a book this way, though maybe that would make an interesting experiment too.

Design Sprint in a day

Tue, 12 Sep 2017 07:00:00 +0100

Jake Knapp used to work at Google Ventures. During that time Jake developed a process to help teams test their ideas and get market feedback early, rather than spend years designing and building a thing before getting any data on whether it works. The process that came to be, was a Design Sprint.

(Left to right) Charles Reynolds-Talbot, Chris Taylor and Jake Knapp

Since that time Jake has run over 150 Design Sprints with teams in a variety of companies, from Slack to Blue Bottle Coffee, and published a book about the process called Sprint.

Recently, Jake left Google Ventures to pursue a passion for writing, whilst consulting and running workshop training sessions on the Design Sprint process. One of those workshops was a single day session at the beautiful Tate Modern in London, presented by Clearleft.

By now, you’ve probably guessed that this post isn’t a guide on how to run a Design Sprint in a day—I wouldn’t recommend that. You might be able to condense certain elements to make for an efficient and productive day, but it’s not a Design Sprint. You need to invest a full five days of time into a Design Sprint to reap the rewards the process provides.

This post is instead a review of Jake’s workshop and a recommendation that—if you’ve read this far—you should attend one, given the opportunity.

Welcoming the teams

Life by Keynote

The day started with Jake giving a bit of a history lesson about him and his experiences that led to the creation of the Design Sprint process, before getting into the detail on what you should do as a facilitator on each of the five days.

Throughout this, Jake had crafted a series of stories that helped to give context and perspective to each part of the process, supported by a well-designed slide deck and a light-hearted delivery.

Far from Death by Powerpoint, I was surprised at how engaged I was throughout. I don’t think I yawned once. This is important right, because when you’re bored you disengage. When you disengage you switch off, and then you’re not learning anymore. Jake keeps your attention in the palm of his hand throughout and as a result delivers an incredibly refreshing learning experience.

Even the icebreaker was genius. I won’t spoil it, you’ll just have to attend one the workshops.

Life by Keynote

Validating interpretations

The single-day workshop I attended focussed on the hardest days—Monday and Wednesday—where you map the flow from discovery to your customers/users achieving their goal (Monday) and make a decision on the moment in time (Wednesday) to focus your prototype and test on.

Tuesdays sketching exercises were another main feature of the workshop, probably because they’re practical and therefore easy to get a room involved in. I got less value from this section as it’s one of the days of the Design Sprint I find [surprisingly] straight forward. Especially when people I think will be reluctant to sketch, get involved no problem.

Jake did unpack some more detail behind the Lightning Demos, which was welcome to see a focus on using agnostic design patterns for inspiration.

Our art was literally on display at the Tate Modern

Prototype and test (Thursday and Friday) were covered at the end by way of a whole room discussion, which was useful to hear other peoples questions and pain points from the process.

Jake also talked about things that didn’t made the final cut of the Sprint book, such as metrics. While metrics might be too specific to quantify for some teams, it is important to have measurable outcomes so you know you’ve succeeded in doing the thing you set out to do.

Throughout the day; a combination of Jake diving into the detail and practical team exercises you get familiar with the nuances of the process which you don’t necessarily get from reading the Sprint book.

I’ve read the physical book and have a digital copy on my iPhone for easy reference. I have run several Design Sprints myself and even wrote about one I did in government that was published on sprintstories.com. And—if I’m honest—while the day for me was really an excuse to meet the legend himself and get a signed copy of the Sprint book, I still found it invaluable.

It’s important to validate your own interpretations from reading the book and running your own Design Sprints.

Designing time

One of the key messages I took away from the day was the true value of a Design Sprint.

Ideas and data about a product or service might be the obvious outcome you get from running one, but a Design Sprint is really about designing time.

Design Sprints help people save time.

🙌

Apple need a dark mode

Fri, 18 Aug 2017 08:00:00 +0100

This is part 2 in a series about why we need dark modes to be an inclusive design consideration.

Molly Watt
Apple need a dark mode
The dark web rises

Last year, I met Molly Watt.

Molly has Usher Syndrome; a condition that has left her deaf with 5–degree vision in one eye.

Laptop glare in a dark setting by Jay Wennington on Unsplash

Molly is still a visual person. One of the problems Molly has when interacting with digital services is high contrast, specifically white backgrounds with black text.

I am a designer at the UK government. GOV.UK pride themselves on championing the needs of users, designing inclusively and building digital services that are accessible to everyone. Yet, the website is practically all white background with black text. It creates too much glare and makes it impossible for Molly to focus. It’s unusable.

The challenge

How might we allow people to change the text and background colour to suit their needs, without effecting images, video, meaning or brand?

Starting with one thing

I started with the assumption that a style switcher would solve this problem—by designing a toggle that would let users switch between a light and dark mode when needed.

GOV.UK prototype to test an idea

Reading the content in dark mode would be bearable for Molly, and might benefit others too—enhancing the experience for a user with a headache, or someone browsing in a poorly lit room. Designing for the few, makes things better for the many.

Thinking of the many

I then thought about people who have different access needs to Molly. People whose needs could be met with a similar solution. Molly’s own website has a classic accessibility toolbar, allowing people to switch between a number of different colour combinations and even change the size of the text.

Designer Craig Abbott recently implemented a great version of this on his own website that includes the ability for dyslexic users to change the typeface to one that provides increased readability for them.

There used to be a lot of websites during the 00s that had these accessibility toolbars, but it’s something that seems to have fallen out of fashion. Surely, if we build one of these for GOV.UK, that will solve the problem.

The toolbar on Craig's website is great, until you leave

Well—while the outstanding efforts to make these websites more accessible should be celebrated, neither really solves the problem. These solutions exist in a vacuum. As soon as the user navigates to a different website that doesn’t have one of these toolbars, the customisation is lost and the experience is broken. Even if the next website did have one of these toolbars—so the option was available to make it more accessible—it wouldn’t know the settings from the previous website, so the user would always be starting from scratch. This isn’t inclusive. It’s a hack, and maybe that’s OK for now—but. We need something better.

Something slightly better

People need a way to change the text and background colours consistently, across all websites to better suit their needs. The BBC have guides on how to do this on your computer, but I wouldn’t say the steps in these guides are easy for everyone to follow and they’re still a hack.

Also—at the time of writing, people use their mobile device more than they do their desktop computer, so those guides won’t help more than half the time.

We need to be providing inclusive design solutions that meet the demand and expectations of the digital era we live it today.

Apple (and others) need to solve this problem

Molly is 22 and like most people her age, uses her iPhone and iPad to access the internet and stay connected.

Apple provide in-built accessibility features to help people with access needs use their technology which is brilliant—but. One thing I don’t think they do very well, is shout about it enough. I would love to see Tim Cook talk passionately about how Apple are making things easier for people with access needs. Unfortunately, this year I think we’ll instead see overly-excited cheers at new emojis.

Some of the new emoji coming to iOS, macOS and watchOS later this year

Molly has talked and written about how Apple products have made her feel less excluded from society, which is great. But, one thing Apple haven’t yet implemented is the option to switch to a true Dark Mode, that would make changes across the Operating System (OS), native Apple apps, third-party developer apps and web browsing.

Apple (and others) need to be making inclusive design considerations for in-built accessibility features like a Dark Mode that just works, without the need for continuous tinkering or hacks.

Everyone should be able to customise their settings for a consistent accessible experience across all their devices, so they can interact with and consume content without barriers.

Apple might be getting smarter

On iPhone and iPad there has been the option to Invert Colours. You can map this as an accessibility shortcut, so when you triple-click the Home Button, the colours will invert (white to black, black to white, etc).

The problem is that this inverts everything, which makes images unusable, brands unrecognisable, and can create confusion in interactions that previously had clear context. Inverting everything also causes a previously dark interface to become glaringly bright, which is not a solution to the problem.

There is a new feature coming called Smart Invert, which can be found in the public beta of iOS11. Unlike Classic Invert (as it is now called), this does not invert everything and appears to be a baby-step towards to a true Dark Mode. Previously bright interfaces like Mail and iMessage, become dark. Interfaces that were already dark like Clock and Calculator, do not change. Likewise, the Home Screen doesn’t change much and your photos stay the way they were supposed to be.

I am unable to take any screenshots, as weirdly the images end up re-inverting themselves which I’m hoping is a bug. 9to5mac have some good images of Smart Invert in action.

Unfortunately, third-party developer apps still mimic the Classic Invert, so everything, including images are changed. This means apps like Instagram are rendered unusable and Twitter—which already has it’s own Dark Mode option—is flipped for the worse. Browsing the web is just as difficult as it was before.

I hope that this is something that app developers will eventually be able to take advantage of, by specifying which parts of the interface should and should not change when using Smart Invert.

However, this would still need developers to make the decision to implement this, and there are no guarantees they will. Especially depending on the size of the app, this may end up being perceived as too much work to bother. Likewise, I have no idea how this would work with browsing websites, but if it required every website developer to do something, it would never happen.

So, this new feature should really be called Slightly Smarter Invert But Not Smart Enough.

So, what is the solution?

I don’t know.

Right now, we have a series of different hacks.

Some of these hacks put the responsibility on designers and developers to implement one-off solutions that will only work on their app, or website.

Others require the user to know a decent amount about their technology in the first place, to know how to successfully configure their device when it’s an option.

And then there are the things that you need to know even exist, before you can start taking advantage of them. Accessibility features just aren’t shouted about as much as they should be.

GOV.UK could, and probably should do more research into an accessibility toolbar, because the information and services on that website are meant for everyone.

Beyond that, we need companies like Apple, Google, Windows and others that design and build OSs, devices and browsers to consider the needs of users like Molly and solve the problem once, to solve it everywhere.

Interaction design: Clearing the confusion

Mon, 10 Jul 2017 08:00:00 +0100

As a lead designer, it’s my goal is to help shape the user centred delivery of projects by raising the quality of interaction design—the work we do and the part we play in multidisciplinary teams.

I’ve noticed confusion about what interaction design is, what interaction designers do and when’s the right time to get them involved.

Design is a good idea

Design exists under many guises; policy design, organisation design, process design, infrastructure design, security design and so on.

Interaction Design (IxD) defines the structure and behavior of interactive systems. Interaction Designers strive to create meaningful relationships between people and the products and services that they use, from computers to mobile devices to appliances and beyond. —Interaction Design Association

It’s often perceived that user centred design costs more and delays delivery—but. Interaction designers want to deliver early and often. Delivery isn’t just about delivering working software, it’s about delivering measurable value. The sooner we can get something into the hands of real users, the sooner we can start learning at scale.

Research is invaluable when building empathy with users and understanding their needs and motivations. When we’re confident we’re building the right thing, we want data to help us realise what works and what doesn’t. We can then target future research more effectively and learn something new, iterate our solution, deliver, relearn, reiterate, repeat.

De-risking assumptions and gaining confidence you’re on track to deliver your outcomes are the returns you get when you invest in user centred design.

Knowing the right level of interaction design

A building call system, with buttons mixed of different colours and shapes

People tend to think of design in 1 of 2 ways: design is look and feel, or design is how it works.

I think design has 4 levels. The stage your project is at will dictate the level of design it needs.

Level 1. Design is solving problems.

First and foremost, interaction designers are problem solvers. They use design and mapping techniques to help teams define the problem and frame it in the right way.

Level 2. Design is how people behave.

Before diving into solutions, it’s important to understand how people behave and what they are trying to do. Interaction designers work closely with user researchers at this level to start building empathy for and better understand the needs of users. This might even redefine the problem.

Level 3. Design is how it works.

This is where interaction designers help create solutions that are easy to use and understand. They’ll prototype these solutions—often in code because interactions are made of code, not mock-ups—to test ideas with users and iterate based on feedback.

Level 4. Design is look and feel.

This is about making it beautiful, but it’s also about making it easy to navigate, increasing legibility and reducing cognitive load. It’s often mistaken as the only role interaction designers play.

Interface/visual design is important and many organisations prioritise form over function. Apple is very good at form. It’s important that interaction designers understand how form and function work together, but there’s less emphasis on interface/visual design. Instead, interaction designers should spend time solving new problems.

Together, these levels allow for user-centric design thinking that solves problems creatively and collaboratively.

Designers beware

Secret Level 5. Design is changing the world.

Designers want to feel like they’re doing something that matters. But not everything needs to be torn down and transformed wholesale. Sometimes you just need to solve the small problem in front of you, right now.

The client asks you to design a business card. You respond that the problem is really the client’s logo. The client asks you to design a logo. You say the problem is the entire identity system. The client asks you to design the identity. You say that the problem is the client’s business plan. And so forth. One or two steps later, you can claim whole industries and vast historical forces as your purview. The problem isn’t making something look pretty, you fool, it’s world hunger! —Michael Bierut

It’s important to remember—just making products and services that work better for the people who need to use them is still innovative, radical and disruptive.

Knowing the right level of interaction design to apply at the right time can help teams understand when to get interaction designers involved—and. Interaction designers should support teams with the right level of design at the right time to make things better for users.

Government doesn’t have needs

Wed, 15 Mar 2017 08:00:00 +0100

We need to stop talking about the needs of government; it doesn’t have any.

People protesting to government

The words we use — often unconsciously — affect our mental model, the decisions we make, the way we design and the services we deliver.

I gave a lightning talk at a digital, data and technology event in government, to get people thinking about three things we’re doing wrong: First, stop saying customer, start saying user. Second, we’re not a business, we’re a government department. Third, government doesn’t have needs, people do.

The latter is arguably the most important. The more we talk about government needs, the more it becomes a thing. This will create a culture where people have a mental model of opposition — government needs versus the needs of people (users). If government have needs and users have needs, whose needs are more important? One will inevitably end up getting prioritised over the other, which is wrong and worrying — employees have a tendency to align with their employer first.

Holding onto the problem with both hands

I read an article by Ben Holliday, Head of User Experience at the Department for Work & Pensions, UK Government.

Prioritising one set of needs over the other doesn’t work. https://medium.com/@BenHolliday/the-needs-of-government-dff845b3d25d#—0-58.jfrvaypy2 — Ben Holliday

Ben’s post is great and goes a long way to articulate how we should be considering everything in order to deliver services that work for people, but he does so by referring to both sides as having needs. I feel this is wrong and fear it will continue to spread the problem — in time people will forget the message but the words “government needs” will stick with them, clouding their mental model and affecting how they deliver services for the worse.

Kate Tarling, Head of Service Design at the Home Office, UK Government, wrote a great response.

…talk about what it is that needs to happen to support or deliver a service, using neutral language. Such as checking eligibility or verifying identity — that doesn’t pre-suppose whether it’s a person or a computer doing that. And to talk about the underlying goals, the intent and outcomes for policy and the operational provider(s) of the service, rather than using a similar word ‘government needs’ to represent all of this. https://medium.com/@kateldn/great-post-ben-a3bd228cac07 — Kate Tarling

This is spot on — by using different words you no longer have that opposition, you can consider user needs alongside government goals/intent. Reframing the language we use in government is part of the solution.

There are better words to use

If we remember…

Government is a function of servicing people out of necessity — services are a means to meeting the needs of their users.

Functions and means can’t have needs.

People have needs.

If we start watching what we say we will start building the right kind of culture to design and deliver: services that meet the needs of users, services that truly matter, and services that make a difference.

This is important — it’s not just semantics. Semantics mean something.

Running a design sprint in government

Thu, 02 Feb 2017 23:00:00 +0100

In a week the team framed the problem and prototyped a solution to test their assumptions with real users.

I’m a senior interaction designer working with a multi-disciplinary team to help people prove things to government using APIs.

This is a story about a design sprint I ran. The focus is on what happened, rather than the problem we worked on. Sensitive projects are a reality of working in government, but we’re taking positive steps to make things open: it makes things better. This story is one of those steps.

The team during our design sprint

What is a design sprint?

If you want to learn more about design sprints, there is a book.

The contents shouldn’t be new if you’re a team focussed on user-centred delivery. It’s the unique way in which these elements come together in just five days that make the Google Ventures process a great way to answer critical questions.

For an agile team, the term sprint can be confusing. Think of a design sprint like a design spike. You don’t need to assign your whole team to it. Think about what tasks can be held in the backlog until later and who you need to keep working on what’s left. Let everyone else focus on the design sprint.

Why run a design sprint?

We were working on a couple of projects that were waiting on other people to do something. Everyone was keen to add the next thing to our project board to stay busy.

The purpose of our team is pretty clear, so it can be easy to just start developing. But, this can be a problem too — we don’t want to spend time and money developing something to find out it’s not what was needed in the first place.

I wanted to run a design sprint to kickstart idea generation for the next project. The team weren’t sold on the value this would add considering our “scope”. After several attempts to convince the team to try it, they still weren’t bought into the concept — of course the designer wants to run a design sprint. In the end it took careful persuasion of just one person to help sway the decision — our delivery manager.

A design sprint was going to help us understand the problem we were trying to solve and get a good indication that we were on the right track. And — if we weren’t, we’d only spend a week finding that out, rather than months. It’s win win.

The design processes in a sprint are not all that different to what a team will go through during a discovery or alpha phase. The difference is the structured format and time constraints that force decisions and progress to be made. This makes running a design sprint a great thing to start or prelude a project, or to approach a new challenge midway through.

Before we started

We block booked a room for the week that would become our war room and rallied our troops. Our team was made up of a product owner, user researcher, business analyst, front-end developer and interaction designer (me).

I facilitated the week and we made our product owner our decider.

We invited a couple of experts along to join us. They are the ones that work with the existing problem and processes. They would be best placed to answer our questions and help us learn more throughout the week. Unfortunately, due to work they weren’t able to be released for the full week so we had them join us on Monday and Tuesday only which were the days they would be able to add the most value. We then saw them again on Friday for testing.

We also agreed that we would continue to attend the daily stand-up with the rest of the team, not only to make sure we were there to answer any questions, but also to update everyone on how the design sprint was going.

The team framing the problem

Monday

We framed the problem, setting a long-term goal and noting our biggest assumptions and questions down.

If we had followed the process strictly, we would have done a story map of what the future journey might look like after achieving our long-term goal. However the team found it difficult to visualise how this might work as there were so many elements that [in reality] were out of our control. This is common in government organisations — most services will interact with multiple departments and as a team you’re only empowered to focus on a thin slice of that big picture. In order to keep momentum going I asked the decider if we should focus on the current journey instead. This approach was favoured as we knew what the current journey looked like, so we could articulate and map it out. We also knew where the problems areas were.

This inverted approach meant that instead of picking a target moment in a idealistic journey, we kept grounded in reality and picked a point that was our riskiest problem and therefore our greatest opportunity.

It felt like a long day and I wasn’t sure that everyone was sold on the process [yet]. People had already questioned the value before we started and Monday’s process didn’t help. Whilst it’s an important day, it’s also a slow day that involved covering a lot of old ground. This was made harder by people from our wider agile team dropping in to observe from time-to-time, which meant more recapping. However, we got there and we were ready to start solving our target problem in the morning.

The team sketching

Tuesday

I always get nervous on Tuesdays (during sprint weeks). I know my artistic skills are below par and it won’t be long until my toddler son surpasses me in sketching ability. This doesn’t hold me back as I know it’s not about artistic prowess, but it can stop people from wanting to get involved. I have run workshops in the past that have fallen apart at this point because people won’t take part, lacking confidence in their ability to draw. But — it’s not about drawing something pretty, it’s about getting information out of your brain and down on paper. That information can be boxes, scribbles or even words. Words are perfectly valid sketches.

The process helps massage people’s confidence, as in contrast to Monday, Tuesday is a relatively quiet day with people sketching mostly for themselves. It isn’t until the end of the day — once we’ve honed our ideas individually — that we share and review as a team.

I didn’t need to worry as everyone was more than happy to get involved. It is a joyous feeling to see the team embrace design in this way.

At the end of Tuesday I held an impromptu retrospective. This was mostly to dampen my own insecurities that people were still pessimistic of the process. It was also a great opportunity to suggest anything that could be done differently.

As usual, I needn’t have worried — the team were positive about the fresh approach to idea generation, the pace we were moving at and the way we were working together. The excessive recapping from the day before was rightly raised and luckily no-one had dropped in today to observe. It was also suggested that we start the remaining days with a YouTube video by Jake Knapp and John Zeratsky who wrote the Sprint book.

Our ideas on the wall

Wednesday

As requested, we kickstarted the day with a short introduction from Jake and John about what we would get up to on Wednesday. They are infinitely more engaging than I am, so this was a great start to the days energy.

I could clearly see how the teams engagement had changed since Monday. Gone were the pessimistic stares from chairs. We were standing up and moving around the room in healthy discussion.

We made great pace, deciding on our best ideas and creating an end-to-end storyboard that we were ready to prototype.

Our prototype

Thursday

We were spoilt — we had a front-end developer on the sprint team, with access to an Angular JS framework and could easily pull in GOV.UK elements and other code dependencies we needed. In minutes we had a solid foundation for a hi-fidelity prototype that users would be able to interact with like it was production ready. Getting the grunt work out the way with meant we had a full day to focus on getting the hard parts of our prototype right.

Building a code-rich prototype didn’t mean the rest of the team were excluded from the day. Everyone played their part; building dummy data sets, mocking up paper artefacts, defining different scenarios. The whole team came together to create a situation that was as close to the real world as possible. This would enrich the reality of the observations we would make during testing on our final day of the week.

The team at the end of our design sprint

Friday

The rest of the week felt like a marathon in comparison to Friday, which literally was our sprint finish.

We’d started with the intention of testing in the building across the road — this was the users natural working environment. We were planning to stream the sessions over Google Hangouts via a laptop webcam to the TV in our war room. This way the whole team could observe live and make notes.

The first session was due to start when suddently the WiFi wasn’t working on the test laptop. We couldn’t delay as we only had the participant for this time. I ran across the road with another laptop and pointed the webcam at the session half-way through. Unfortunately the angle wasn’t great and although the team could hear everything, they couldn’t see any of the interactions on the screen.

This was what came through on Google Hangouts. We had a bit of time before the next participant to set up. It wasn’t until after the session that we realised what we could see on the screen wasn’t coming through Google Hangouts at the other end. It was at this point we gave up on streaming and rearranged the afternoon sessions to be in the same room. This wasn’t ideal as it was no longer the “natural” environment, but at least everyone could observe.

We also had a bit of time over lunch to make a couple of tweaks to the prototype for the afternoon. A few obvious things kept coming up during testing that we hadn’t had chance to perfect the day before. It made sense to quickly fix them now so they were no longer a obstacle.

The afternoon sessions went much smoother and we affinity sorted all of our notes at the end of the day.

That was it — in one week we had framed the problem, prototyped a coded solution, tested it with real users and got rich qualitative feedback we could act upon. Phew!

What happened next

The following week, we did a show & tell with some people from policy. We shared the process we went through, what we built and learnt. We felt we’d done a great weeks work, but anticipated we’d soon be grounded back in reality. But again, worry was not needed! They were impressed with the process and what we had achieved in such a short space of time. They were even keen to find more ways in which our solution could be used.

This was a baby step in a long journey. We have learnt a lot, but most importantly we have learnt what we need to learn more about.

It turned out that the experts we had in the room were a niche subsection of the potential users, which means there was a lot we’ve potentially missed that could have led us on a different journey.

We’re planning to use the work we’ve done as part of a request for funding so hopefully this will become a full project soon.

I did a show & tell to people from our wider digital hub, to share our journey and hopefully inspire others to run their own design sprints. It was comforting to hear our product owner and front-end developer admit that they were skeptical beforehand — they didn’t believe we would do everything I said we would. Now that we’ve done it, they’re impressed with what we achieved and would do it again.

Running a design sprint in government has it’s own challenges: working openly, senior buy-in, cross-government dependencies, policy, legislation, funding. Don’t let that stop you. By the end of the week you will have tangible output in your prototype. You will have questions, but you will have answers too. You will have achieved a lot, fast, and this is just the start.

Molly Watt

Sat, 17 Sep 2016 21:00:00 +0100

This is part 1 in a series about why we need dark modes to be an inclusive design consideration.

Molly Watt has Usher Syndrome.

A photo of Molly Watt

Molly was born deaf and at the age of 12 began to lose her sight through retinitis pigmentosa, leaving her registered blind at 14. Today Molly hears using ReSound hearing aids and sees with the remaining 5–degree vision she has in one eye. Molly uses technology as a gateway to her independence and raises awareness of her condition through keynote speaking and consultation.

I recently heard Molly deliver a motivational presentation at a cross government accessibility meeting. This was the second time I’d had the privilege of hearing Molly inspire people to do the hard work, to make digital services better for everyone. On both occasions I immediately wanted to start solving some of the problems Molly encounters with digital services that haven’t been designed with her in mind.

This compulsive nature to solve problems can be a great strength, but it can also make you lose focus. I want to solve the immediate problem that’s before me. After research sessions with users I straight away want to address their needs and solve their problems. Then before I know it, the solutions for them cause the next group of users problems, so I solve them, then the next and the next and so on. Before I know it the first peoples problems have become yesterdays news and I haven’t fully solved them.

Accessibility is kind of like the weather

One week we’re experiencing a heatwave and everyone is really engaged and excited to be making a difference in their design and development processes. Then before you know it we’re back battling legal challenges with our umbrellas, and when it rains it pours.

Inclusive design should be considered at all times and to an extent it is, through good practices in content, interaction and technology. But — too often, other things get in the way and you need that empathetic kick. Get out there and listen to real people to better understand their needs and their problems.

What’s the accessibility forecast today?

Right now the big problem I want to solve is one that I know Molly struggles with —high contrast, specifically white backgrounds with black text. It creates too much glare and makes it impossible for Molly to focus. It’s unusable.

We’ve kind of come to associate plain white backgrounds with good simple design and think no more about it, but this is wrong and we need to do more of the hard work to include everyone.

Most people will think, “Why not just invert the colours on your device. Problem solved.” No! It’s like we can’t think outside our own degree of experience. There’s two problems with that way of thinking:

You’re assuming someone knows how to invert colours on their device—they might not.
You’re replacing one problem with another—inverting colours will invert everything and make images unusable.

When someone can see, even a little bit, you can bet your ass they’ll want to make full use of whatever vision they have left. Just because someone is registered blind, doesn’t mean they are not a visual person.

Imagine a person is carrying out lots of tasks on their device, requiring different apps and websites. As they switch between each one the base colours of that app/website will be different. What makes the contrast good on one makes it bad on another. Inverting colours is a hack (not a solution) that Molly would constantly have to flick on and off depending on what she’s viewing. That’s not inclusion. That’s ignorance.

If you have a nail you know you need a hammer

Is this true? I guess the argument in this statement is, if you have a condition you should know the tool you need to let you get on with it. I disagree. That’s ignorantly assuming that because you know you need a hammer, that all users will know they need a hammer too. And what if it’s not even a nail, what if people think it’s a nail but it’s actually a screw? Suddenly the hammer isn’t the right tool to solve the problem anymore.

High contrast black on white will be good for a proportion of the population, but what about those it’s not good for. Unless we do something for them, we’re excluding them.

What am I doing about it?

I’m trying.

There are more things that will need to be done to make sure Molly’s experiences of digital services are as inclusive as they should be, but I need to start with just one thing. A dark mode.

Dark mode is on the backlog. Now to fight for its priority @MollyWattTalks @dugboticus pic.twitter.com/rRwExgj2Nr
— Charles RT (@charles_rt) September 16, 2016

Digital services need a way to easily let people switch the core content colours to a mode that is tailored to their needs, without effecting images, video, meaning or brand.

Assuming a style switcher is the solution to this problem, it’s nothing new. It’s just something that isn’t trendy anymore. But this shouldn’t be about fashion, this is about inclusive design for all. Solving this problem for Molly will actually solve problems for other people too. A dark mode will be better for people who suffer from migraines, have a hangover or are just browsing the web in bed at night with the light off. Designing for the few, makes things better for the many.

I am a designer at the UK government. So far this solution is a Post–it on the wall under another Post–it called ‘Things we know about.’ I now need to fight for it’s priority so I can prototype it and test whether it truly does solve the problem. But this is just one service. The big win will be implementing a solution on the whole of GOV.UK, setting a standard that the rest of the web can follow.

As a baby-step I’ve already added a dark mode to my personal website. This not only helps me quickly test a solution live, but I’m also too aware of how hypocritical I am banging on about inclusive design, when my own website falls short on so many levels. I’ll write about the process of implementing this on my own website soon (it’s just a simple CSS only style switcher). I’ll also do a prototype of how the same solution could work on GOV.UK.

If nothing else comes of this I’ll at least be happy with Molly’s feedback…

Wow, brilliant thank you for going to this trouble it really makes a difference :)

I’m liking the simplicity of your website, it certainly works for me. Great contrasts too :)

Molly’s life experience has been affected by how hard people have worked to make both digital and non digital services inclusive for her. It’s affected her education, work and mental health.

It’s not enough anymore to employ people who can do a job, who code, who do design. We need to start employing people who are passionate about solving real problems, people who are empathetic, people who care.

I have published a follow up to this post called Apple need a dark mode.

Egoless design: Reviewing the right way

Tue, 06 Sep 2016 12:30:00 +0100

I was halfway through a design deep dive. I became uncomfortable. I was nervous. I was hot. I started breathing heavily. My heart started racing. But — I was not presenting. I was in the audience. An audience that was not doing it right. An audience that was criticising.

An illustration of a head in empty space

Nobody benefits from criticism.

Crit(ique) vs Crit(icism)

These two words are too similar in form to appreciate their difference in definition. The language we use is important as it forms our mental model and approach to a situation. This is why I’m going to use the softer word review, which works better.

Reviewing the right way

When we review design we should not make statements or pass comments, we should ask questions to learn more:

How might you…?
Why did you…?
What did the user…?

As designers it’s easy to try to think like the user, but we are not, and we can never hope to fully grasp the context of something in a short review. We should have trust in the designer(s) presenting. They have lived and breathed the problem. They have attended and observed user research sessions. They are the professionals that have been hired and entrusted to do the job the right way.

By asking questions, we prompt answers that will force designers to communicate the context and process in more detail. This helps them discover new ideas or alternative approaches they’d previously missed because they were too focussed. Self–captured comments will always be better acted upon.

It’s important to talk about what works well too. Don’t forget that this is a chance for both sides to learn something new.

Three’s company

With the best intentions, design reviews can still be challenging. Designer(s) can be anxious about presenting; worried that it is them or their ability that is being reviewed, rather than their work. To help ease this feeling of audience vs presenter(s), it can work well to have someone take up a third role of facilitator. A facilitator can help reviews by:

introducing the designer(s) presenting
clarifying what we’re reviewing and what we’re not — there’s no value in discussing things that can’t be changed right now, especially if there is a specific problem area the designer(s) want feedback on.
asking the audience for questions
taking notes to help prompt the designer(s) later
confirming next steps

No egos

There are no bonus points for egos. We’re all working towards the same goal — we all want to solve the problem collaboratively. In the beginning; it doesn’t matter what it looks like, or how it feels — it matters how it works; how people understand it and how people interact with it.

Ask questions. Listen. Learn. Repeat.

If nothing ever changed, there’d be no butterflies

Fri, 05 Aug 2016 14:55:00 +0100

Normally, we don’t pay attention to change — we live busy lives — and the changes taking place around us are not worthy of a second thought.

A butterfly on a leaf

Occasionally, we allow our perceptions to determine a particular change as having a higher effect on us. That change could be work related; a project cancelled, close team members leaving, organisational change, starting a new job, or it could be personal; having a baby, or moving home. Sometimes that change is outside of our control, sometimes we’ve instigated it — that isn’t what’s important. The important thing is how we let that change effect us; our mood, our outlook and our work.

We can’t always change change, and most of the time it’s futile to try and stop it. When change happens, we need to adapt and evolve. Don’t focus on the negatives or the known unknown, but — if the opportunity arises — do influence change positively. We can’t regret trying to make something better, we can only regret not trying.

We should embrace change and the new opportunities it may bring, while reflecting on our past decisions so that we learn for the future.

After all, tomorrow is a new day.