In deze blog wil ik het hebben over het proces van het creëren van dashboards in Tableau en hoe fouten kunnen worden gemaakt tijdens dat proces. Ik wil graag een methode toelichten die we gebruiken binnen The Information Lab om dashboards voor klanten te creëren en waarom wij denken dat deze methode succesvol is.

Dus je wilt meer dashboard creëren? En sneller?

Als je Tableau hebt aangeschaft omdat het je in staat stelt om visualisaties en dashboards te maken op een veel snellere manier dan je ooit gewend was, waarbij het waarschijnlijk je traditionele BI pakket vervangt, dan is er grote kans dat je ontwikkel proces er ongeveer als volgt uitziet:

Process Flow

Het creëren van dashboards is eenvoudig, toch?  Je weet wat je eindgebruikers willen zien en daarom maak je een aantal dashboards op basis van hun wensen. Tableau is een fantastische tool om supersnel visualisaties en dashboards te maken op een interactieve manier, je gebruikers zullen versteld staan door de snelheid waarmee je hen de dashboards kunt leveren en ze zijn helemaal tevreden, toch?

Soms is iedereen ook echt blij, als het project op deze manier wordt ingestoken. Maar vaak zul je naar de gebruikersstatistieken kijken op je server en na een paar weken concluderen… oh nee.. niemand maakt er meer gebruik van.

De route naar inzicht is geen lineair pad

Waarom stoppen mensen op een gegeven moment met het gebruiken van de dashboards uit het bovengenoemde proces? Doorgaans omdat het niet het dashboard was wat ze echt nodig hadden, het was slechts enige informatie.

insight. noun. an accurate and deep understanding
inzicht. zelfstandig naamwoord. een nauwkeurige en diepgaande kennis

That’s easy to say but harder to achieve, how we we give our end users something they don’t even know themselves. The solution is to go on a journey together, and the result almost certainly won’t be a straight journey like it was above; it will probably look something like “squiggle” by Damian Newman:

 

the-squiggle1

Reinventing Agile for Tableau

Clearly there is a need for a more agile process to manage this journey and so, by borrowing from Tableau’s Drive methodology, as well as refined using our Data School projects a template (we use this method with our junior consultants in the school for all the projects they do in their time with us).

Tableau Squiggle
Process Description

So yeah a fast turnaround dashboard development process suited for Tableau. You may feel that less than a week isn’t long enough to produce complex dashboards, I would encourage you to still timebox them and then start again following a period where the user has got used to their dashboard. This period of around a week is essential to allow the user to think about the data and insights, their questions may well have changed by next week.

So where did our first process go wrong? Let’s explore the main reasons we often see dashboard creation processes go wrong and see how our new process fixes it.

  • Long development cycles: A lot can be accomplished in Tableau in a short time, and there is a tendency to draw out the development cycle longer than necessary, meaning energy slowly dissipates after an initial creative burst. Our aim in the new process is to keep the energy high.
  • Project Management: Manage the pipeline of dashboards that need to be created but not the process. Trying to control the process too tightly can involve too many people. Instead we look to create time-boxed development cycles and leave dashboard creators to liaise with users or project owners directly.
  • Lack of touch-points between creators and end users: ensure feedback happens live or in meetings, and not at artificial points in the project.
  • Too much documentation: Change control slows down processes and can demoralise requestors and dashboard creators. Let projects evolve and then document pre-release.
  • Aiming too broadly: Dashboards should aim to answer one key business question or have one primary function; dashboards that are too broad tend to not satisfy anyone’s requirements. Time-boxing the deployment helps prevent that happening.
  • Ignoring self-service: enabling users to self-serve in Tableau can help them get insight very quickly, projects which ignore this and try to deliver everything via dashboards can end up over-reaching. If you find the user trying to take the mouse in the kick-off meeting then buy them a copy of Tableau desktop – you’ll make their day.

Ultimately we feel our process gives the user full insight into their data by involving them, live, in the process and giving them full sight of how it develops.

Let us know your feedback

How does our process compare to yours? What do you think works? What doesn’t? Let us know in the comments below.

Next time: adding Alteryx

In the next post in this series I’ll look at how you can go about adding Alteryx into this workflow in order to improve the data side of the process. Finally in part 3 I will talk about Alteryx Server and why it’s essential for productionising the resulting workflows.