How to deliver the financial data users need

How to deliver the financial data users need


By Andrew Kenney

Accounting and finance professionals increasingly are asked to deliver intuitive real-time presentations of a whole universe of new information sources, not just the company’s essentials. Business leaders have heard for years that Big Data is going to smash together numbers from the factory floor and every other division into crystal-clear charts and presentations.

Yet something is being lost in translation.

Nearly half the respondents to a recent CEB Accounting survey said they don’t receive financial data on a timeline sensitive to their needs. The consulting company also found that most accounting teams in another study group weren’t rated “effective” at meeting information needs.

This friction is the collision of changing expectations about technology. People naturally want their digital business tools – from sales guidance apps to executive dashboards – to feel more like their consumer devices: simple and smart.

“I think that the demand for better user experience is getting hotter and hotter and hotter,” said Elizabeth Benker, who has designed interfaces for employees and consumers of some of the world’s largest brands, from Kraft Foods to Warner Bros.

Her job, in short, is to solve the irritations that can ruin the relationships between people and technology – and the strategies she uses can also help wrangle complex streams of financial data into simple and useable packages.

“What we find is that finance teams who take a little more time to understand the business context that their data consumers are living, day in and day out, are going to be much more successful when they design reports and do ad hoc analysis,” said Tim Raiswell, research head for CEB Accounting.

Obstacles to change

The design quality and ease of use of business software has lagged behind consumer products for a few reasons. In part, it’s because business operations are complicated, and complicated tasks breed complicated interfaces. Older applications may be intimidating to beginners, or irritating to veterans, but they also tend to work reliably. That’s part of why the COBOL programming language, for example, has stuck around since the 1950s.

“In enterprise software, it’s often a herculean effort to make anything functional,” said Benker, a user-experience manager for Illinois-based marketing and consulting firm ZS Associates. “It is difficult to build these systems because they’re having to pull data from multiple sources. It’s a very painful technical experience, and once it’s done and proven, there’s a huge reticence to do it again.”

Still, business software has indeed started to take on fresher looks and layouts in the last few years, and its marketing reflects that. A collection of new data dashboards variously promises to “monitor everything” and let you “ask any question” to “optimise every part of your business” with “no IT help required!”

But bad assumptions and poor planning can dampen the potential of new business software.

“What you find out is there’s so much wheel-spinning,” Raiswell said. “Two, three years after something’s gone live, another stream of consultants and people have come through and tried to format the data in a way that meets the use case. And that battle seems to be never-ending.”

Designing for people

Benker’s team was recently tasked with redesigning an internal app used by a few thousand salesforce employees of a very large client. Most often, these salespeople would use the app while they travelled to their appointments.

“You’re getting into your car, you’re on your iPad, you’re on the go,” Benker said. “‘What am I going to say to this person? How’d I meet them?’”

Looking down to their screens, they would see a lot of information, including heat maps of sales in the area. Pretty impressive stuff, Benker said, but wrong for the moment.

“The process of obtaining the information that I need to be well-prepared for my customer interaction is inefficient, time-consuming – it’s pestering, it’s terrible,” they had told her.

So her team stripped the app down to its basics and presented a redesign to her client. She was confident that the changes they proposed in an early meeting would make the users not just happier but more productive, too.

Management didn’t like it.

Proving a point

“We did a bunch of research and presented this idea to the client, and they rejected it,” she said. People thought it was too simplistic. The new design had far less information and no heat maps. It was like they had taken half the blades out of a Swiss Army Knife.

But Benker persisted: “We really respectfully think they’re going to love it.”

To prove the point, they took a mock-up of the redesigned app out to its potential users. It tried to answer the questions they really had: When did I see this person last? What did they buy last? What were the questions they had from last time?

It worked.

“In my entire career,” she said, “I’ve never had the kind of reception that we had showing the screen. They loved it. Basically, the reps were saying, ‘Build it. I want it now.’ And luckily, we recorded all these sessions.”

Those emotional reactions were enough to propel the project into motion – and the reason Benker won those reactions was that she had studied her subjects through the lens of user experience (UX), which at its best is a research-based method to identify and eliminate the pain points that are ruining people’s interactions with data.

Sound useful? Here’s how to do it.

1. Interrogate the problem

UX says designs should be sourced in people’s habits and preferences – but you can’t expect users to jump up with answers.

“You have to create use cases and get a sense of what it is they’re trying to get and how fast they need to make the decision,” said Larry Boyd, CPA/CITP, CGMA, an expert in decision support and process transformation for Resources Global Professionals in New York City.

Early in the project, corral your stakeholders for 15-minute meetings. Ask them open-ended questions about their objectives, their routines, and their frustrations.

“Are your fundamentals right? Do you know what you need to measure? That, to me, is more important than just having the tool,” said Justus Roux, ACMA, CGMA, and head of business intelligence at Mukuru, a money transfer service for the continent of Africa.

Some designers also like to create “personas,” or composite sketches of potential users, replete with personal details, which they use to role-play their way through potential data designs. This may sound hokey, but it’s a great way to simulate the mindset of a board member or a department head.

“You can deliver something brilliant,” Roux said. “But if it’s not the focus and the pull that the user actually wanted, then you’ve wasted your time and his time or her time.”

2. Make a prototype

The best interfaces, no matter how slick they may be, started life as a sketch. Some designers even create elaborate paper models of an entire proposed app, having their would-be users tap on drawings to simulate the eventual experience.

Eventually, those paper models become digital prototypes. They shouldn’t be pretty. The goal here is to attract criticism, and people are more likely to criticise rough-looking works in progress than polished final presentations, according to designers.

“The most successful ones that help leadership make decisions are whiteboard sessions or wireframes,” Boyd said. “You want it to be 80% there so they can fill in the 20%. What’s missing? What would you need to link out to? What else would you want to say?”

It’s easy to get defensive as the comments roll in, and you may be tempted to ease the tension by explaining your design. Don’t do that.

“The rule is: Don’t demo. Don’t walk them through the software,” Benker said. Instead, ask audiences to explain their reactions to the prototype. “ ‘What is this?’ ‘What does this mean?’ ‘Is this making sense to you?’ ”

3. Keep iterating

If possible, don’t stop with one prototype. Watch how people integrate each version of your design into their actual workflow.

Are they constantly forced to refer to outside sources to complete the task you’re trying to address? Are they paying much more attention to one section of your product than another? Are they using the interface as you expected, or are they developing shortcuts?

“Have the user feel that they’re part of the development process – rather than you going and sitting for two months in a corner and then coming back with this massive product,” Roux said.

Besides keeping the designer grounded, these exercises can make the audience feel invested in the tool – and in the financial data it delivers.

Andrew Kenney is a CGMA Magazine contributing editor.