Doing the hard work to make it simple – Tom Loosemore

Below is a video and summary of a talk by Tom Loosemore at the Camp Digital conference, 2016.

Design is inherently political, and we must not ignore this

Ask yourself: who is the “we” that gets to build the future?

If you don’t understand how something works, you are a consumer, not a citizen. Don’t be fooled by ‘magic’.

Richard Pope – “Software is politics, now” – it shapes power dynamics.

GDS came up with the design principles so that people would have a new language to use to change reality.

The advantages of working in the open

Child benefit tax calculator. They made a mistake, so someone suggested a fix on github which has now been incorporated.

Ministry of Justice – problems with a form used by divorcing couples. Proprietary software. Took months to fix.
The change on github took 3 days. Massive difference.

What is digital, and what is our job in a digital world?

Definition of digital: “Applying the culture, practices, processes & technologies of the Internet-era to respond to people’s raised expectations.”

It’s not about technology – it’s about taking advantage of technology to redesign services and organisations to meet changed expectations.

Focus on delivery

Martha Lane Fox’s 4-page report gave just enough cover to start delivering. No need for a big strategy.

“The strategy is delivery” – key phrase at GDS.

Internal metric: write 100x more lines of code than lines of business cases justifying code.

Guy Moorhouse designed icons for GDS. But then he tested and found out that they didn’t help people, so he removed them and blogged about why.

Building the political case for change

GDS alpha was done openly. This was to create buzz outside the system to convince ministers that it was a good idea. This helped overcome reluctance from senior civil servants.

Do something valuable -> build political capital through an early win -> get rid of the ‘no’ people (spending all of the political capital)

Old approaches to service delivery are flawed

When Tom Loosemore started at the DWP in 2013, he asked ‘so, what have you been doing with all this time and money?’ For 3 years of work, they showed a 600 page policy design manual.

The DWP senior leadership thought of Universal Credit as a policy. But they hadn’t designed anything – they’d written a document. It had thousands of untested assumptions about people’s behavior.
“a document full of false certainty”

When Tom arrived, the DWP processes were as follows (with each step done by a different team):

  1. Invent policy
  2. Guess requirements
  3. Procure IT system
  4. Inflict on users
  5. Operate (aka ‘stasis’)

This is the wrong way to deliver services.

You must observe real user behaviour

People don’t know what they need. You have to observe real people in the real world
“observer their actual behavior. Surveys are useless. Actually focus groups are useless.”

“Watch what they do, don’t listen to what they say”

“False certainty if our mortal foe”

“Start humble, stay humble”

Start small, build a shared vision and empower the team

Start really small. Iterate based on how people actually use the service.

Craft a vision that everyone can use to steer every decision. Use simple language.

Empower people to make decisions based on this vision without having to run it up the hierarchy.
And because you have governance check-ins every 2 weeks through a show-and-tell (demo), things won’t go out of control.

Build an empowered multi-disciplinary team

The multidisciplinary team worked together in a room.

To enter the room, you had to be fully empowered by your bit of DWP or HMRC or LA to make decisions in the room. No one senior. It was surprising how easy it was for the organisation to identify who needed to be in the room.

Video of user testing convinced IDS to make a change to the benefits policy immediately.

Start multi-disciplinary; stay multidisciplinary.
Don’t just remove these people once you’ve ‘launched’

Obtain a mix of mindsets: Pioneers, Settlers, Town Planners.

“User research is a team sport”

Continually assess your knowledge and your readiness

Each sprint, they asked themselves: What have we proved? Do we understand user needs better? Have we designed the service to scale massively? Do we know how to operate?

“If you can’t release software every day in an emergency you’ll never be secure, because a new threat will emerge and if you can’t respond like that *clicks fingers*, your organisation is inherently insecure”

Governance

“Governance was very simple: Ministers come to the show and tell, we’ll show you what we’ve made, we’ll show you what we’ve learnt, and what we’re going to do next, and we’ll talk about risks and issues if you want. But the real governance is seeing the thing being made and seeing the evidence and user research that it’s likely to have the intent that the minister wanted. Every week. And give credit to ministers, they turned up.”

“If your senior management doesn’t show up to show and tells, look them in the eye and tell them that they are failing at governance. Use that word.”

“Show the thing” – a thing you can use, not a thing you can see.
If you’re sending screengrabs, you aren’t showing the thing, you’re showing pictures of the thing.

Behavioural psychology approaches to service design – Alisan Atvur

Below is a video and summary of a talk by Alisan Atvur at the Camp Digital conference.

Psychology knows that behaviour is seldom rational. So we need to study behaviour.

Create a common design language with “nonviolent communication”

Marshall Rosenberg argued that there were 3 categories of non-violent communication:

  1. 88 human needs
  2. 91 positive feelings we wish to experience
  3. 153 negative feelings we want to avoid

To be non-judgmental, clear and constructive in our use of language, use a “Rosenberg deck” of feelings cards as a conversation prompt.

Map behaviours with “rational emotive behaviourism”.

Albert Ellis, the founder of CBT, argued that Activators trigger Behaviours, which lead to Consequences.

Map out a user journey. Use an Ellis Matrix. Identify the causes of user behaviours. Propose what new Consequences could be, and what new activators and behaviours could be.

