How many times have you developed a dashboard or a piece of work and delayed releasing it because of the desire to make it perfect? Have you ever considered the impact of your perfection procrastination and that there may be an alternative way?
More and more organisations and individuals I speak with say this is a challenge they regularly face. The fear of criticism, the drive to validate every data point, to align every pixel, can be debilitating. Development cycles can be extended by weeks and return on investment can be significantly reduced as a result.
On a personal note, I found myself caught in this quandy when designing my September #SportsVizSunday entry ‘The Story of the Solheim Cup’. I had a clear vision of the design I was trying to achieve, but it was a technically challenging one to implement. To do it, to technical perfection, would have required numerous complex polygon calculations and changes to my underlying data. This would have taken a considerable amount of time to complete and I wasn’t even sure if my design idea would be easy to interpret and meet my needs.
With this doubt in my mind, about 1 day into the project I decided to approach the design process differently. I built the design using multiple layered doughnut charts, sure technically inadequate, but it allowed me to test, relatively quickly, if the design hit the spot. Sure enough it did, I was really pleased with the output.
Then came the next challenge, the Solheim Cup had finished the weekend before and, to maximise engagement, I wanted to publish the viz whilst the event was still topical, but AGGHHH! If someone downloaded the viz they would see my technical inadequacies. To make this worse, the viz was failing to open on a mobile device.
I debated with myself the merits of publishing versus the merits of weighting and the case for publication was overwhelming. If I waited to publish the audience for my viz would significantly decrease and I could be honest with my audience and clearly state the viz was work in progress and I would evolve the technical build over the forthcoming weeks (personal admission time, I am still to find the time to do this).
The result of my decision to publish? No criticism, plenty of probing and engaging questions and lots of feedback, perfectly normal for a Tableau Public viz!
And now onto my professional life and time for another personal admission, I used to fall foul of perfection procrastination when leading my Centre of Excellence. In prior roles, I can distinctly remember giving analysts exhaustive feedback on a dashboard, wanting to understand and validate every element of a dashboard before being confident enough to release it to my users.
All of that changed when the Centre of Excellence I currently lead within JLL embraced Agile methodology as our framework for content development. My approach to analytics significantly altered, acknowledging the possibility that a dashboard could be developed iteratively and benefiting from numerous, smaller, feedback loops.
I am not for one minute doubting the importance of accurate data, the importance of rigorous testing, what I am questioning is the need for this to be done to the nth degree and in isolation from your end users. I am also questioning the belief there is ever an end point to dashboard development.
I would passionately challenge people to consider at what point a dashboard can be reliably used, and to embrace seeing your users as part of a collaboration with analysts. Users that are empowered to provide dashboard feedback that is then acted upon in a responsive, agile, fashion by the analyst. Feeling part of the solution. If you create a bond of trust with your consumers where they acknowledge dashboard are living creations you will reduce the ‘them and us’, reduce the risk of being told ‘your data is wrong’, reduce the fear of failure and criticism amongst your analysts.
Of course, this approach only works if you are geared up to acknowledge feedback and act on it responsively. Managing users’ expectations is critical in enabling trust and partnership. In my experience if a user views their relationship with analysts and data as a transaction they will revert to transactional behaviours, raising tickets and focusing on the minutia of a dashboard, challenging why a number if 99.94% rather than 99.95%. However, if analysts are visible to their users and there is an honesty when releasing content, these behaviours can change.
Your users can be forgiving, heck, they can even be thankful that they have access to data and insights sooner. Put yourselves in their shoes, if a dashboard has an important insight, wouldn’t you want to know about that insight as soon as humanly possible? If the insight is sat on the analyst’s computer whilst they feverishly spend days, if not weeks, finalising every pixel, every data point, the risk or opportunity that insight poses will go un-acted upon.
So, if you want to challenge the power of perfection within your organisation;
Embrace your stakeholders and users; actively encourage their feedback.
Release content frequent and often to create a willingness to embrace new insights.
Be clear and honest about your development cycle, explaining that the release of new content is just the start of the cycle.
Set the expectation even your newest content will evolve post release, allowing it to adapt to changing business needs and the experiences of your users.
Be transparent with users, when they give feedback, acknowledge it. If you do not act on it, say why. If you do act on it, say thank you for their help in improving the dashboard.
Respect your analysts by providing them with dedicated time to respond to feedback and implement changes. They cannot do this if they are always expected to focus on new initiatives.
And, a pointer for avoiding perfection procrastination in your personal work;
Ask yourself this, will you benefit from having your work out there, engaging your audience and then evolving it? Will your audience really notice those minuscule flaws or aspects of work in progress and more importantly will they care? The likelihood is yes to the first and no to the second, especially if you are honest with them and explain your desire to continue to make small changes.
This post is the first teaser for my forthcoming Centre of Excellence Playbook blog series, a practical guide of how to enable a successful Centre of Excellence within an organisation, I look forward to sharing more of it with you in early 2020.
Comments