4 Replies Latest reply on Dec 4, 2012 8:06 AM by David Roers

    Dashboard technical spec?

    David Roers

      My team is used to writing SSRS report specs that often run into the dozens of pages. Until now, our Tableau reports have enjoyed a free-pass on documentation (largely because of the quick, iterative process we use with our customers), but as we move to formalize Tableau development, that pass will be revoked.  Is anyone willing to share thoughts about how their organizations document/spec Tableau reports?  Maybe a sample or two?





        • 1. Re: Dashboard technical spec?
          Andy Cotgreave

          It is precisely because of Tableau's iterative, fast response functionality that it is very hard to spec out a dashboard.


          Imagine you spend a month, two months, or whatever, gathering requirements. What have you got? A snapshot of what the requirements were TWO months ago. The second people start seeing results, the sign of success will be MORE questions and requests for NEW dashboards. For a lot of organisations, the organic nature of tableau is exactly what they need.


          But, this approach isn't going to work for all. When I worked at Oxford University, my approach for dashboards that would change rarely was to meet with the end users every week for a 6 months.

          • Build something that answers the questions as best you understand them
          • Show it to users
          • Ask them: does this answer your business question? Does it make you want to ask new questions?
          • Go back to the first option
          • Stop when you think you're done.


          You should think of this as agile development, small development sprints, IN CONJUNCTION with the users. We never really had specification documents during this process - just progress documents. We tracked whether or not we were getting closer to the goals, and when we got there, we stopped.

          1 of 1 people found this helpful
          • 2. Re: Dashboard technical spec?
            David Roers

            Whole-heartedly agree all around.  Thanks for the thoughtful response, Andy. 


            Do you do any after-the-fact, as-built documentation to assist the folks who will be maintaining the reports?  I'm thinking of consultants who come in, build some dashboards, and then disappear. In such cases, we sometimes get burned by Agile's bias toward less documentation.  Do your progress documents capture enough details that someone else could carry on?


            Thanks again.



            • 3. Re: Dashboard technical spec?
              Andy Cotgreave

              After-the-fact documenation - we tried that for a while. Tips for this:

              • You can do "describe sheet" to get a copyable text description of each worksheet (Worksheet...Describe Sheet or Ctrl+E). This is v useful but tedious to do it sheet by sheet. Wouldn't it be nice if there was an uber "Describe Workbook"?
              • Having done that for a while and got frustrated, I eventually started hacking the XML. This led to the TWB Auditor (http://community.tableau.com/message/189888) which is a tool you can point to all your workbooks. It will analyse and let you see how everything is put together.
              • And final best practise is to do the following:
                • Put comments all your calculated fields (easier said than done!)
                • Add Comments to your dimensions/measures (right-click a Field name...Field Properties...Comment)


              If you can do all the above you'll be fine. It's hard to maintain the discipline though!

              1 of 1 people found this helpful
              • 4. Re: Dashboard technical spec?
                David Roers

                Great ideas!  I had forgotten about the Describe Sheet feature and hadn't tried the TWB Auditor yet.  Thanks for the help.