Map motivations with “guiding self ideals”

A lot of we do is a result of feelings of inferiority. (See the work of Alfred Adler.)
We seek a “fictional final goal” – if I do [BLANK] I’ll be finished and happy.

So ask ourselves: what would happen to us as an organisation if we never tried to solve this problem?
What would happen to the user if we never tried to solve this problem?

Then ask: What is an aspirational place for us to be? What if we did do this?
Can you clearly indicate what the result would be? – for us and for users

You need to map this out to get an overview of a potential new area of work.

Good leaders and designers empower the team

Lao Tzu quote on leadership, from Tao Te Ching:
“A leader is best when people barely know he exists, not so good when people obey and acclaim him and worse when they despise him. But of a good leader, when his work is done, his aim is fulfilled, they will all say we did it ourselves.”

Cultivating Shared Understanding from Collaborative User Research – summary

I’ve pulled out some of the key points in a discussion about user research, between Jared Spool and Erika Hall on the UI20 podcast. A transcript is available on that page.

What makes for good user research?

Years ago, the approach to reporting on user testing was different. Jared Spool: “You’d come back and you’d assemble the notes into a giant report. You would write the report in passive voice, and then distribute it. Of course, the thicker you made the report, the more of a thump up it made when you dropped it on the table, which was, of course, the most impressive way to do reporting, and then nobody read it. Then you wondered why it was there.”

Of course, the purpose of user research is to inform high-quality decisions. So research must be read and acted upon. This is why user researchers now produce short, easy-to-digest reports.

Erika Hall: “The value in research is not the answer… It’s creating that culture where you’re constantly asking the same question, and you’re in a position to keep asking the question, finding what today’s answer is, and finding a way to respond to that in your work.”

What is the aim and output of research in a team?

The documentation becomes secondary. Erika Hall: “The goal is not to produce a report. The goal is to create this shared understanding so that everybody in the team knows here’s what our goal is, and we’re very clear about our goal. Here’s what our constraints and requirements are. To really think about the assumptions together and develop the shared vocabulary about here’s what we’re betting on, and here’s our evidence that those are good bets.”

Selling research

Erika Hall: ‘[One thing that] sociologists are studying right now is the fact that data doesn’t change minds… People’s minds are very good at shutting out data that they don’t want to hear…That’s a sales moment for research, when you bring a stakeholder in and you’re like, “Watch this, and see the power, and feel the change in your own mind when you see all of your assumptions blown away.” Those are really, really powerful moments.’

Erika Hall: “Research is challenging given ideas, so it’s naturally anti-authoritarian. If you’re in an authoritarian business culture, you have to work very carefully to change that.”

Asking people what they want leads to unhelpful speculation

Erika Hall: “one of the criticisms of research is that you’re asking people what they want. People will speculate, and this is something you have to be really careful of when you do research about people and their actual behaviors and habits. If you ask the question the wrong way, what you’ll hear is what people are speculating about, which might have no connection to how they actually behave.”

If you talk to people about, “Would you use this feature? What do you like? What do you want?” they’ll imagine these scenarios that may have very little relationship to what they actually do, and what they actually need, and the choices that they make if they’re using something in a real-world scenario.

When building digital products, you should test them early to make sure that what you’re building will work

Jared Spool: ‘if we developed bridges the way we develop online products, the way people seem to want to do it, we would build the bridge and then we would send a car across it. We would watch the car inevitably plummet into the depths below, and then we’d go, “Huh. Maybe there’s something wrong with the bridge.’

Erika Hall: ‘you need to know what your overall goal is, that the research is supposed to be helping you with. you say, “OK, what are our major assumptions that we’re betting on, that carry a lot of risk?”…Then you say, “OK, what questions do we need to ask? What are we trying to find out before we get down to work, or as we continuously work, to help us validate our assumptions?”‘

When you work with data, be wary of projecting assumptions and biases onto the data

Jared Spool:
In a study, a panel was interviewing for the position of police chief. There were two flavours of resume: academic-oriented, and street-oriented.
The male name was attached the to academic resume, the female one the street experience resume.
They picked the male candidate. They said “This position requires a real academic approach, so that’s why we chose the male candidate over the female. It wasn’t because they were male. It was because it was academic.”
But then the names were switched, so that the female name was on the academic resume, and the male name on the street resume.
Then the evaluators would say “This job requires someone with real-street smarts, so we chose…but we’re not biased.”‘

But it’s possible to take measures against bias: “they found that if they had the folks rate up front which is more important, street-smarts or academics, and they were to write that down before they looked at the resumes, then they were more likely to choose the person based on the actual criteria they had decided, not based on gender bias.”

How to change the world – Mike Monteiro

Below is a video and summary of a recent talk by Mike Monteiro. A transcript is available. N.B. NSFW language.

The world is bad because we made it this way. “The world is designed to work this way.”

When people talk about changing the world, ask: “How? For who?”
For all the excitement about Uber and AirBnB, the service economy is nothing new. “There’s nothing disruptive about rich people getting richer.”

