The Power of Visualization (part I)

ERP is a domain that is associated with large amounts of data and complex processes. ERP software traditionally uses tables and forms to visualize the data and in many cases processes are not visualized at all. The reason for this is historically: Activities such as planning, purchasing, sales and financial management are mostly about numbers and the way these numbers are "visualized" has hardly changed in the last 100 years. This cash book still looks very similar to the one we use today. This does not make it any easier for people working with it, whether it be designers, developers, business partners or end users.

I believe that we can make things much easier by applying visualization in our every day activities and this does not only apply to building flashy user interfaces or creating sales forecast charts. Visualization can be used to gain insights that you would never have thought of before, it can be used to seduce customers, your boss, your peers and the opposite sex. It can be used to spur creativity, invoke discussion and generate alternatives. And the effort it takes is much lower than you´d think. Let me illustrate all this per activity and object type.

Ideas & Insights

So you have this great idea or insight, right? What are you going to do with it? Mostly, you need to get buy-in, so what do you do? Describe it in an email and hope people will understand it? We are surrounded by many smart people but most of them are busy and don´t want to use their brain cycles to understand what you want them to understand. By visualizing your idea or a problem you make it easier for your audience to grasp what you mean and because you made it less painful, they will reward you with their support (providing that the idea was good of course). Another happy side effect is that by visualizing your idea or problem, YOU will also understand it better. Those who are best in visualizing a problem, are most likely the ones to solve the problem.

Design & Development

From requirement to code is a long way and many things can go wrong. Traditionally business consultants distilled requirements, wrote use cases to capture what the system needs to do and the developer converted those in functional specifications outlining what technology architecture will be used. Nowadays most development companies also employ user experience designers who are in charge of designing the user interface. One of the most differentiating features of these people is that they tend to visualize ideas and concepts as early as possible in the design process. In fact, they start sketching the moment they enter a meeting room for the first project brief. This really helps the team to understand the (same) problem and to evaluate the different solutions before a line of code has been produced. The last months we shared all design work online with the community and solicited feedback in every step. This saves time & money, brings more and better ideas and results in better quality with lower risk. We should all be sketching more often.

Data

The source of all data is in tables in data bases or in spread sheets. This is not going to change anytime soon but the way to present the data is much more flexible. An image (or video) says more than a thousand words so just have a look at this tremendous presentation of Hans Rosling who makes boring statistics come alive. Try to put this in a spreadsheet and make people understand it! There is a great opportunity for us to use visualization in ERP systems when we start to include business intelligence (BI) functionality. This will help us to view the data from different angles and to gain better and earlier insights than with using traditional data views. It also lets us interact with the data. A great example of effective data visualization is the NY Times interactive chart for the 2008 Olympic medal count. One of our community members shared some great ideas for data visualization and manipulation for Openbravo ERP.

Processes

Things happen over time and most of the time the path via which things happen is not linear but depends on certain conditions. This can get quite hard to understand without visualization. I was very happy when the Openbravo team started to model the most common business processes. Now we understand on the most abstract level what task flows we need to support. Everything we design and develop should be supporting those. Process visualization can be used everywhere: From a simple HR process for doing your expense report to helping a potential customer understand how the sign-up and installation will work and when the payment takes place. When I moved to Spain I had to apply for a health card (tarjeta sanitaria) but I was unable to find any process description (not even in words) which eventually made me visit 6 different administrative offices (all with very Spanish opening times) all over the city. Half way I had no idea what form was supposed to do what so I ended up dropping the whole pile of documents on the next desk in the process explaining to the staff: "I just need a health card, take the paper you need and tell me what to do next!". It took me almost a full day.

Pretty Products & Presentation

One study at the UCLA indicated that up to 93 percent of communication effectiveness is determined by nonverbal cues. That was about direct communication between people but it isn't hard to imagine that similar figures apply to other channels. The power of good looks can be used to your advantage. People like to use beautiful products, it makes them feel happy and confident. Your customers are people too, they like to use a handsome ERP system and look at beautiful presentations, pretty invoices and cool looking sales charts. Among techies, aesthetics are normally not considered to be very important, it is all about features: The iPod was a "lame product" according to a post by a Slashdot community member because it did not have wireless and less space than a competing product. S(he) Obviously did not understand that good design & simplicity can beat feature count. There is nothing shallow about liking pretty stuff and you better make things look good if you want to impress.

This was part I. In part II I will give you some tools and methods to let you do the visualizing.

Work with Us on Improving OB ERP´s Business Processes

Ease of use is more then user interface (re-) design; it is also making sure the processes implemented in the application match the user´s mental map and match the way companies do their business. For this reason we have been working on modeling the most common ERP business process flows. We would like to share the resulting diagrams with you in order to collect feedback and improve them. Each diagram documents an abstract business process, which should result in a business-process-specific discussion. It will also provide a natural place for people to discuss current issues about or suggest changes to the current Openbravo-specific implementation.

Another reason for describing the business process flows is to provide better user guidance through our documentation. Surveys told us that this is a key priority for our community and therefore for us.

Please provide feedback per diagram (thread) to validate the correctness and completeness of these flows. Also, let us know when you think that a crucial process is missing. The finalized flows will be used as input for the UX redesign.

Usability Test Results

In the last weeks mockups for the new GUI for OB ERP were tested on 12 users. Let me share the findings with you.

What was tested: three clickable mockups

Test methodology: participants were asked to execute a number of tasks, as described in the scenarios. They were asked to think out loud while doing so. All mouse movements were recorded, as well as the audio (participant talking). A web cam was used to record the user´s facial expression. The facilitator observed the participant, took notes and asked questions in case of hesitation, mistakes and other deviations from the pre-determined scenario path. Other than with the contextual inquiries (user observations) that were conducted in December 2008, I have decided not to post-process(annotations, etc.) the videos as the findings were extremely consistent across all sessions. The sessions were split in parts: 4 tests were done at first and findings were immediately processed into a modified design (biggest change was in the ribbon toolbar). The remaining 8 tests were done using both the initial design and the modified designs.

Findings: The most important findings are:

* Users have difficulty navigating the different master detail views from parents to childs, from grids to forms and back. There is definitely a learning curve but cognitive load seems to be high. I think part of it has to do with visual design but I´m concerned that this can only fix parts of the problem.

* Users have troubles finding menu items (buttons) in the ribbon toolbar. I noticed that the labels I initially used (such as "record") were not ideal, and changing them to more common labels (such as "edit") significantly improved the user´s performance. Still, it took most users a while to get used to the concept of "buttons hidden on tabs". Some users even thought the the form or grid below the toolbar was part of the tab. Here visual design and labeling play an important role but I have the feeling we should simplify, dumb it down. Plonking all buttons (icons) in one bar is perhaps the way to go. Users don´t seem to notice a difference between generic buttons and object specific process buttons but I still want to keep this clean separation, as in the earlier concepts.

* Forms work great. Users love the layout, the nifty sections and the color coding on field and section level for required fields.

* It was not always clear when records are saved and when not. Users did not seem to worry about it at first but seem to wonder what saving mechanisms are applied and demand clear feedback on the status. Auto saving is not always good: an implicit save action is requested for forms to avoid unfinished forms to be saved or even processed.

* Users double click rows in grids

* Users get confused about which tab contains what because of missing (id) labels on the tabs

* Three users had concrete examples of use cases where flicking through the headers while observing a related lines grid update is needed.

The detailed findings can be found here.

Now the next step is going back to the drawing board and solve the issues pointed out by our users. After that, another round of usability test might be necessary. As always, you are welcome to participate in all stages of the design process by posting on the UX Lab Forum.