The Power of Napkin Technical Specifications
Simplifying Dashboard Implementation
Properly defining the task is a mandatory condition for a successful project.
Task Definition
When people hear ‘Technical Specification,’ they often cringe… For many, it’s associated with a futile time investment and excessive bureaucracy. And not without reason.
But, shouldn’t a Technical Specification be about helping developers create a great and useful product, rather than merely shielding them from future conflicts?
What went wrong, and how can it be fixed?
I am convinced that an iterative approach to creating the final visual product is necessary. Over the years, I have found a simple yet effective tool for this.
Here it is!
Napkin Technical Specification
Let’s be honest: demanding a clear and detailed TS with algorithms for all indicators from the client is challenging. In the best case, a response to such a request would be a demand for 100 metrics on one real-time dashboard. In the worst case, the proposal to create several working versions from which one would be chosen for further refinement. This will waste a lot of your resources.
To start work without delay, I use a brief form consisting of 6 points divided into two columns.
In the left column, there’s the logic of construction and the essential facts, such as the format in which the report will be presented, the periodicity of data updates, the key quantitative indicators (KPI), and the dimensions (filters, categories) in which they will be displayed.
The right column contains the creative aspect, associations: These points include ‘customer,’ ‘conclusions,’ and ‘solutions.’ They are very important as they determine the dashboard’s usefulness for the user.
It is the left side that serves as the basis for visualization, so let’s delve into it further.
Logic part
Format and Period
The format is the first thing to determine. It concerns the real scenario of using analytics, how data will be worked with — displayed on a projector screen, in a BI application on a tablet, in Excel on a laptop, or only on paper printouts. If this is not discussed at the outset, the risk of project overhaul is high.
The period should determine how often the report will be used: once a day, week, month, quarter, or year. It’s clear that if an indicator is analyzed twice a year, there’s no point in expending resources on weekly updates.
Key Indicators
On the very first stage, you need to identify the most important quantitative indicators (KPI) that should be reflected. It can be profit, revenue, sales, the number of employees, labor costs, or any other relevant metric. Further components for these indicators can be determined at a later stage.
Categories and Filters
In this section, it’s necessary to specify how to detail the key indicators. For instance, a manager may require filtering by month, a top manager may need to filter by department, and an analyst may request filtering by customer type. However, such an attribute may not exist in the source data. To implement such a filter, it will be necessary either to populate this field in the data source or perform an aggregated intermediate calculation.
Now let’s take a closer look at the right column. While analysts usually have no difficulty with the parameters included in the left part of the brief, they may face challenges with the description of the right part. However, neglecting this is not advisable, as the right column contains questions that have the most significant impact on the project’s success.
Creative Part
Customer
It is essential to precisely determine who will be the primary user, as there are no universal dashboards. The director of sales and the financial director are interested in different sets of metrics, and, consequently, the reports should be personalized. It is especially important to consider the actual user: we may prepare a report for the CEO, but, in reality, the deputy will use it, while the CEO will only sign documents. Even this can affect the desired project outcome.
Conclusions
In this section, it is necessary to describe what conclusions can be drawn by looking at the report: where there are deviations, issues, delays, or other parameters. This is the transformation of data into information, but not yet decision-making. Conclusions logically derive from the indicators and categories in the report, properly presented on the charts. For example, the monthly revenue graph is rising, but profitability is decreasing. And nearby, we see a list of unprofitable projects.
Solutions
Clearly, no dashboard will explicitly provide a solution to the problem or offer instructions for further business actions. The client will have to make those decisions, taking into account additional external information or their own experience. Nevertheless, it’s essential to understand that solutions should align with the conclusions.
For instance, a logical solution for low conversion rates in agency sales might involve increasing commission rates, while a drop in sales within a specific segment could necessitate an increase in the advertising budget.
If there’s no such logical connection between the conclusion and the solution, then something went wrong in the brief. There’s no need to fear that the client will think we are overstepping our bounds. A good manager will understand that this is necessary to make the report more useful. It’s also important to remember that it’s not possible to calculate all possible solutions, but identifying a couple of options to link different parts of the brief is entirely feasible.
Let’s consider the application of a “napkin” technical specification (TS) using a real example.
Case Study: Cost Structure
In one of the major agribusiness holdings, a brewing conflict between economists who provided the financial director with a massive report on cost structure, deviations from norms, and itemized details, and the financial director, who still had to request additional clarifications.
The issue was that, even with all the necessary data, making them the basis for managerial decisions was extremely difficult, if not impossible. During discussions with the client, I was able to formulate the following “napkin” technical specification.
The first line of the table was easy to fill out. The client was the financial director. The format and period were monthly Excel dashboards.
Let’s proceed with the left part. The key indicator was the cost of 1 kg of product, planned versus actual, and the variance. This KPI needed to be visible to the director, broken down by factories, cost categories, and on a monthly basis — this was filled in the “categories and filters” cell.
Moving on to the “conclusions” section: the client needed to understand who was responsible for the cost structure exceeding the norm. There were many cost categories, but they could be grouped into two: those the factory was responsible for and those that impacted the final cost (marketing, logistics, and other support services).
What do we enter in the “solutions” cell? Based on the data, the financial director makes a decision whether or not to award a bonus to the factory director. If the cost norm is exceeded, that’s bad. However, if the factory still managed to stay within its limits, he gets his bonus.
The result of this “napkin” technical specification was that we had the opportunity to focus on the most critical aspects and not get bogged down in the approval of secondary details. We could already sketch future visualizations — almost like on the “reverse side of the napkin” — and immediately show them to the client.
For this case, three options were proposed by me:
1. A horizontal waterfall chart, showing intermediate production costs and the final cost with all ancillary expenses.
2. A ranking of factories by cost.
3. Monthly dynamics of the plan versus actual.
With this, work could commence. Even if the final design slightly differed from the sketch, the content would remain the same. The “napkin” technical specification accelerated and simplified the project’s implementation and helped establish a common understanding with the client.
Here, you can see the final version of the dashboard created based on this sketch.
I hope you will also find such a template useful. It is convenient to have it with you at initial meetings with the client!
Save your time and resources.