How to change the world

  1. Get ignorant.
  2. Realise that the world as designed works in our favour. What if that wasn’t the case?
    The Veil of Ignorance is “The single most important political and ethical concept in a designer’s toolbox.”

  3. Look like the world.
  4. “Our diversity is our strength, and we’re idiots for not leveraging it.”
    If people have narrow life experience, you just get “white boys solving problems for white boys”.
    “They’ve never been harrassed, so it doesn’t even occur to them that that’s a problem you have to solve for.”
    Similarly with cabs refusing to stop, or being assaulted,

    “Empathy is not enough – we need inclusion.”
    The point isn’t that any particular experience or classification makes you a better designer. People are just better informed about themselves than they are about others.
    Our teams need to reflect the diversity of who we design for. It’s not just about race or gender, but experiences, needs, thinking, solutions.

  5. Design the right thing
  6. The AK47 is easy to use, easy to manufacture. But design is about more than this.
    “Nothing who’s primary purpose is to kill can be said to be designed well.”
    “Attempting to separate an object from its function, in order to appreciate it for purely aesthetic reasons, or to be impressed by its minimal elegance is a coward’s way of justifying the death they have brought into the world and the money with which they’re lining their pockets.”

    “Design is a trade done for money, but we have a choice about how we make that money.”
    “Your role as a designer is to leave the world in a better state than you found it.”
    “You are responsible for what you make.”

There are big design problems for us to solve

  • Global warming
  • The migrant crisis
  • Guns in the US

We’re lucky people – so we’re responsible for helping others who weren’t as lucky.
Change how we design and who designs.
Use your time on this world in the interest of making others free.

Testing two WordPress Gutenberg prototypes

I carried out three user testing sessions of two prototypes of the new editor for WordPress. Users were confident in their digital skills. Here are the results.

Key observations

  • The overall design approach is successful. The idea of thinking of content in blocks was easy to grasp, and the context-sensitive popup options were intelligible.
  • The function of the up and down arrows to the left of content blocks wasn’t immediately clear.
  • Users quickly worked out what the block-positioning arrows did, and were happy with this approach. To my surprise, no one tried to drag and drop blocks after finding out how to reposition blocks.
  • In 1.0 people weren’t sure what the S means – is it strikethrough or the option to remove a link? Perhaps we can use proximity to make this clearer – associating this options clearly with presentation controls (underline, italics) or functionality controls (hyperlinks).
  • Some users tried to drag and drop images. How will dragging and dropping work – within and between blocks?

Full notes of the testing sessions

First prototype

Tester 1

Prototype: “A beautiful thing about Apple…”

prototype of a new editor for wordpress

Clicks into a block and sees and instantly understands the alignment options.

Clicks on the ¶ symbol but it doesn’t do anything.
Expected it to be interactive as the mouse changed to a hand pointer, suggesting interactivity.

Clicks on the up arrow, but nothing happens. Wasn’t really sure what it would do.

Enters a line return to break up the paragraph of text, but isn’t able to do this.
Thought that the arrows up and down might allow the insertion of a line break.

Highlights text to make it bold and expects to have to use a keyboard shortcut as nothing was previously visible on the screen. But then notices the popup.
Comfortable with the options presented.

Heading and blockquote options don’t behave as expected. (Dismissed as a limitation of the prototype)

Clicks on the image. The up and down buttons don’t do anything.
Tries to click on the image icon but it doesn’t do anything.
“I don’t understand what the symbols are. I expected them to be interactive but they don’t do anything.”

Tester 2

Understands the split between code and visual editors.

Likes the context-specific editing as it keeps the screen more focused.

Tester 3

Understands the concept of HTML and editable preview.

Wonders how valuable constant HTML visibility is to the average content editor. Will they break things?

Second prototype

“1.0 Is The Loneliest Number”

An early prototype of the new wordpress gutenberg editor

Tester 1

Clicks on the heading text block.
Then clicks on the up arrow.
Then clicks down on it. “Ah, that’s interesting. So these up arrows change the order of the boxes”

User expected to be able to insert line breaks. (How do we want to handle line breaks within paragraph blocks? Do we permit them, meaning that we have big text blocks, or do we take line breaks as denoting the start of a new paragraph block? I’d prefer the latter but haven’t thought about all use cases.)

Clicks on the paragraph of text, and then clicks on the ¶ symbol.
Changes to blockquote style from paragraph style.
Understands that this allows him to apply style to the block.

Scrolls down the page and clicks on the plus sign at the bottom.

When asked what this is, says that it’s “a shortcut to functions that you use regularly.”
When asked: what would you expect to happen if you clicked on one of these items?
“It would create a new paragraph, image, heading, quote, etc, which you’d then populate with content.”

Tester 2

Clicks into the block and manipulates alignment options – working as expected.

Clicks down arrow and block responds as expected. Understands that the page is made up of blocks and that these can be repositioned.

Clicks on “+” and explains that this will add a new block. More options than expected: expected just image or text, so the extra options are “a nice surprise”.

Drags and drops an image into the content block. (Is this something we want to design for?)

Clicks on ¶ – and changes the text block type

Tester 3

Clicks into the text block.
“I wonder what the arrow does” Clicks on the down arrow and sees the block move down. Understands it fine.

Looks at alignment options. “Does that do the whole block? It does”

