I redesigned dozens of reports on an enterprise client's business intelligence platform by learning the business, gathering requirements (user, business, and technical) from the client, recognizing UX improvement opportunities, and adhering to patterns in the UX library we had previously established. The ongoing project requires intelligent solutions for data visualization and recommending optimal UX patterns for accomplishing functionality goals.
Unfortunately, I am unable to show any screenshots of the designs publicly for confidentiality reasons.
One ongoing project that I spend a lot of my time on is designing a series of reports for a client's business intelligence platform. This suite of BI sites is used to monitor the sales and customer data of several of the company's teams. The BI platform is united by a common UX pattern library that is also being designed and maintained by my team.
Typically, a business owner comes to our team with a set of sales reports that they want to build or update for the platform. Their initial requirements can range anywhere from an overall message that they want to communicate to a detailed page mock-up, with and idea of the visualizations they want already defined. Our job is to propose the best controls and components to use from a UX and data visualization perspective.
Though each report's process may vary considerably based on the specific needs, we strive to understand the mindset of the users who will be accessing the page and to identify the most important pieces of information that they need to get out of the page. This kind of higher-level information can be a challenge to get from the stakeholders who are often used to prescribing an exact solution to less skilled design teams. However, the more we learn about the information that we need to convey, the better job we can do recommending components, such as one type of data visualization solution over the typical pie chart that stakeholders will often propose.
When designing each report, I typically break the report down into its individual components, then determine whether an existing component from the UX library will work, or if something new needs to be created, in which case I will try to leverage variations of existing components to maintain consistency across the platform.
The nature of this project (in which stakeholders do not have any experience with user experience design) requires me to confidently explain and defend design decisions, a skill that I've improved greatly throughout the course of these report redesigns.
After a few rounds of revisions (stakeholders often need to refine their requirements based on the questions that come up during the design work), I will create detailed specifications for any components not already detailed in the UX library.
As described above, this project is ongoing as business owners look to build new reports and rebuild existing ones. The reports are built alongside the UX library so that any new components can be effectively leveraged on the next reports. Overall, our reports end up being much more effective (from a user experience perspective) than existing reports, and our stakeholders are continually pleased with the work that we produce. Though we do not have analytics in place to track performance, we have anecdotally heard that our users are very satisfied with the new reports.