Have you been somewhere with no internet access and tried listening to music?

Chances are you encountered the same frustrating problem I did last week.

I was holidaying with my family near Coffs Harbour in New South Wales, Australia. There was a 3G signal, but it was weak and intermittent in our accommodation. The resort had WiFi in communal areas, but that does not help when you want to listen to music in your villa.

On opening Spotify I would have to wait what felt like a minute or more while it tried to connect to the internet. Often failing. Then it would present me with my downloaded playlists.

The ability to download music is the main reason I subscribe to Spotify. For precisely these moments. When network connectivity is an issue, for example when on a train or in a car, and to limit data usage.

Now a minute may not sound like a long time to someone without kids. But if you are a parent, you know a minute can feel like an eternity.

After four days of having to wait each time I wanted to listen to music, I decided to try iTunes instead.

I opened the app, selected the playlist, and then shuffle. A song started to play. I didn’t like it. I wanted to skip.

Only I couldn’t.

Here is a screenshot from that moment.

I couldn’t do anything while Apple Music tried to do whatever it was trying to do.

The result?

I closed the app and went without.

No iTunes. Not Spotify. No Music.

Spotify and Apple Music both made an assumption that I was either (a) always connected to the internet or (b) my connection was strong and fast.

---

I don’t know how explicit that assumption was during the design phase. Perhaps it was explicit. Perhaps it was a conscious decision.

But my experience was frustrating. Frustrating enough to stop using the apps in that moment.

Now, I can find reasons for the behaviour as designed. Of course, there are many. Spotify is first a streaming service. That implies a connection. Apple Music probably identified my internet connection before launching. Who knows?

The point is that there is an assumption in the design that I have an internet connection and want to use it.

From the comfort of an always on WiFi connection at work and home it may have never been considered. After all the designers and developers are always connected.

But I am on a mobile device. Mobile.

It wasn’t something that crossed their minds. That is the danger of an assumption. They are hidden. 

Assumptions are everywhere. We all make them. Assumptions are mental shortcuts we use to conserve our mental energy.

I am making a big assumption in this post. That the designers and developers didn’t think of me in that situation.

I could be very wrong. I don’t know any of them to ask and check.

Assumptions affect the way we view the world. The way we perceive what is in front of us.

Now I should be honest with you, I love assumptions.

Sad perhaps but true. At work at least.

I am always on the lookout for them. I find it easy to call them out. At work that helps. At home not so much.

But let’s consider this in the work context.

When you document anything at work do you ask yourself what assumptions you are making, or what assumptions your stakeholders might be making?

I hope so.

You see the reason I love them so much at work is that I can tell whether a stakeholder has actually read the document. In the way a story can convey meaning beyond the written words, I find assumptions convey meaning beyond the rest of the document.

They provide context.

This section of a document allows you state everything you need to hold true for the rest of the document to make sense.

If an assumption does not hold, then your requirements change and your design changes. The stakeholders expectations may change too.

Now not everyone agrees. See this thread on Stake Exchange.

Perhaps they think they should be documented elsewhere. Or perhaps they just don’t believe they are needed at all.

Whatever you believe in relation to documenting them, you should understand that they are being made. Whether you like it or not.

Perhaps the most prevalent, and most influential, of all the assumptions that guide perception is this: when other people look at you, they see what they expect to see. Psychologists call this confirmation bias . No one understands you.

From No One Understands You and What to Do About It by Heidi Halvorson

The project sponsor is making them. The project manager is making them. The business analyst is making them (see Assumptions and Constraints Matter Too and Assumptions in Analysis). The developer is making them.

And sure as … your users are making them.

So be explicit.

Identify them up front.

Write them down.

See who objects.

This last point is important.

When I state assumptions I am secretly hoping for objections. An objection now will save me time later. It gives me confidence that I understand the project.

The earlier I do this the better.

We all pass information through our own filters.

Assumptions are one of those filters.

They always apply. They are always being made. Always being made.

Should I say that again?

Why not, this is important.

They are always being made.

Write them down.

Call them out.

Be better for it.