Open Thinkering

Menu

Month: November 2020

Define your audience or your product will (probably) fail

In the past few weeks there have been a couple of occasions where the ‘why’ has been missing from some of the work in which I’ve been asked to be involved.

I’m not talking about the ‘why’ from the supply side, from the organisation that wants to provide the thing; I’m talking about the ‘why’ from the demand side, from the people who might want the thing.

This is not new to me. It was one of the major reasons it was so difficult to get systems of digital credentials based on the Open Badges standard off the ground in the early days: they made sense for the badge issuers, but not necessarily to the badge earners!


During the Catalyst Discovery work I led for We Are Open Co-op last month, we kept returning to one central theme with the nine charities that were involved in the programme. It’s summed-up in this excellent illustration from Bryan Mathers:

Person enthusiastically showing a complicated diagram and saying "What do you think of my cool idea?" to someone looking rather bemused.
Image: CC BY-ND Bryan Mathers

In other words, if you show people who you already know something that you’ve made and ask them their opinion of it, they will say things to please you. “What do you think of my cool idea?” is not a fair question to ask people with whom you’re in a relationship. It’s the equivalent of asking your partner “does my bum look big in this?”

Instead, you have to do the hard work of audience definition and then user research. If this were an easy thing to do, then every workshop would have a waiting list, every newsletter would have millions of subscribers, and every product would have made its inventors rich.

It sounds obvious, but if you don’t know who your audience is, then you can only be successful: (i) by accident, (ii) by designing for yourself (as part of the audience group), or (iii) by copying other people. These are not long-term strategies for success.


Once you have defined your audience, congratulations! You now need to find out as much about them as possible. You can do this in passive ways, through reading other people’s research and sifting through data. That’s valuable, but nothing beats being active and going out of your way to actually talk to people about their pains, gains, and jobs to be done.

I tend to use Strategyzer’s Value Proposition Design (VPD) approach for this. I used it when designing MoodleNet, and I use it with clients. In its simplest form, you boil down the thing you create to a series of ad-libs which define your audience, product, and how it helps them:

Our ______ helps ______ who want to ______ by ______  and_____  (unlike  ______).

I see too much what I would term ‘magical thinking’ in the world of product design and development. It’s equivalent to the fallacy of build it and they will come which plagues us all from time to time.

If your idea is worth putting into the world, and the main audience is someone other than yourself, then it’s worth talking in advance to the people who you want to buy, read, or use your product.


This post is Day 66 of my #100DaysToOffload challenge. Want to get involved? Find out more at 100daystooffload.com

Convenience, UX, and ethics

Old TV displaying the phrase "the convenience you demanded is now mandatory" with each word in the design of a big tech company (e.g. Amazon/Netflix)

At about this time of year (Frimaire, for those paying attention) I get a little more introspective. I tend to reconsider my relationship with technology more generally, and apps/platforms in particular.

This is because decisions I make about my relationship with tech are a proxy for my wider views about the world, including philosophy, politics, and society.

The meme at the top of this post went by my Mastodon timeline recently (thanks to Ali for re-finding it!) and perfectly encapsulated the relationship many of us have with tech. In a nutshell, convenience and good user experience (UX) trumps ethics and thoughtful decision-making every time.

It’s all very well wringing our hands and promising to use Amazon less, but we’re living in a world where regulators need to step in and ensure more competition.

In the meantime, there are small decisions we can all make which won’t inconvenience us too much. For me, that means having goals in mind about consumption, ethical principles, and the tools I use to communicate.


This post is Day 65 of my #100DaysToOffload challenge. Want to get involved? Find out more at 100daystooffload.com

(A)synchronous project updates within organisations

As a consultant, I find that there are, broadly speaking, three types of teams and organisations when it comes to project updates:

  1. Synchronous updates (only)
  2. Aynchronous updates (only)
  3. Asynchronous and synchronous updates

The purpose of this post is to explain why the third of these is by far the better option.

1. Synchronous updates (only)

The most popular (the default, even!) are those only doing synchronous project updates. This means that the team, group, or other unit of organisation finds out the whole picture of what’s going on in the weekly team meeting.

Advantages: every project update can come with full context and, if someone doesn’t understand, or has a question, this can be addressed immediately. If the project team is meeting face-to-face or via video then facial expressions and body language can convey additional information.

Disadvantages: if the project team is only receiving updates on the day of the meeting, then the information they have can be up to six days out of date at any given time. Also, anyone who misses the meeting has to rely on the notes.

2. Asynchronous updates (only)

Other teams, groups, or other units of organisation only do asynchronous project updates. This means that meetings are rare, and the main way to find out what’s going on is to check the place where updates are made.

Advantages: anyone with the necessary permissions can get involved, which is why this approach is common to Open Source Software projects. What you see is what you get, and combined code repositories and issue trackers (e.g. GitHub) provide a decent workflow to get things done.

Disadvantages: with the human element removed, it’s difficult for the full context (including relative importance) of an update to be conveyed, and for serendipitous links to be made between projects.

3. Asynchronous and synchronous updates

The best teams I’ve come across do a combination of asynchronous and synchronous project updates. They meet regularly face-to-face or by video and provide updates in a dedicated space between meetings.

Advantages: everyone on the project gets full context around an update, either in the dedicated space or by asking a question about it in the meeting. There is now more time in meetings for forward planning and innovation.

Disadvantages: none that I can think of!


N.B. Workplace chat solutions such as Slack are great for many things. Given the potentially low signal/noise ratio, project updates are not necessarily one of them. Instead, I recommend using a dedicated space — e.g. Trello or Nextcloud Deck.


This post is Day 64 of my #100DaysToOffload challenge. Want to get involved? Find out more at 100daystooffload.com

css.php