AT&T Dashboard Project
In this project, I was the UX designer and UI developer. Since the project is confidential, I would like to share the process and the takeaways.
The mission was to design a rich dashboard, reflecting many types of real-time KPIs and aggregations that are viewed, sliced and dices by different properties: types of errors, keywords, periods, locations and more.It was designed together with the product owner and the collaboration of the customer's reps. We identified two personas or users. The first is an executive focused on a generally high-level view of the services' performance. The second is of an expert, mainly interested in the details, drilling down, comparing specific situations, to fine-tune the monitored system and troubleshoot problems.
The process I led was:
1. Discussed with the product owner and key stakeholders about the needs
2. Interviewed the end users to identify the real need (Why dashboard? What are they trying to achieve? How are they solving their needs right now? What will make them better at their job?)
3. Use my programming and prototyping skills to create several clickable prototypes with real data
4. Do usability tests with end users (3) to get initial feedback
5. Adjust the prototype and create another usability round
6. Presented to key stakeholders and used the feedback to adjust the solution
7. Started development of a rapid development tool (Kibana) and got more feedback
8. As KIbana did not address all UX needs, we migrated to a Javascript / d3 solution and after that to Angular
​
It was a tremendous end-to-end experience with some significant takeaways for me:
​
1. Although the vision is clear, it is important to be adaptive and achieve enhancements gradually
2. Advocating a new concept of UX is effective when accompanied by a working prototyping
3. When the client suggests a UX solution which is not suitable, pinpoint the problems and discrepancies,
and show how a different approach & concept will give so much more
In addition, I found I frequently use my development skills to prototype quickly different use cases and demo to the customer and users. These skills also come handy when playing around is needed with charts (e.g., d3), maps, etc. to tailor or expand in code their capabilities for specific needs. It is beneficial where tools like InVision fall short to demo sophisticated interactions with a particular context, for instance selecting in a chart subsets and trying it out with permutations of multiple settings and real-time data.
You can try here the different options in the chart above to better understand this point.
Detailed Lesson Learned
At some point, the customer wanted to add to a report more KPIs. This report which mainly serves the executives on their desktops is also presented on a large screen in a control room and includes a grid of 9 tiles with different charts and maps. The customer approached us with an idea to add these KPIs to the "fully booked" report by flipping the tiles, so clicking a tile would switch between two different KPIs.
At first, this creative idea seemed sensible and quite neat, but after spending more thought, it turned to have some shortcoming. First of all, this solution will not allow viewing all the KPIs at one glance. Secondly, after further analyzing, we understood that these new KPIs turned to be invalid when selecting in the UI some properties, and are not to be presented in such a case.
As said, the idea came from the customer, and we found ourselves in an awkward situation, compelled to kind of push back.
Next, we decided to share with the customer the contradictions that would rise and try to find together a solution. We demoed the different situations, showing the cases it works well and where it causes a problem. This process turned out to be a very productive approach. It revealed that the system comprises a few services. We found each service has it's corresponding KPIs, so instead of cluttering the report with more and more information, we separated it into a few subreports, each representing a different service or view of the system.
Also, we concluded from the analysis that some of these KPIs were not new, but more of a variation on an already existing one, sharing the same data, just showing it differently.
So in this case, instead of adding a new tile, we added to an existing tile a multiple view option, allowing the user to choose how to present the same data.