Please Say “No”!

It is fair to say that Adobe Analytics offers a lot of choice. Whenever a business user or analyst is looking for specific data or wants to answer a question, there will be more than one way to do it.

In fact, there will often be multiple ways of doing it, each with advantages and challenges, sometimes even a lot of ways.

Now this is a good thing, of course.

The more different approaches with different characteristics there are, the more likely it is that one of them is very close to the requirements, right?

A bit like if you have a bunch of Lego bricks and they’re all the same size, you will have trouble building the exact thing you want. But if you have lots of bricks in lots of shapes and sizes, you can build anything.

From the programmer’s point of view, choice is awesome.

We are engineers in our hearts, we want to make things, ideally really impressive things, good things.

I have an ask for you: stop it. Say no.

Adoption

Engineers sometimes build amazing things. They (we) have a knack for finding a technical solution to all sorts of problems or situations.

The more stringent the restrictions, the more ingenious the solutions tend to be. Look back some 60 years or so, and some guys in the US were able to build a space ship that navigated to, around and down to the surface of the Moon. Compared with our mobile phones, they did it with paper and an abacus.

But here is the thing: it took around 400000 people and 25 years to do it, because it was a huge undertaking. And the result of all this was a system that could only be operated by people who basically trained half of their lives for their very specific mission role.

This is what Apple was doing right under Steve Jobs: make sure people can use things. Make sure they do not have to be or become mission specialists. Any designer in this world works towards that ideal, sometimes successfully, more often not so much.

And when they are not successful, the thing being built — as adequate as it might be — will not be used. People will not adopt it.

Obvious, isn’t it?

This is why it makes sense for you to work closely with the web analyst(s) or the business user(s). It helps both you and them.

It also helps the business as a whole, hopefully. Someone at some point signed up for analytics because they wanted the business to perform better. The more people use the system, the more likely it is that it will.

tl;dr: adoption is crucial

What can you do?

Why am I telling you this? What can you do?

On one level, you work on projects. People come to you with requests or ideas and you find good ways to implement those. There is no way you have enough influence to make your business users adopt some tool that some other company built, right? Right?

Well, I think there is.

I am no Steve Jobs, but I think a big part of usability is simplicity, or at least that things are straight-forward. Where a geek will love Emacs (Oh yes!) or Sublime Text, most people are more than happy with the Evernote editor.

And the same goes for analytics. The overwhelming majority does not care whether there is one way to do something or 20! Worse, they are actually put off if there is more than one way!

And that is something you can help with!

Step 1 – Ask questions first, shoot later

When someone comes to you and wants something, resist the urge to suggest a solution!

Ask questions, lots of questions. Open-ended questions. Let them flesh it out while they talk. Do not jump to conclusions or suggest anything. Ask “why?” as many times as you like, until you really completely understand them. Do not restrict their train of thoughts in any way.

Chances are they will come up with a reasonable design themselves while they are telling you. Why? Because before they walked over, they didn’t have time to do so. They had some vague idea, but telling you forces them to go deeper. If you do not provide any suggestions (cutting them off, basically) they will go to a pretty good level of detail.

Do this a couple of times and you should see two effects:

1. Your business users will speak highly of your ability to understand them. D’uh. But honestly, it makes a difference!
2. Your projects will be better in a lot of ways: people will be happier with what you build them. They will actually use what you built. And they will even like using it!

Say “No”!

Step 2 – Say “No”

After some time you can move on to the next stage — simplification

Users have a tendency to be too specific, too niche, or to come up with ideas that are too complex. If we listen to them and try to accommodate their wishes, we add our own complexification on top (“they didn’t think about this edge case!”), and presto, a design that is clunky and — frankly — doomed.

So my suggestion is: when someone comes to you and asks “can you implement feature XYZ?” or “can this tool do ABC?”, say “No”.

Chances are the person will look at you in utter disbelief for a moment, then scale down their request. You can say no again until you come to a level that is so simple you can sketch it on a post-it. That’s a good level!

I know you know what I mean. Think back to your Unix days. One job, one tool. It works because it is simpel. I can still use grep, sed and tar even though I have not worked on any Unix-derivate for like 15 years. The concept is good, though, and you can achieve the same.

You will have to experiment with the level of simplification and the number of times you can say “No” without annoying your users too much.

There is also a (tiny) risk that people will say you’re incompetent, because they know this other guy and his developer says “sure can do” to everything he wants. At that point it makes sense for you to come clean with the analytics manager, and I am pretty sure she will not only understand you but also support the idea!

If you put those two approaches into practice, you should be able to change the perception of any highly flexible, customizable and therefore potentially complex and useless tool into something useful and adapted to the actual needs of the actual users.

I’m saying this adaptation is not a question of features and diversity, but it is a matter of taking options away. Leave only the right options.