Sage’s Accpac ERP (enterprise resource planning) desktop application serves Fortune 500 companies. It is a deep and complex product that is specialized for helping businesses manage a wide array of back office functions. To produce the next generation of Sage’s Accpac ERP system we were tasked with merging it with SageCRM (built and managed by Sage’s Dublin, Ireland division), while getting it ready for a possible SaaS play. The immense scale of the product along with the specialized subject matter of accounting presented a very unique challenge.
While the visual designs you're about to see might be outdated based on today's trends, the concepts and process I used is still important.
I started things off by first trying to understand things. I met with different product managers and business analysts to learn about the features they're responsible for and to get a better understanding of who the customer is and what they do. 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).
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 manner, since the then-existing UI had form fields arranged in a scattershot manner. 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 and digital worlds.
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.
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.
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.
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.