Weeknotes 1

I've decided to give weeknotes a go. I don't really know if there's a format I should follow but I'm just going to focus on things I did (or read) that I think are worth highlighting.

What's interaction design?

Last week I changed various pieces of content on my site. For example, my home page sub title now reads:

‘Hey 👋 I’m Adam. I help discover user needs and translate them into simple and inclusive digital services for the web.’

I wanted capture what I do in as few words as possible. I was triggered to do this after being a guest on Paul Boag's podcast last week. He asked me what an interaction designer does and where the role starts and ends.

The overly short answer is in the one liner above. The long answer is in the podcast, but I will say that it's hard to define because interaction design is a subset of service or user experience design.

And the whole team is responsible for that. And so the lines are blurry particularly between developers, content designers, architects, service designers and product owners.

If you listen to the podcast, you should know that I didn't come up with the answers all on my own. I asked Dave House on Slack and I stole things Craig Abbott said in an interview and other things from Charles Reynolds-Talbot's article.

Insanity Max 30 — finished week two

Despite playing 3-5 hours of tennis a week for a good few months, I've noticed that I don't need my belt anymore! That's probably because I eat way too much chocolate when nobody's watching.

In the past I've had good fun and good success with Insanity so when my friend told me about Insanity Max 30 I decided to give it a go. It's a shorter regime (30 minutes) and full of fun crazy moves.

The way it works is that you follow the moves and the timing until your body gives out. Then you note down the time. Then you see your times improve over the weeks.

The first week was disgusting and I felt like giving up after a minute but managed some pretty decent times. But I felt an improvement in the second week. You can see my times below.

First week fail times: 7:01 9:49 7:51 10:42 8:35

Second week fail times: 9:17 10:43 10:01 10:48 11:45

Six weeks to go.

Released a rich text editor component

We added the rich text editor component into the HMCTS Design System. It uses the contenteditable browser API which is powerful and requires very little JavaScript.

The need for this came from judges needing to send questions to appellants (citizens) to hopefully avoid the need for an in-person hearing. Without formatting, citizens would have to read a large block of text. Bad.

The rich text editor had controls for bold, italic, underline, bulleted lists and numbered lists.

The problem was that citizens don't always understand what bold and italic signify. And underlined text is reserved for links. Having underlines on text that you can't click is confusing.

Given the above, I'd usually opt to kill all three controls to keep things lean. But when it comes to design systems that are used by many, we think it's best to make things configurable.

This is something I've learnt from Amy Hupe—she works on the GOV.UK Design System which our design system depends on—over one of our many Whatsapp design chats. I was going on about doing the leanest, simplest thing and making components specific so they can be delivered quickly.

Amy was saying how that doesn't work so well in government because we can't possibly understand the entire nuanced problem space. I've noticed this to be true for our design system too.

So for this component the three controls are turned off by default. This way, should there be a need for these controls (perhaps for judge to judge communication), we can turn them on individually through configuration alone.

Also, some browsers such as Chrome, let users format text using keyboard shortcuts whether you show toolbar controls or not. For example, pressing CMD+B makes text go bold. Other browsers such as Firefox will open the user's bookmarks instead.

Because of this, we can't just detect these keys and prevent the default behaviour. Instead I think we'll need to consider filtering out the forbidden tags somehow.

If the tags are filtered out on the server then what the user sees is not what's sent. Bad.

If the tags are filtered on the client (by listening to the keydown event or similar) I worry that the user might see a flicker or that the caret might move position.

I'll need to learn more about this.

The project I'm currently working on uses Angular. And for reasons I don't fully understand yet, Angular doesn't work when you use <a href="/path/to/resource"> for links. Urgh.

The suggestion was to use <button>s instead which feels wrong to me. To the user, navigating should feel like navigating and offer the same behaviours and signifiers.

I decided to see ask Twitter and I got some good responses. Here's a few:

‘I’d use links. You’re still navigating somewhere. Unless you’re doing something like submitting a form I wouldn’t use a button.’—Craig Abbott

‘This is the mantra: If it goes somewhere, it’s a link. If it does something, it’s a button.’—Charlie Triplett

‘Screen readers don't care. For deep linking and bookmarking and easier navigation out of the box with browsers, use hrefs. If purely UI use a button.’—Nick

‘If the control points to a resource, it may have a route (direct url) and so it should be an A tag with href. If the control only trigger an "in place" behavior, then I think it should be a button. FMPOV, Single Page Apps arn't an excuse for not giving real URL (routes) to contents.’—Mab

‘I think for reasons of accessibility then links. We know as devs when a site is an SPA.. end users, especially those using screen readers, probably still see it as a normal site.’—Michael

Fudgability

Having worked on a number of internal case management systems there seems to be two approaches to design that crop up in my head and in conversations with teammates.

  1. You can get clever and try to change the interface to give users exactly what they need in order to send them down the path they should be taking. Or
  2. You reflect back the true state of things and give users all the options so they can do whatever they choose.

At first (1) sounded like the best approach. But in my experience it's (2) that is the way to go. And then I stumble across Alan Cooper's tweet storm on fudgability where he articulates this better than I ever could.

Here's a few bits I've pulled out:

‘A fundamental truth about any good white collar worker--manager or practitioner--is that they know how to react to different situations that arise on a daily basis, adapting and adjusting their behavior to suit. 1’

‘Virtually all such software is designed and built based on the insane idea that business processes are like a predictable series of sequential operations. A then B then C then D then check the box and move on to the next docket. 6’

‘Virtually all back office software is built on an idealized concept of how businesses work, and are utterly incapable of dealing with how businesses actually work. 7’

‘The job of the interaction designer is to deconstruct systems like this and create digital solutions that combine the best attributes of both approaches, both human and idealized work flow. 18’

‘A good designer creates a system that is adaptable, adjustable, revealing of state, willing to let the human lead, capable of holding parts of the information flow in a state of suspense. 19’

The five dysfunctions of a team

My friend Dan is on a streak (of two) of recommending me books that are light but full of practical advice. His latest rec was The Five Dysfunctions of a Team. I almost cracked out the whole lot in a week of commutes.

A high performing team has individuals who trust each other, are comfortable in conflict and who are focused on the results of the group (not the individual). And the book explains how to go about building a team like this.

I'd love to be able to help build a team like this and I'll try to apply things where I can. But I fear this is one of those books where I'll read it and forget it. And that even if I manage to do tiny things here in there, they'll effectively be, well, ineffective.

The book tells a story from the point of view of a CEO and while you don't have to be CEO, I do think you need to be in a leadership position to implement the things in the book.

And that's me done. That felt therapeutic. And this may also help me stop drowning in random Google Keep notes.