Just Because You’re An Analyst Doesn’t Mean You’re Not A Designer
Ever heard an analyst or scientist say: “I’m not very good at making presentations” or an engineer say: “I really suck at UI design”? Or, perhaps one of my biggest bugbears: “I just can’t make things look pretty…”?
Why does that frustrate me so much? Because it does a complete injustice to what design is.
“Design is not just what it looks like and feels like. Design is how it works.” – Steve Jobs
So, maybe as an analyst (or someone in any ‘technical’ field), you’re thinking: “but my job isn’t about design, I build the insert technical project here and then it’s up to other people with different skill sets to digest and then ‘sell’ the findings/product.”
Unfortunately, at some point, your work will need to be passed from your brain to somebody else’s, and when that happens, you’ll need to follow design principles to be effective. Another way of describing design is:
The articulation of your abstract thoughts being expressed to others.
This is as true for making a presentation, painting an oil masterpiece, or for making the UI of a new app as it is for sharing code with your colleagues. If these things aren’t designed (and designed well) meaning will be lost, purpose will be lost and the result will be less than optimal.
If you’d like a full deep-dive analysis of some of the design principles or the psychology of people, I couldn’t recommend highly enough ‘The Design of Everyday Things’ by Don Norman. Norman articulates these ideas (and more) in great detail and lays out a number of principles you should consider throughout your creative process. And yes, as an analyst/developer you are being creative.
Today, I’ll run through three of his seven principles, showing how they can help you better communicate your analytics to stakeholders regardless of whether or not they’re technical.
Principle 1 – Discoverability
Discoverability is the art of showing that this isn’t all there is; this is just the beginning.
In the context of ‘Design of Everyday Things’, this is the idea that users should be aware of what’s possible, and also what is not, within whatever system they use.
In the context of analytics, your stakeholders should be aware of what is possible with the methodologies you’ve chosen. Perhaps they know other teams internally that could use it or future pipeline projects that you aren’t yet aware of.
In practice, this means that the design of your communications should reflect where the methodology might take them and the opportunities it can create for their business.
Principle 2 – Feedback
Feedback refers to continuous information about the results of actions. If you click the login button on a system and nothing happens, that’s a source of real frustration. This is why we invented loading screens/icons, notification boxes and Clippy (though maybe the less said about that last one, the better…).
This is especially pertinent for builders of dashboards or analytics apps – if I’ve changed a filter, I don’t mind if it takes a while to retrieve the data, but I need know that it’s busy getting what I asked for.
But we can extend the concept of action and reaction further. Sales people have known for a long time that examples sell better than theory – which is why customer testimonials are highly effective.
Providing scenarios of analysis in use, and demonstrating how it can save the business cold hard cash will get a much greater buy in to your analytics than any amount of technical jargon. This is a method often used to great effect with Econometrics and scenario planning of marketing budgets.
This brings us to another important point: your communications should take into consideration that people want to know what they should do with your insights and what possible reactions might occur. Answer the question: “Okay that’s interesting, but what’s the point and why should I care?” Remember, the business got this far without your analysis…
Principle 3 – Conceptual Model
This is arguably the most important of the three principles in this blog.
“Why is it not the first principle in the list then, Tom? That’s a terrible design choice,” say the voices in my head (and hopefully in yours too!). The reason it’s important (yet third), is because it brings together the other two.
Essentially, a good Conceptual Model (as discussed in ‘The Design of Everyday Things’) is when the “design projects all the information needed to create a good conceptual model of the system.”
With regards to analytics, a good conceptual model enables the consumer/stakeholder to get a good grasp of the methodology in question.
The audience needs to understand what is relevant, how the insights can be used and what the methodology is capable of. Hopefully by combining ‘discoverability’ and ‘feedback’ into your design choices when communicating you achieve this.
Think of your analytics like you think of a car – I don’t need to be a qualified mechanic to drive, but I do need a conceptual understanding of how a car works (i.e. turning steering wheel steers the car and pedals move it forwards/brake).
Similarly, people don’t need to have a PhD in statistics to understand what you’ve done, but by providing an effective conceptual model, you can help them better use the services you’ve provided.
Conclusion
By following just these three principles when choosing how to communicate and what you show to stakeholders you should help them have a better grasp of:
a) What’s possible (and what’s not) with your choice of analytics
b) Why they should care
c) How it all comes together so they have a conceptual understanding of your insights
Remember: design your communication, because designing is communicating.