In general, understands the popup text formatting and link options.
Not sure what the popup “S” with strikethrough icon means.

Clicks on image and manipulates text flow options.

Clicks image icon, but “nothing here”. Expects caption controls.

Clicks on the “+” sign, and understands that this is for adding blocks. Wonders how lists will interact with paragraph blocks, and how we could set levels of header.

Easily understood the blocks concept. Wondered how well this would handle more complex page layouts.

What I learnt by building a side project

A few years ago I completed Harvard’s CS50x – an online computer science course. My favourite part of the course was the self-directed final project. I’m interested in the question of how we can filter the mass of digital information that we’re confronted with every day, so that we can enjoy the best bits without spending all of our time scanning and processing. In my own life, I’d found that I had less time to keep an eye on Twitter. I really wanted a tool to keep an eye on Twitter activity while I was at work. So I explored this in my final project. I built a tool to monitor Twitter activity for a given list.

What I built was pretty basic – it was running on an old laptop in the corner of my flat, and it just displayed the results on the laptop screen after a specified number of hours had elapsed. A solid final project, but it only ever felt like a proof of concept. I wanted to build this into something I could use, and something that other people could use too.

So over the next few years I built it from the ground up as a full-blown web application that has now been launched as a real business: MySocialSummary.com.

The CS50 class was great, but once you have the foundations of understanding in place, there’s no substitute for the motivation, exploration, imagination and excitement of working on your own idea. Subject to having a reasonable grounding (and I’ve taken a number of computer science classes, not just CS50), I’d definitely recommend taking on a project that excites you, to take your knowledge to the next level.

Going through this process I’ve learnt a lot. I’ve divided this into two lists: one on specific computer science and business insights, the other on more overarching observations.

