Simplicity is Hard

This article is not about development as much as it is supposed to give you, the developer, a handle on a subject that should be dear to you: simplicity.

You’re a developer, right? You have seen what happens when things are done as simply as possible: less bugs, easier maintenance — beauty emerges.

It’s the simple things, like not having to wonder about what on Earth those three lines of code do in that method you’re supposed to fix. Not having to scratch your head or bang it into the desk because of some crazy code someone else wrote, ages ago.

Your friendly marketer has similar issues. I’d argue that if you know what she’s up against, you might be able to help her. Simplicity is hard, so the more people aim for it, the better.

Simplicity

Let me just say that again: simplicity is hard.

Your friendly marketer has exactly the same problem: she wants answers to specific question with the least possible hassle. She wants to use data to inform other people or herself. The data she gets must easily allow her or those others to understand things and therefore draw the right conclusions and take the best action.

Funny enough, “let’s just give her as much data as we can” is not the answer just as “hire more programmers” will not help finish projects on time.

Your friendly marketer really needs the right data and only the right data.

It boils down to a couple of aspects:

  • Speed — a well-crafted, targeted report helps her get her data faster. There is no need to search for it. No need to change existing reports until they match.
  • Clarity — the less data, the less confusion. When all roads lead to Rome, which one do you take?
  • Usefulness — the marketer does not need all possible data, but she must have some of it. So there is a minimum level of data that has to be provided.

If you think about it, the data that your Analytics implementation collects and the reports or dashboards that it provides are very similar to the inputs and functionality of any piece of software you would write. Below a certain threshold of functionality, nobody cares. Make it too complex and people will shun your tool because they can’t operate it.

Android versus iOS analogies are getting more lame by the hour, but I think it is safe to say that a marketer is not a techie and just like you would probably give an iPhone to your parents rather than CyanogenMod, you should use the same reasoning when you provide data to your marketer.

Simplicity and You

What does all of that have to do with you, the developer?

I think your role comes with some responsibility.

Your friendly marketer will ask you to implement things for her, and sometimes she will ask you for advice regarding whether something can be tracked.

When that happens (and if you do not say no), you should keep in mind that simplicity matters on all levels. You want your implementation to be as simple as possible. The marketer wants access to the data without hassle, and the stakeholders want simple facts.

Only if you and the marketer manage to balance the requirements and implementation properly will all of those fall into place. Only then will people look at the data, analyse it and use the resulting knowledge to make decisions.

The way I see it: if they don’t use what you made for them, you failed.

But here’s the good part: you are not a marketer!

Say what?

Well, because you are not a marketer, some of the ideas your friendly marketer comes up with are bound to make no sense to you whatsoever.

I think that is an incredibly powerful opportunity.

What it means is that you can ask questions, again and again. You can ask “why?” until you know what this new idea really is about. You can use your ignorance of the field to force the proponent to really explain what it is they are trying to achieve.

The old cliche “explain, as you would a child” does make sense, and if the proponent of a new idea can’t do that, chances are the idea will not gain a lot of traction later.

So you can function as a gatekeeper, a sounding board. You can make sure there is no scope creep, no absurd niche cases that pollute data.

Ok, ok, so what now?

Let me suggest some really easy things you can do:

  • make a list of open requests, let the stakeholders rank them — makes it more likely that important stuff is done first
  • prune, remove parts of the implementation every now and again, maybe using the same technique — relentlessly eliminate stuff that is no longer useful
  • restructure the menu (see Adam Greco’s Interface Time Savers post from 6 years ago) — easier access and less confusion will mean more usage
  • document, both requirements and implementation — no longer having to guess when someone asks “why do we have this report?” If you need help assessing the current state, check Variable to Report Mapping and Report to Variable Mapping.
  • deploy a tag management system — added agility is a good thing

Most of all, try to understand what it is your friendly marketer is trying to achieve. I promise you that learning about that will not do you any harm!

10 thoughts on “Simplicity is Hard

  1. Bijan

    Hi Jan,
    again a very good description of what’s to achieve, but remember those who’s intention is somewhat different and more to show how much to work she has and how important she is and how much budget she needs… what are you going to say to her? This is the real ‘fight’, if you can avoid this and follow your advice you will be very very succesful 😉

    Best,
    Bijan

    Like

    1. Good point, Bijan!

      My advice in situations like that: whatever you make for a person like that, put it into a separate menu so you do not overwhelm the other users. Have an “Advanced” menu item, or “Experimental”.

      The latter is also good for things you want to track temporarily, say during a World Cup or Christmas season.

      Like

  2. Pingback: KPIs and Success Events | Web Analytics for Developers

  3. Pingback: A Short History of Processing a Hit | Web Analytics for Developers

  4. Pingback: Making Reports | Web Analytics for Developers

  5. Pingback: SAINT Classifications – the Most Used Feature | Web Analytics for Developers

  6. Pingback: Analytics is not a Debugger | Web Analytics for Developers

  7. Pingback: “Data Layer on the fly” | Web Analytics for Developers

  8. Pingback: Delayed Page Load Tracking with DTM | Web Analytics for Developers

  9. Pingback: Don’t track New/Repeat Visitors! | Web Analytics for Developers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s