Thinking as a designer makes you a stronger Data Analyst and Advisor

Each industry progresses with its own timeline, but I think most will converge on some key principles. In this article, I'm sharing my observations on analysts who create impact - specifically the ones that adopt traits that work well for design professionals, and why we should also think of ourselves as designers.

I'm also sharing insights on how I use Count.co, a collaborative data tool that embodies the practices that I've shared today.

Introduction

The problems we analyse are a direct reflection of the systems we work in. These systems could be a biological one, a digital product, or even a farm. While I've had the chance to analyse problems across all these fields, I'm zooming specifically in on the digital world.

Our goal with these analyses is to figure out how to build a product that enhances the value a user receives, with the hopes of seeing a financial return. We'll analyse where bottlenecks exist in the current product and the good analysts will advise on what we can do to mitigate these bottlenecks. We'll identify patterns and trends that we share across the business, and suggest ways we can leverage these to grow. There is a constant process of creation and distribution of insights that will hopefully lead to more iterations of this process.

We're defining our research question, in order to design our analysis, in order to inform how we can design our product.

Nice.

Whether you like it or not, people outside of your design team are making significant design choices that affect your customers in important ways. They are designing your product. They are designers.

So, since we're all responsible for creating in some way, I've learnt to appreciate how creative domains approach designing and collaborating across the business.

The 'Pitching Trap'

Reading the 'Win Without Pitching Manifesto' taught me that the process of pitching is a trap for both the creator and receiver of the pitch. But I've integrated this in an unexpected way –

I've realised that 'pitching' is a weekly occurrence for us as data professionals. We often treat our end report, dashboard, insight as an end product that we're hoping our stakeholders will love. We don't leverage the feedback loops available to create the best possible solution, and we often stop the conversation once the 'work' is done. This process and approach can create a huge distance between us and developing the knowledge and skills to be practical advisors for the business.

I've noticed that UI/UX designers have figured this out. Rather than delivering a polished product upfront, they have the skills and tools to co-create and review their designs in a multiplayer system.

It would help us to move away from the presenter/complier role, and into the expert practitioner. I personally find this so much more fulfilling, and while it can take time to build up the domain expertise behind the problem you're solving, it's a worthwhile pursuit. Conduct those user interviews, share your research questions, create visuals that will help explain what your analyses is aiming to solve.

The Fear That Holds Us Back

One of the reasons that many of us will avoid engaging with key business partners throughout the analysis process is because we're uncomfortable with sharing insights until we've checked it more times than we can count. We know more than anyone that sharing an incorrect experiment result that could cost the business $$, if not be a huge opportunity cost --

What is the downside of making wrong decisions? Not all decisions are equal and not all mistakes are equal. There may be no downside of launching a change that has no impact, but the opportunity cost can be high if we forego a change that has impact, and vice versa..

-- but, this is not the case for most analyses. The fear of sharing unpolished insights can paralyse us into inaction. It can lead us to missed opportunities for early feedback or joint problem-solving.

In reality, the analysis process is iterative.

Sharing preliminary insights, prototypes, even some basic SQL logic, allows for course correction away from undesired outputs. Business stakeholders are a crucial resource for reliable business logic, so I find they readily and easily grasp the core logic behind the analysis when guided by analysts. I personally approach feedback sessions at the research design stage as a conversation with a few visuals and minimal analysed data.

If we want to become partners and advisors for the business, not only do we need the context, but we need to co-design our research with the same goal in mind.

The 'Single Link Source of Truth' 🔗

I mentioned how the design process has become multiplayer due to the influential impact of products like Figma. We're starting to see more web-based analytics tools that can be distributed and collaborated on across teams, using a single link.

Not only that, tools like Count are making it so much easier to analyse and visualise the processes that exists across our business - from visualising user journeys to sales pipelines. These tools are giving us the building blocks to quite literally to lay out current systems as they are, monitor them with a high degree of operational clarity, and design new systems for the business. Take a look at this great example of a product funnel here.

Jump to 34:30 to see what using this platform looks like in action.

I'm getting increasingly excited about the possibility of analysts to become stronger systems thinkers thanks to tools like Count.

Closing Thoughts

At the end of the day, it's about getting stuck into the process, co-creating with the team, and designing smarter solutions. When we do that, we stop being just the 'data people' and become real drivers of business impact.

Thanks for reading, I hope you enjoyed this brain dump of some thoughts I've had over the last few months.

Shoutout to Giorgi Arveladze and Ergest Xheblati for entertaining this thought train.