Specific computer science and business lessons

  • How to embed tweets in emails. (Or, rather, why you can’t embed tweets in emails.)
  • Working with APIs. An API is a tool for communicating between two pieces of software. Manipulation of data from the Twitter API is the foundation of My Social Summary.
  • How to load test your website. If you’ve built a website, you probably want people to visit. You commission your infrastructure with a certain number of visitors in mind. It’s worth testing how your site would behave if an unexpectedly large number of visitors arrive at once. This is called Load Testing. I used a tool called Load Impact to check out the load speed of My Social Summary when you add more users. As you can see, the homepage performs well with 50 visitors loading it at the same time.
    load test of mysocialsummary.com with 50 users
  • Working with code libraries. When you’re programming, you’ll often want to do something that other people have done before. For example, loading a web page, sending an email, or accessing the Twitter API. If you’re trying to solve a common problem, often there’ll be a code library of pre-written code that will help you with this. By using a code library, rather than producing this code from scratch, you can save a lot of effort, and the quality of the code is probably much higher quality than what you’d produce yourself. This frees you up to focus on the problems that no-one else has worked on yet. Not all code libraries are created equal – some are better documented and more fully-featured than others – so picking the right one is an important decision.
  • How to set up login via Twitter. A good example of when a code library can be useful. I’d have definitely struggled to build this authentication myself if I’d had to do so from scratch. Check out this documentation.
  • A diagram of part of the Twitter authentication process

  • How to securely handle user input. If you take any form of user input on your website that ends up interacting with the web server, it’s a security risk. So you need to build your site from the ground up with security in mind. I really enjoyed learning about how you can protect yourself using paramaterised database queries and other security best practices.
  • How to set up a LAMP server. That’s a common infrastructure stack, using Linux, Apache, MySQL and PHP to run a website. I’ve learnt how to manipulate the different parts of the machine (e.g. updating Apache settings) and use the different management tools.
  • The complexities of daylight saving time. When the clocks changed, I noticed that my daily summary emails were arriving an hour early. Fixing this problem for myself was trivial, but solving it for all different users – and possible future users – was harder. I’ve built functionality that checks every evening against the very latest timezone rules, and supports every timezone. (Check out the exhaustive dropdown list on the page where you can sign up for a free trial account)
  • The benefits of refactoring code. If code is a set of instructions, refactoring is rewriting those instructions to be more efficient. Refactoring your code isn’t fun – it’s hard work, and involves trawling through your past self’s logic and trying to improve upon it. But it can make massive performance improvements. In one case I was able to decrease the number of database interactions by a factor of a thousand through batch operations.
  • Are you too busy to improve your process?

  • The importance of good version control and deployment infrastructure. Any halfway competent programmer will tell you that good version control is really important. At the start of this project I was evidently not a halfway competent programmer. If you operate version control you can review the history of your code over time, and quickly track down errors. Your deployment infrastructure is the process from getting your code from a code file on your computer to your web server so that it can start doing real work. Ideally you want this to be as frictionless as possible. In the early days, I had no version control, and my deployment procedure was copying and pasting the contents of one text file into another. I can confirm that this was not a good process.
  • How to work with a front-end framework. Specifically Twitter Bootstrap. My interest in this project has been more in concepts and engineering than in presentation. But any website needs to have a front-end of HTML and CSS. Rather than building all of this from scratch, I used the Bootstrap library to help set up the structure and presentation of the site. This made it quite easy to make the site mobile responsive.
  • How to integrate with a payment provider. Taking money from people online has a few complexities. The main one is passing data from your payment provider to your web server, so that you know who’s paid what. This entailed using Paddle’s Webhooks. Handling all the different types of event that might happen – and doing so securely – was quite a bit of work, but it was very satisfying to get this set up and working correctly, and see money come in to my account.
  • How to use cron jobs. On a Linux machine, you can instruct the computer to automatically carry out tasks at certain times. These are called ‘cron jobs’, and they can be really powerful. I make extensive use of these for My Social Summary, for the management of user accounts, and the sending out of communications to new users.
  • How to satisfy the Twitter brand guidelines – and how to update things when they change…. Before coming up with a name, I carefully checked Twitter’s brand guidelines to make sure that the name was consistent. I felt pretty smug about having thought to do this. However, Twitter changed the goalposts, and later the name I’d chosen was no longer acceptable. So I had to come up with a new name for the service – and then roll out this change to all aspects of the service.
  • How to set up HTTPS security. Privacy and security are important, so I wanted to make sure that the site I was building used HTTPS encryption. Setting this up was quite easy – much of the process was done by my web hosting provider who installed the certificate. Seeing the little padlock next to the domain name for the first time was very satisfying.
  • How to set up email authentication via DKIM. I had no idea what this was. But one day I saw a little question mark when I opened up one of my summary emails, next to the sender name. Gmail said that it wasn’t sure if the sender of the email was actually who they claimed to be. Google had instructions on what to do next if you were the person sending this email, and I didn’t even need to follow all of these – pretty much all I had to do was change a setting with my hosting provider and this was resolved.
  • Example of an image without DKIM

  • How to migrate hosting provider. Part-way in to the project, it became clear that I’d outgrown the infrastructure I’d started on and needed a more robust web server. The process of transitioning from one provider to another is something I’ve overseen before in my day job, but to do all the work myself was useful. Before I started the process, I had to choose a provider with the right infrastructure and an SLA to match my needs. (I chose TSOHost and I’m happy with them.) Then I had to commission a new database within slightly different constraints, migrate the data over, and switch the traffic over to the new site. None of this was massively difficult, but the work took about a day nonetheless.
  • How to register a business in the UK.
  • How to track business finances. Fortunately the costs of a digital business are easy to track, so a simple Google spreadsheet suffices.
  • How to complete the year-end tax process. I haven’t had to do this yet – this is likely to be the real learning curve.
  • How to comply with the EU’s new rules on VAT for digital services. The EU changed its laws for how VAT is charged on digital services. Rather than being charged at the rate of the country of the person selling the service, VAT has to be charged at the rate in the country of the person buying the product. You have to collect evidence to prove this, and you can either make VAT payments to each EU country separately, according to its own processes, or you can submit centralised returns through the UK VAT MOSS service. Both of these processes seemed tedious and onerous, so I opted instead to use a payment provider that would handle VAT on my behalf. This meant switching from Stripe or PayPal (I’d been testing out both) to Paddle. Here’s a blog post on Paddle’s site discussing the changes.
  • How to set up a Content Delivery Network. Your website lives on a web server – a computer probably sitting in a datacentre somewhere. If someone the other side of the world wants to see one of your web pages, the information has to travel all the way to your web server and back. It would be quicker if they were requesting the web page from somewhere closer to home. A CDN is a network of web servers around the world that does this task. A CDN can also help take some of the load off your web server – if people are getting pages from the CDN rather than your web server, the web server doesn’t have to work as hard. I use the Cloudflare CDN. It has a free tier and is easy to set up. It disrupted the site’s HTTPS setup for a few hours while I turned it on, but other than setting up the CDN was easy. Cloudflare CDN usage graph example

Broader lessons

  • Starting with a Minimum Viable Product is the right way to build a digital product. I started off by building the simplest possible tool to meet my needs, and then I successively improved it from there until I had a product that was ready to launch. Had I tried to build everything in one go, I wouldn’t have known how to do it, or what I was trying to build. And I wouldn’t have had the motivation and insights provided by being able to use the tool myself from early on in the process. It would not have even been clear if what I was building was going to useful to anyone until after it had been launched. The Lean Startup methodology, and the Agile Manifesto, tell us that you should start off by building a Minimum Viable Product – the most basic version of your product that is still valuable. I already had an intellectual appreciation of this, but it’s always useful to test theories out in practice.
  • How to build a minimum viable product diagram

  • The power of self-directed learning. This project has been entirely self-directed. This has been thrilling – a chance to follow my interests and try and constantly reassess what I need to do – or learn – next. You learn a lot more, and a lot more broadly, if you’re learning to achieve a personal goal.
  • The power of emergent possibilities and understanding. When I started this project, I didn’t know everything upfront. I didn’t even know what I would need to know. The Agile approach to projects – release early, and iterate based on evidence of real user behavior – is thoroughly vindicated by this. Working on this project has strengthened my understanding of, and commitment to, the Agile and Lean principles of releasing early and improving your product from there.
  • The importance of knowing how you work – and what you need to work. Working on a side project is different to working your day job. I’ve become more sensitive to when I’m in the right headspace to do some work on My Social Summary, and when I just need to take it easy. I also have a better understanding about the conditions I need to get work done outside of my normal job. I tend to work quite well in uninterrupted stretches of at least an hour and a half – especially if I’m programming.
  • The importance of dealing with changing circumstances. The external environment changes. During this project, VAT legislation changed and Twitter’s naming rules changed. You need an approach to building a product that is not only resilient to this, but embraces it. Again, if I hadn’t been following an Agile approach, I’d have been in trouble.
  • To trust in your ability to keep learning and know more than you know now. Taking on a self-directed project builds self-confidence and self-reliance.

