By andreakendall on Sep 21, 2007
Designing a Business To Business Dashboard
My team and I have been on a journey to design a “Business-to-Business” dashboard. Like any traveler going on a journey, I didn't go alone. This project required a team of international programmers, our director, the Software Experience Design (xDesign) Group and, most importantly, our customers.
What is B2B?
Business-to-Business is “the exchange of information to support commerce”. This is a world that requires businesses to send standardized information. It's a world that allows a doctor to look up information about a patient or allows a factory to get the best price on steel from its partners. It's a world that spans large businesses and small mom-and-pop shops that want to do business together.
Identifying the Users
The first and most important step was to identify our users: the people who the dashboard had to serve by supporting their tasks and making their lives easier.
- Business users
- Dollars and cents — cut waste and increase profits.
- Who is costing us more/less and why?
- Operations users
- Make sure the end-to-end system is up and running correctly.
- View alerts about something that was expected to happen but did not. For example, "Purchase order 99587 has not finished processing".
- Business-to-business centric users
- Track transaction status for standard messages
- Drill down to lowest level of a message and show:
- The Message Hierarchy
- The actual data sent
- Resubmit messages back to the system after correcting errors
- View audit information
Designing for the Web
I had sent off some of our best technical minds to explore what options we had for creating the Web application. This exploration brought into sharp focus that design a Web application is very different than designing a desktop application. It was like the difference between working with bronze or clay: you can create works of wonder using each material but you can not expect the materials to respond in the same ways. Using Swing to create a desktop application was like working with clay: very flexible with a rich set of widgets. Working on the Web was like working in bronze, more restrictive.
However, the rewards for working on the Web were also richer. One reward is that the Web is more available to users than a desktop. Our hectic business user would have access to statistics about his enterprise even while on an important trip. Our brilliant business-to-business-centric user would be able to communicate status about orders to our other users. Our crucial operations user would be able to ensure the smooth running of her business-to-business enterprise even at home. And best of all, they would all be using the same Web-based GUI.
Identifying Example Charts and Tables
Having read the requirements, our team knew that we could not possibly know every chart and table that would be needed to shown on our dashboard. What we did know is that we needed good examples that could be shown in a Web 2.0 application, and which contained data that each type of user would care about. Given these examples the customer could add their own charts and tables. Our team to came up with the charts and tables shown below.
Working on the Mock-Up
With the example charts in hand and an understanding of our development material (bronze), we started to tackle the next major task of designing the user interface. Working with Sun's Software Experience Design (xDesign) group was key, especially given that we had to create a way to allow our users to explore their data. This would require that we invent a way to show a hierarchical structure where a node can have thousands of children — a paginated tree. These experts quickly created screen designs and acted as much-needed guides on the path to creating a mock-up that we could show to users.
As of this writing we are exploring several other looks for this widget by creating a working prototype. However, ultimately we may follow one of my rules of thumb, ‘ when in doubt let the user decide what works for them ’.
Not the Final Destination, But a Good Stopping Point
At the end of this part of the design journey, we had several things to show for our efforts. The mock-up and some running code. We were able to see how the mock-up fulfilled the needs of our users and knew we were at a good stopping point.
- The business user could find out how much money was sent/received.
- The operations user could monitor the health of the system and check key tasks.
- The business-to-business-centric user could find the data they needed to track, fix it and send it back to an enterprise.
We are confident that the design work we have done will help us create the right application for our users, and that, after all, is the point of any journey in design.