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.
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!
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!