I’d love for you to check out what I’ve been working on. My Social Summary has a free one month trial, with no card details needed, so see if it can help you get more from Twitter.

What’s next for me?

  • Spread the word about My Social Summary.
  • Explore how we might overcome the ‘filter bubble’ that seems to be narrowing our political and cultural discourse. This feels like an important design challenge.
  • From a computer science perspective, I’d like to build something in a different, and more modern, technology stack. Probably Node.js / Foundation (for front-end) / PostgreSQL / Heroku.

Could you be a Digital Superhero? Julie Dodd (Camp Digital 2016)

Here’s a summary of Julie Dodd’s talk at this year’s Camp Digital conference.

Julie argues that digital superheroes…:

  1. Make products that really help people

    e.g. the Ugly Mugs app, built for sex workers to make sex work safer, or Tony Canning’s use of 3D printing to reduce the cost of prosthetic limbs from £20,000 to £40 – and reducing production time from months to hours – and making the technology available open source so that others can use it.

  2. Use any tool or platform that they can get their hands on

    BBC used Whatsapp at the height of Ebola in Sierra Leone in 2014 to provide information. Largely simple infographics. Reached 20,000 people in the first 3 months who were otherwise very hard to reach. The BBC used existing technology as it was cheaper, quicker and more effective.

    Crowdfunding sites – e.g. Kickstarter and IndieGogo – reduce the need for people to go through a middleman. Charities need to think what this means for them.
    Girl Scouts in America used IndieGogo to raise funds after rejecting a $100,000 transphobic donation. The troop of Girl Scouts that turned down the donation started a crowdfunding campaign that raised 4 times as much money – and sent out a powerful message about inclusion. They also changed the policy of how the national organisation takes donations.

  3. Aren’t frightened to try new ways to do things

    For example bringing in service design thinking or agile methogologies.

    St Mary’s Hospital in Paddington has created the ‘Helix centre’ innovation lab. It’s focused on lean, iterative solutions and combines online and offline. Projects include increasing rates of bowel cancer screening, offering guidance for clinicians on how to communicate about end of life care, asthma management tools for kids, dealing with storage of IV fluids.

    The Town of Jun use twitter for civic discourse and interactions – e.g. booking an appointment with the doctor or making a complaint. Everyone was trained. Saw a rise in public workers being thanked.

  4. Can be found anywhere – not just in tech.

    Google studied a favela in Rio, and didn’t expect to find much technology. Rather, they found a flourishing ecosystem, with radio stations, cyber cafes. With the proliferation of smartphones, people often ‘leapfrog’ the desktop ‘stage’ of development.

  5. Can have significant impact on organisations.

    The British Library now conceives of itself as a data institution, rather than a custodian of physical objects.
    The #tweetmythesis movement encourages academics to share their thesis in a tweet.

  6. Can have an impact in major commercial brands too.

    Barclays set up Digital Eagles programme, driven by the profit motive of reducing cost by moving more people to online banking. (And thereby reducing interaction costs, e.g. staff and branch costs). So it has trained 20,000 staff to train people across the community.

  7. Should work for organisations interested in changing.

    When researching “The New Reality” Julie found some organisations just weren’t interested in digital transformation. She thinks many won’t survive a decade, and wants to spend her energy not fighting those ones to change, but working for the ones that do want to change.

A few miscellaneous recommendations:

  • Recommended meetups: Citizen Beta and Tech for Good
  • “Apps without marketing are pointless”
  • If you do pro bono work with a charity, make clear the equivalent financial value. Otherwise they won’t value it because it’s free.
  • “Asking people to experiment is easier than asking them to commit”

Design for Real Life

