A case study about devising a system for specifying and signing-off content for reporting. It’s also about handling challenges as a designer, recognising when the brief needs changing, and wearing many hats.
Context
My client is an e-gaming company that operates sports-book and casino products. They decided to launch a b2b service renting their platforms to new operators. They asked me to design a player and platform management system for this service, based on their current admin.
After exploring personas, user journeys, business model canvas and value proposition, initial user interviews, identifying jobs to be done, we prioritised features, and established that reporting was essential to the MVP.
Reporting is a set of data tables for keeping track of player activity and statistics that drive daily business decisions. Each report or table is compiled to give a quick overview of different aspects of the business.
Original Scope
The original plan was, that I design a neat table template that can be used for all the reports.
That content of the reports were to be copied as is from my client’s existing admin. While users of the original reporting system were internal users who were effectively being paid to use it, we had to step up the design to be able to market it as a paid service.
The goal was to make the new report template a lot more clear, ergonomic, and offer customisation options.
User Research: Uncovering Deeper Challenges
In preparation for designing the report template, I wanted to see how they are used, and why each piece of information matters.
I started conducting user studies with internal users: shadowing, and interviews. I printed every report, schlepped the sheets around the office to discuss them with different types users, took notes, grouped and regrouped them, and kept asking questions, almost to the point of being irritating. I wanted to understand what the data in each column represented, why they were important to different users, and why they were grouped the way they were.
As hoped, I did gather the insights I needed to inform the design of the template, however something else really stood out: the data the reports and the information architecture was unstructured and the terminology was inconsistent.
After some investigation, I understood that a lot of details had been changed around in reports over the years. While each of them mostly made sense in itself, the whole set of reports as a whole had not been revised in a while. We had too many reports on our hand, with too much overlapping and redundant information.
Expanding the Scope
Since we were building a product with reporting at its core, we recognised that we didn't just need to repackage the reporting system, but we had to restructure it.
We added restructuring reports to the MVP as a whole new epic.
We added restructuring reports to the MVP as a whole new epic.
Pushback due to time pressure
Although everybody on the project agreed that restructuring reports was necessary, the when was not so obvious.
Stakeholders were conscious of the deadline that had already been pushed back due of concurrent projects on the development team’s plate, and naturally they were weary of putting even more on it.
In the same time, the dev team was afraid that changing all reports would run into an endless logistical nightmare, despite the actual development time being manageable.
I learned that changes to reports had so far been handled on an ad-hoc basis, but there was no documentation to tracking these. Miscommunication and lack of formal sign-off were the cause of frustration and wasted time drawing energy from important work.
Clear Specifications Would Make the New Epic Manageable
I wanted to find a way of fitting the restructuring job into the MVP rather than doing it post launch. I felt it would have been unideal to start out with a product which is more complicated then it has to be, and start changing it around later, after users have managed to figure it out.
Although I couldn't change the fact that engineering resources were limited, but I recognised that scattered and inefficient communication around features and frequent changes were a significant drain on their time. I set out to remove this workflow friction by streamlining a clear and precise specification system and pushed for definitive sign-off from stakeholders.
Streamlining the Specification and Sign-off Process
I used a spreadsheet product called airtable for compiling all the information and checking all the info with the team. I gathered the entire reporting specification into a single cloud based data table. The table had separate tabs for the specification of each report, and an additional one for listing all the row types used across reporting.
Column List
Before getting down to changing each report, I set up a tab to list and specify every column that appears in the reports. Inconsistencies needed to be cleared up between column names, cell data, and formatting. So each column type got an identification number, and all the parameters specified.
The column list is a menu of columns that can be used to create a report.
This is the list of details that can be specified for every column:
• Header: column header
• Short header: the short version of the header to be used when space is tight
• Show short header: a checkbox to be turned on and off depending wether we want to show the short version of the header instead of the normal one
• Tooltip text: for when the header text is not self explanatory
• Example entry: an example of typical of the cell data
• Max length: in characters
• User story: specifies the cell data
• Cell type: text-free/text-option/text-entry/checkbox/date&time/number/percent
• Format: options for formatting date, time and numbers
• Sort-desktop: reports on desktop are always sortable by all of the date/time, number, and percent columns
• Sort-mobile: selecting this checkbox make this one of the columns to sort the report by on mobile. (not available for text fields)
• Link to: Some of the data is linked to the section of the admin where action can be taken on the new information.
Most some of the column specs can be changed at a report level (like formatting and length,) these are capitalised.
Once I set this template up, the UX researcher on the project compiled a full list of all columns based on the existing reports. She could use my notes, and the subject matter experts on the team to get more clarification.
Specifying Reports
Reports are then specified on separate tabs. They can be populated with items from the column list.
Joining Reports: Tabs
Too many reports were putting too much cognitive load on users. Some reports were almost the same so they could be merged. Tabs was a simple way to join related ones, when they could not be merged. The screenshot on the left shows the way columns are specified on the document.
Visual Sign-off
While the above specification format is very precise and leaves little room for misunderstanding, it was not easy to process visually, so I needed to support it with a simplified format. So I set up a google sheet with tabs for each report. This gives a rough idea of what reports will look like, and the information that goes on each tab.
Back on Track
Also setting up a clear framework for specification allowed me to give a clear brief to the researcher, who then prepared the lion share of the specifications, while I could get back on track and proceed with the design.
Subject matter experts on the team assisted us by clarifying details and by doing first rounds of sign-offs. The restructure proposal was finally signed-off and handed over to developers.
This framework enabled us to contain the additional epic in time, and minimise changes requested post development.
After getting past the initial concerns, the whole product team got behind the chore values of the product, even when they needed extra effort to maintain.
Takeaways
This was a large project, and rather than going over the usual textbook design process, I wanted to highlight a specific challenge that reflects the realities designers face—because in reality, projects rarely unfold in a neat, step-by-step manner.
As designers we occasionally find that the job we‘re asked to do for is not quite the right job for the goal, or even that our role is not quite right for the job.
When this happens I try to be proactive in coming up with alternative solutions, even if it means stepping out of my roles, and wearing many hats.
When this happens I try to be proactive in coming up with alternative solutions, even if it means stepping out of my roles, and wearing many hats.
I have redesigned the UI, and changed the data on the example screens in order to keep my client’s business information and identity confidential.