Lean UX design for Dashboards
How to make great dashboards with Lean UX and Agile
Context
It is my view that the least preferred data output by data analysts is the dashboard. Unfortunately for us analysts, it seems like dashboards are the preferred deliverable to be received by management.
We’ve all been there, management needs a dashboard ASAP, and once delivered it is never looked at again. Given this, it is easy to see why so many analysts would dislike creating dashboards.
However, the problem is not inherent to dashboards, but to the process with which we create them.
Luckily for us, the dashboard design process can be improved by borrowing learnings from the thinking design process and agile methodologies. To this end, we will summarize the key points of Lean UX, and see what actions we can take to actually create value with dashboards.
Lean UX Background
Jeff and Josh understand that while businesses may claim to value agility, the interconnections between departments are still mired in antiquated processes that prioritize bureaucracy or command chains.
In the dashboard creation process, these antiquated processes can be manifested in the form of dashboard requests being sent via email with little detail on so much needed context, or through other processes that have in common the lack of cooperation between users who request dashboards and the dashboard creators.
For us analysts, this means that dashboard requirements may not always be created with the objective of delivering the right information, to the right audience, in the right way. Instead, our requirements may be limited to a list of KPIs and a due date. When this happens, we are sure to struggle to find success.
📜 The principles of UX Design
In order to prevent this, the authors call for the use of cross-functional teams that bring non-designers into the design process. Where conversations are encouraged across functional silos, which drives greater team efficiency and reduces the risk of misunderstanding each other's needs.
The authors also emphasize the need to be comfortable with a non-perfect product out of the get-go, and to learn to adapt the team and the product as information is acquired through time.
You need to know — as a team — that you’re not going to get it right the first time and that you’re all working together to iterate your way forward.
Their approach has two foundations: design thinking and Agile development philosophies.
- Design thinking takes a solution-focused approach to problem-solving, working collaboratively to iterate an endless, shifting path toward perfection.
- While Agile focuses on delivering working software to customers quickly while learning along the way.
We will now highlight some key principles of Lean UX.
1️⃣ Outcomes, Not Output
The authors suggest not defining the creation objective of a dashboard based on what requirements it will contain, but by explicitly defining business outcomes to be achieved with the help of the dashboard.
Our goal is not to create a deliverable, it’s to change something in the world — to create an outcome.
2️⃣ Keep a low inventory
It is better to create only the design that is necessary to move the team forward and avoid a big “inventory” of untested and unimplemented design ideas.
Move quickly. Once you have a design concept for a dashboard that will take a few days to create, execute this, do not wait until you have fully designed an entire conceptual product. Through iteration, you will be able to edit your work in progress, and your work in progress can be used to collect feedback to feed into your next iteration.
3️⃣ Iterate
Lean UX values “making” over “analysis”. There is more value in creating the first version of an idea than spending half a day debating its merits in a conference room.
4️⃣ Create a shared understanding of the deliverable
By bringing the entire team into the planning cycle, the team will develop empathy for business users and the problems they face, while the business users will be better able to vocalize their needs.
Under this framework, the dashboard design is a shared responsibility of all stakeholders.
Shared understanding is the currency of Lean UX. The more a team collectively understands what it’s doing and why; the less it has to depend on secondhand reports and detailed documents to continue its work.
How to execute Lean UX Design
We now know some key principles. However, the transition from principle to practice is not easy.
Thankfully, Jeff and Josh provide key guidelines on certain steps of the Lean UX design process. We will cover these best practices below.
Preparation for cross-functional meeting
We already noted the importance of having all voices represented during the design process. However, we cannot place everyone in a room and expect success. We can, however, take preliminary actions to improve meeting effectiveness.
Preparation steps can be split into two categories,
- learn how our product or prior solutions were being used, and
- learn how others (competitors, other departments, outside cases) have created a product to solve the same issue.
Preparation performed independently by each participant, will provide insightful talking points to start the meeting.
Meeting agenda
Once the meeting starts, the following structure is advised.
Particular attention is needed to the “critique” process. As poor delivery can cripple your team's effectiveness.
Comments such as “I don’t like that idea” provide little value and don’t give the presenter concrete ideas for iterating. Make sure that every team member presents and receives a critique.
Similarly, we need to make sure that everyone can receive critique over their ideas.
Preparation can take place within a few days, and the meeting itself should take place within a day.
Do not fiddle about. The sooner we can find which features are worth investing in, the sooner we can focus our limited resources on the best solutions to our business problems.
Agreeing upon the MVP
Throughout the meeting, individual concepts will be presented, updated, and finally merged into a commonly agreed design concept. This will become our minimum viable product (MVP).
The following three questions must be answered at this stage:
- Is there a need for the solution being designed?
- Is there value in the features offered?
- Is the solution usable?
🚀 From MVP to Deliverable
Once an MVP is agreed upon, it is the task of the analyst to execute it. Following the low inventory principle, we should hold regular check-ins with the rest of the team to verify that;
- we continue to share the same vision and
- the business context has not changed since we last met.
Assuming we split each iteration into three different sprints, our road from MVP to Final deliverable could look as follows:
Where for each iteration of the product, we hold specific meetings aimed to ensure that our MVP still is likely to support our business outcome.
These meetings can be:
- Sketch idea: Come together to define how the next iteration of the dashboard can look in order to accommodate features needed to support the business.
- Testing: Come together to see how the end-users interact with the tool.
- It is a good idea to ask for first-time reaction feedback, where the product is shown live as a demo and feedback is received
- as well as post-days of use by final user feedback, where you let your end-users use the product for a few days first.
Conclusion
Note that the diagram above does not contain an end. This is because all dashboards/products are WIP-ready to be altered when they no longer support business outcomes.
So what would stop a team from keep iterating on the same dashboard? Shared vision. It is because there is a shared vision across stakeholders and analysts over where resources should be allocated, based on what matters most for business, that new projects can be initiated after ensuring that the current MVP is now in use and adding value.
You can recognize a lack of shared vision when the team argues about what features are important or what should be done first. Do not forget that Lean UX must require your team to count on a shared vision.