Design for Real Life argues that we need to take accessibility more seriously. This goes beyond just conforming to a set of content presentation guidelines (e.g. the W3C standards), and goes to your overall design process. You can buy the book from A Book Apart

  1. Identify and challenge assumptions

    Think about what assumptions you’ve built into what you’re designing. What will happen if someone falls outside these?

    Facebook’s Year In Review – a feature designed to help people celebrate and share their great year – wasn’t designed with the experiences of people who’d not had a great year in mind.

    Inappropriate Year In Review images included:

    • a photo of the user’s apartment on fire
    • a photo of an urn containing the user’s father’s ashes
    • a sonogram of a pregnancy that later ended in miscarriage
    • a photo of a friend’s gravestone

    Facebook’s design team had a narrow vision, and so excluded all of these users. Meyer and Wachter-Boettcher challenge us to bring “edge cases” to the centre. “Instead of treating stress situations as fringe concerns, it’s time we move them to the center of our conversations – to start with our most vulnerable, distracted, and stressed-out users, and then work our way outward.” All users will benefit from this more focused, understandable and empathetic approach.

  2. Make space for real people

    Give people “enough room within our interfaces to be themselves.” For example, gender is often presented as a binary choice between male and female, which doesn’t fit with our current understanding of gender. Facebook is an example of best practice here, allowing people to choose male, female or custom – which is a free text field with a list of common choices as prompts.

    Other examples of systems not giving people space to be themselves include systems that can’t handle names longer than a certain length (e.g. 15 characters), systems that don’t accept hyphens in names, or ones that don’t accept names that don’t pass culturally-specific test of validity. (e.g. Facebook rejecting Shane Creepingbear’s name as not real.)

    Organisations often make assumptions about what matters to users, or about who they are. The ‘Apple Health’ app didn’t include period tracking on launch, even though it boasted that it tracked ‘all of your metrics that you’re most interested in’. Its implicit focus was on men. And period tracking apps themselves often have a bias towards straight, sexually active, partnered people.

  3. Incorporate stress cases

    A DIY and home appliance retailer was looking to improve its product guides. Originally these were written in a chirpy, positive tone, for happy, confident home-improvers. But sometimes users are more stressed when carrying out these tasks. The team found that there were two general categories of use: “urgent” and “upgrade”. They updated their style guide to write for the urgent case. This improved the guides for all users, as the clarity of information increased. Guides now feature installation availability and time-frames, estimated cost ranges, greater user of subheadings to allow for easy skimming, one-sentence summaries, reassuring tone.

    You can incorporate stress or crisis cases in usability testing. And you can test how a product performs in a cognitively-demanding environment by either testing in that environment, or by tiring people out mentally before the testing – e.g. by giving them some maths tasks to carry out.

  4. Only ask necessary questions in forms

    Organisations are often pushy to obtain as much information as they can from every web form. Often this is done with a total disregard for the user’s experience. Caroline Jarrett has a protocol for evaluating each question you want to include:

    1. Who in the organisation will use the answer?
    2. What will the answer be used for?
    3. Is the answer required or optional?
    4. If the question is required, what happens if the user enters rubbish data just to get through the form

    This question protocol can help open up a discussion about the true business value of each question.

  5. Learn from users

    Work to understand how your users see the world. This goes deeper than just testing top tasks on your website, or discussing product features.

    Steve Portigal recommends three types of question:

    1. Gather context and collect detail. e.g. asking about a sequence (Describe a typical workday) or specific examples (What was the last app you used?)
    2. Probe. e.g. ask for clarification of how a system works.
    3. Draw out contrasts. Useful for uncovering frameworks and mental models. e.g comparing processes or approaches.

    Open-ended research is about opening up questions and ideas, expanding your vision and the types of question you ask. This helps you move towards a design process centred aroudn real people and their needs.

    Customer mapping can help you identify pain points, broken flows, and content gaps, through analysis of lenses, touchpoints, channels, actions, thoughts and feelings. Adaptive Path have produced a guide to customer experience/journey mapping.

  6. Making the business case for accessibility

    Karl Groves, an accessibility consultant, argues that there are only three business cases for anything. Here’s how to argue for accessibility for each of these:

    1. It will make money. You can use accessibility to stand our from your competitors. e.g. Slack gaining users through ease-of-use. You can reach new audiences if more people are able to use your product.
    2. It will save money. You can cut customer service costs. The UK government found that as of 2011 it was receiving 150 million avoidable calls a year – calls for which an online service existed. This represented a possible annual saving of around £4 billion a year. Improving accessibility saves you money by increasing user retention – which is between 5 and 25 times more cheaper than acquiring new customers.
    3. It will decrease risk. Accessibility helps you avoid negative experiences and associated backlash – e.g. Facebook’s year in review generated a lot of negative press.

Agile Planning – How to plan quickly and collaboratively

A summary of the 02/08/2016 Digital Project Managers meetup on agile planning.

Estimating jobs

Gather the whole team for this exercise. e.g. UX design, developers, testers, product managers.

Discuss each job, and collaboratively rank the jobs in order of complexity.
Think about all the work that will be required to get this job ready to go live.
For each job, some elements might take more time. E.g. UX might take a long time on one job, but the development might be quick. So you need the different perspectives involved in the discussion.

Groups similarly-complex jobs together.

Apply T shirt sizes to these groups: S, M, L, XL, XXL.

If you have anything XXL, break it down into two or more different jobs.

Assign ‘story points’ to each job, based on its size:
S: 1
M: 3
L: 5
XL: 8

(If you’re running an internal team, there’s no need to think in terms of hours.)

Estimating velocity (how much work you can get done in a given time period)

If you’re an established team, you’ll know from experience how much work you can complete in a given period.

If you’re a new team, you’ll need to collaboratively estimate how much work you think you could carry out in a given development sprint (e.g. 2 weeks).

Work through each of the jobs, and combine them into groups showing how much you think you could carry out in a sprint. Then total the number of story points of the jobs in that group.

Once you’ve done this 10 or more times, work out the average number of story points per sprint. (Round down to the nearest whole number if required.)

This is your estimated velocity – the number of story points you think you can complete in a given sprint.

Prioritising jobs to build a plan of work

Prioritise all jobs using force rank: the highest priority job goes at the top, the lowest at the bottom. Nothing has equal priority.

