Good design for dashboard information systems is more about good storytelling.
Enterprise software users aren't necessarily "different" from people using consumer software, it's just the outcome of their effort is different.
Improving the usability of aging software (and conducting usability tests to get confirmation) is a critical part of any redesign.
How might we redesign an aging desktop accounting package to be a better experience?
The original desktop product started life as an MS-DOS application and had evolved into a complex, Windows-based application. With the move to modernize it with a cloud backend, I lead a team of designers to redesign the software for a new generation of internet-connected Enterprise applications.
When it comes to corporate accounting, there are many different roles to learn about. Data-entry clerks, controllers, sales and marketing, system administrators, all roles in and around the accounting departments of large companies needed to be supported. I spent time with our business analyst and product managers to discuss these various roles to understand what kinds of responsibilities they had, to help start the ideation process.
What are their goals?
Each role had different goals to fulfill. Data-entry clerks had to input accounting information quickly and efficiently. Controllers monitored the flow of information and made sure that account ledgers were complete. Sales people manage large databases of contacts and try to convert leads into sales. Even though these are different goals for different roles, it is all part of one holistic accounting process.
What are their pain points?
Each role has different pain points to address. The main thing to address was the information that was being generated as people perform their tasks. While data-entry clerks need to input accounting information quickly and efficiently, they also need to be error-free. Controllers need to monitor information as well as the performance of the clerks on their team. Sales people need to keep track of where their contacts are and what stage they're at within the sales funnel. How would the system surface the right information at the right time?
I started things off by first trying to understand things. After discussing the customers roles and responsibilities with product managers and our business analyst, I translated those learnings into a user flow that maps out the general process from sales to accounts, and finally to the general ledger (GL). This map was the foundation for the work that was to come.
In looking at this more, I decided that the data-entry clerk would be a good role to start the process of redesigning the application. After all, the system can't work without the accounting data, and the data entry clerks fulfill that crucial task. So the next step was to rethink the invoice entry screen, the UI that clerks use to input the data.
This was one of the later wireframe iterations of that UI. It started with grouping form fields together in a more logical order, since the then-existing UI had form fields arranged in a scattershot manner. It seems a rather obvious idea, but reorganizing the UI led to studying paper invoice forms to try and reflect the way physical documents are arranged so that there would be a stronger connection between the analog paper forms and digital UI that data entry clerks were contending with.
I got help with prototyping this UI and we conducted some usability tests and found that reorganizing the UI, without making significant feature changes greatly enhanced people's comprehension of the interface.
Another problem to tackle was the whole idea of "batches". This is a feature unique to Accpac and is targeted at controllers. Invoices are entered into batches for processing and review at a later point. Once they're reviewed and everything is good, batches get posted to one of the ledgers. Each company has different rules as to when batches get posted and closed. These rules are critical to maintaining the integrity of the data.
The main design change with the batch UI was to create a visual indication of the status of each batch. Posted batches could be greyed out since they can no longer be modified (except in rare situations). Open batches were ones still currently being worked on. Batches marked as "Ready" were ones awaiting review so they can be posted. In discussing with the business analysts, I learned that it's not always easy for controllers to know what's in a batch without them actually clicking on things to find out what's inside. So I also designed a batch summary pane (to the right of the list) to be able to provide a bit more information at a glance.
I originally intended to integrate the batch UI into the invoice UI to help reduce the number of steps involved with document entry but in discussing this further with the business analysts, I learned there was certain business logic built into the UI logic layer that would be prohibitively difficult to change, so I (unfortunately) ended up having to compromise a bit and keep it as a separate UI.
The next thing to start tackling was the actual information system, the main portal dashboard. The problem to solve was how to represent all the most important accounting information in a simple, single page. I also had to find a way to connect the users to particular tasks and applications that they would use on a regular basis.
The basic idea was to summarize a lot of information in various portlets that appear on the main portal landing page, so that with one view, the user could quickly access everything they need. These portlets would be different depending on your role, and even within roles, the UI could be customized to your own specific preferences. The user could also interact with the portlets to get more information as needed.
There would also be a simple menu system to access the different application UI's, as well as a notification center to see the latest activity within the system. There were a lot of new features that we proposed that were fairly advanced for the time, especially since they weren't included in the original application.
Later on in the process, I also proposed a different way of generating reports. I had spent so much time thinking about new ways of getting information into the system, and realized there weren't very good ways of getting information back out in a meaningful way. The filtering tools of the time required users to understand a bit of advanced scripting to actually pull data from the database so that they could generate these "reports" on the fly.
Obviously, the non-technical users will not be able to do this on their own. This meant that anyone needing a more custom report would have to get their sys admin involved to help generate the right SQL query. But with better search tools, we could help users generate these kinds of reports without having to write a single line of code.
The wireframe above shows one of the early concepts for what became known as "Document Inquiry", the new search and filtering tool that gives users the ability to look up information and generate custom reports. It would have been nice to have made it even more simple (in terms of UI design) but this had to be based on some other, more complex query tools already in the system.
Numerous rounds of usability testing were conducted to ensure we were heading in the right direction. If we weren't, the test results would help us get in the right direction. In general, I learned a lot from observing the tests. Additionally, with continued iterations on the design, as well as more interactions across the company, I was able to focus the UI concepts in the right way. I worked with a separate team based in Atlanta, to help generate the mockups and visual styling for the new product.
Just a quick note: the mockups you're about to see were designed by a wonderful graphic designer who was on a different team. Working remotely with a visual designer was challenging, but an interesting experience as well.
Since the team in Atlanta was already familiar with a new UI style, it was decided that we could work with them to bring that new look & feel to this product. It of course had to be different, since this is a product for Fortune 500 level accounting, and the Atlanta team worked on small business and personal accounting, but I thought it would make sense to treat this as a whole family of products with a unified look.
At this stage, it becomes more about the production and less about the concepts. This is where all the details become very important. The company switched to scrum to be able to handle all the implementation work. There was far too much to do and not really enough time to implement it. So the switch to more agile methodologies made sense. As the lead designer on the project, it was a clear win to have me take on the product owner responsibilities for the main portal.
With these new product owner responsibilities, I worked closely with my scrum team to write up user stories that would help us effectively manage our time. I worked closely with our scrum master to review the team's burndown metrics and participated in a weekly sprint progress meeting with the company management. I even created a physical scrum board that mirrored our digital tools so that everyone could see the visible progress we were making, and also give people the satisfaction of tearing up their story cards at the end of each sprint (morale boosters FTW!).
With the collaboration with my scrum master, we managed to improve our productivity over time so that my scrum team was one of the highest performing scrums in the company!
One big accomplishment was flattening the information architecture a little bit. Too often companies (especially enterprise companies) structure software products with deep architectures because while they do a lot of things, their software is often far too complicated to understand. I wanted to flatten it out so that important functions would be easier to discover. I also pushed for renaming some of the simple names. So instead of "Invoice Entry" (which is a noun), I switched the naming convention so that it starts with a verb, e.g. "Enter an invoice". This decision was spurred on by the way our customers actually talk.
Given that this product is not only for the North American market, I also had to work with our remote designers to develop ideas on how to incorporate foreign languages.
Typically, when dealing with Romance languages, the general rule of thumb is to allow for 3x the space as English. For example, if some UI text in English occupied a 2 cm width on the UI, then the Romance languages would need 6 cm to fit nicely in the UI without hyphenation or truncation. In the above bottom image, it shows some different options for displaying Chinese in the UI, which is yet another variation that I had to consider since it doesn't conform to the Romance language rule.
This was a pretty complex project, one of the first major enterprise products that I ever worked on. There was a lot to learn in order to be able to design an effective solution for a new ERP system. But since I focused on following a user-centered process, it was far simpler to keep the quality of the work very high. We used usability testing (instead of actual product releases) as a way to "soft release" our products and could iterate and evolve things from there.
Unfortunately, the overall project stalled with numerous delays, and I left the company before the initial product launch, but much of the core of what I did at Sage is still present in the product that was launched. In fact, looking at some of the product screens today, you can still see the legacy of what I did for Sage, working proudly alongside the members of the User-Centered Design team.
On a certain level, I am glad to not be working on accounting packages and ERP systems anymore :) but it was a very unique opportunity to get a glimpse into a world that I had never once considered as an occupation. There are a lot of rules that govern accounting, and even now, I still find it all fascinating.