You can also factor in sequence dependencies (and so promote some jobs that are required to allow you to complete other, higher priority jobs) and highlight milestones (points where you’ll have something specific to show off).

Once you have this ordered list of jobs, lay them out into separate sprints, totaling the number of story points you think the team can achieve during that sprint.

N.B. to adjust for team size, the time of year (e.g. holiday season), and to leave a % for emergent scope: between 20 and 40%, depending on how confident you are that the stories are comprehensive.

Managing ongoing development

Scope is variable. The plan isn’t fixed – it’s an overall route map.

Estimates are fixed. Once an estimate has been made, don’t change it. Retroactively changing estimates wastes time, and disrupts your statistics.
If you aren’t able to get through as much work as you expected, you need to have this recorded in the sprint burn-down. Reflect on this in the sprint retrospective. Re-project your velocity as required.

New stories are sized with reference to existing stories. This makes it quicker to estimate new jobs, as you can compare them to other similar jobs already completed. So estimation becomes easier and quicker over time.

Update your burn-up chart each sprint.Track the speed to the target (velocity) and the distance from the target (scope).

Once your team is established, use their measured velocity and use this to re-project timings. This is more useful than the estimated capacity that you use when planning with a new team.

Agile Foundation – some key insights from the BCS course

In May this year I obtained the BCS Agile Foundation certification. Here are some of the key insights.

Project variables

In a digital project, you have a set of variables that you can control.

Project-triangle-en

In a Waterfall project, you attempt to deliver a fixed scope. To meet this, the time and cost may have to change – and the quality may also be undermined.

In an Agile project, you fix the time and cost, but vary the scope. You might deliver less, but the quality is high, costs are controlled, you release on time, and what you do deliver is the most valuable work you could have been doing.

(A lean approach is slightly different. You look at flow rather than time, value rather than cost (if you only focus on cost you might not get a good ROI), and quality rather than scope (deliver less, deliver right).)

Agile focuses on the early delivery of value to the customer

A Waterfall project only generates value at the end of the project. You start off by specifying what you want to build, then you carry out design, then development, then testing, before launch. It is only at this last step that any value is experienced, because this is the first time that a working product is used by the customer.

An Agile project goes through all these stages during each sprint. At the end of each time-bound unit of development, something valuable is released to the customer. This means that value is delivered more quickly than in a Waterfall project.

Agile focuses on frequent delivery of value

Working in short sprints allows you to regularly release valuable software.

In 2010 Etsy re-engineered their backend systems to reduce the time taken between software releases. The aim was to be more responsive to customers. In 2011, Etsy released new software 12,000 times – about 30-40 releases per day. They tested code on a small percentage of the audience, and then ramped this up to 100% if it tested well. This new approach reduced defects on go-live by 90%, as each change was so small that it was very difficult to make mistakes.

Think about how you could make a small, safe change to your business process. This would help with risk management, and with agility.

Agile values emergent solutions

It’s important to plan, but plans always have to change. Our competitive advantage is in how well we respond to change.

Management must provide vision and purpose, so that self-organising teams know the overall direction they should be travelling in, and management must clear out blockers for teams. This is different to command and control, with management closely directing the actions of teams.

We must design for uncertainty and change

The ‘Waterfall’ model of developing software was codified by Royce in 1970. He noted that it is “risky and invites failure”. The waterfall approach assumes a simplicity which does not exist in a complex environment like software development.

When applied to software development, a waterfall approach makes three dangerous foundational assumptions:

Myth Reality
The customer knows what they want We don’t know what we want until we interact with it and see if it works for us or not.
We know how to make the software. Generally developers don’t know how exactly to build the software until they start building.
Nothing changes during the project Understanding and requirements change over time. Barry Boehm found that estimates given at the start of the project could be 4 times too high or 4 times too low. Later estimates are more reliable.

In an uncertain environment, use an empirical approach

Build something -> Measure how well it works -> Learn

Loop through this cycle as rapidly as you can.

Regular delivery allows for the earlier realisation of value, and for learning and customer feedback that can improve the product. This reduces the risk of building the wrong thing.
If you take a single, late delivery approach (as in Waterfall), the risk of not delivering the right product only starts to fall later on when you do UAT or go live. It’s better to deliver regularly, and to focus on high-value and high-risk areas, delivering these early to de-risk the project.

The economic case for Agile vs Waterfall

The Standish Group’s 2002 Chaos Report found that:
– Around 1/3 of projects are never completed.
– For completed projects, 45% of features were never used. So almost half of all time, effort and cost was for no reason.
– 19% of features were rarely used.
– 64% of time/effort/cost was wasted. So you need to focus on value, and you need to validate ideas with customers.

The Cutter Consortium found the following improvements due to the adoption of Agile practices:
– 61% cheaper.
– 24% faster.
– 83% fewer defects.
– 39% smaller teams.
These gains are a result of simplicity – maximising the work not done.

The key learning is: make your products smaller and more focused on the core value.

Report on the delivery of actual value, not on progress through project stages

In traditional project reporting, you monitor progress through different stages of the project. But there’s no value delivered until you go live.

Instead: look at revenue, impact, satisfaction levels, customer calls, organisational KPIs.