displaying large amounts of data in the Financial sector

14 Oct 2008 - 11:29pm
5 years ago
7 replies
1124 reads
Juan Ruiz
2007

Hello UX experts,

I need some advice in regards on how to display large amounts of

financial information on the screen.

My client is an Insurance Provider. They currently have re-designed an

internal application for their insurance products. As you could

imagine, there is a lot of data to display. Currently they display

the information in a table format (grid format), which extends horizontally and

vertically. For example, column headers are

- Client Number

- Client Name

- Trading Name

- Policy Number

- Type

- Start Date

- Transaction

- Internal ID

- Channel

I was wondering if you could provide advice on how to display large

amounts of data (specially in the financial sector), if you collapse

columns together, or if you have any tricks under your sleeve for

this sort of situation :) are there best practices?

Thanks!

-Juan

Juan Ruiz
Senior User Experience Architect
-------------------------------------------------

hyro

P 1300 800 500 (in Australia)
D +61 2 9215 4279
M +61 421 448 780
E juan.ruiz at hyro.com<mailto:juan.ruiz at hyro.com>
W www.hyro.com<http://www.hyro.com>

AUSTRALIA | CHINA | HONG KONG | NEW ZEALAND | THAILAND
---------------------------------------------------------------------------------------------------------
Hyro is Hiring! For excellent career opportunities visit http://jobs.hyro.com
---------------------------------------------------------------------------------------------------------
ASX : HYO

Comments

15 Oct 2008 - 8:33am
mark ahlenius
2008

Jaun,

what I would recommend, as one type of reference for this subject is to
get a hold of a couple of books by Edward Tufte;

The Visual Display of Quantitative Information (Graphics Press)
Envisioning Information (Graphics Press)

Both are great references (IMHO) and also great coffee table books as
well.

These are chocked full of ideas - albeit not at all web-centric. Many
of the concepts can still be applied to other forms of media. Also
study the WSJ, Financial Times, Investors Business Daily, NY Times, and
other financial papers. Of course be careful not to copy, but adapt. ;-}

best,

'mark

Juan Ruiz wrote:
> Hello UX experts,
>
>
>
> I need some advice in regards on how to display large amounts of
>
> financial information on the screen.
>
>
>
> My client is an Insurance Provider. They currently have re-designed an
>
> internal application for their insurance products. As you could
>
> imagine, there is a lot of data to display. Currently they display
>
> the information in a table format (grid format), which extends horizontally and
>
> vertically. For example, column headers are
>
> - Client Number
>
> - Client Name
>
> - Trading Name
>
> - Policy Number
>
> - Type
>
> - Start Date
>
> - Transaction
>
> - Internal ID
>
> - Channel
>
> I was wondering if you could provide advice on how to display large
>
> amounts of data (specially in the financial sector), if you collapse
>
> columns together, or if you have any tricks under your sleeve for
>
> this sort of situation :) are there best practices?
>
>
>
> Thanks!
>
> -Juan
>
>
> Juan Ruiz
> Senior User Experience Architect
> -------------------------------------------------
>
> hyro
>
> P 1300 800 500 (in Australia)
> D +61 2 9215 4279
> M +61 421 448 780
> E juan.ruiz at hyro.com<mailto:juan.ruiz at hyro.com>
> W www.hyro.com<http://www.hyro.com>
>
> AUSTRALIA | CHINA | HONG KONG | NEW ZEALAND | THAILAND
> ---------------------------------------------------------------------------------------------------------
> Hyro is Hiring! For excellent career opportunities visit http://jobs.hyro.com
> ---------------------------------------------------------------------------------------------------------
> ASX : HYO
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>
>

15 Oct 2008 - 8:51am
sdboyd
2007

I feel your pain on this one, Juan. I deal with the same sort of
issues on most of the internal apps I work on. Your initial thought
about collapsing columns together is a good one.

Looking at the example data you provided, my first inclination would
be to clump Client Number, Client Name and Trading Name together
under a "Client" or "Client Info" heading.
Policy Number, Type and Start Date seem to refer to "Policy
Details."

Another suggestion is dependent on the size of the data. Let's say
that in your example "Channel" is a 1 character alpha field. So
instead of having a column header of "Channel" you could label it
"C". This saves you some horizontal real estate. It does lack an
inherent intuitiveness, BUT you're building internal application and
it's likely that the users will pick up on this naming scheme very
quickly.

Keep in mind, though, that client requests for filtering and/or
sorting on any or all of the columns could send you back to square
one.

A final thought... don't be afraid to push the client to justify the
inclusion of a particular bit of data. I've found that clients will
usually ask for more data on a screen than they need to accomplish
the defined task. My diplomatic approach on this is typically
something like, "My understanding of this screen is that the user is
attempting to [update customer data]. Given that, how does the
inclusion of [minor league hockey scores] help the user accomplish
that task?" You might actually get lucky and have them agree to
*remove* data from the screen :)

I'm behind a Massive Firewall Of Death (tm) here at work so I can't
post any sample wireframes, but I'd be happy to share some examples
for you if you contact me via email.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34312

15 Oct 2008 - 9:48am
Juan Lanus
2005

Juan,

You already have useful answers. I'like to add $0.02.
I designed many applications that displayed data in grids for the user to
peruse, and got kudos.

Firstly, I started by displaying all columns. Not the hockey scores, of
course.
Second, I let the user adjust the column widths at will, also to almost
zero.
Third, the system saved the column widths, as an Excel sheet does, and
recalled those saved widths the next time.

What's the next time? Well, that depends on your application.
I designed and implemented software that saved the geometry settings (among
other things) per user and per report. So "next time" means "the next time
this user runs this same report" in the context of that application.

Steve Boyd's suggestion about narrowing the column headings is valuable.
I'd add that you use a smaller font for headings.
In this vein I implemented in an application a word splitter for headings.
So the user saw tall 3-line headings, but narrow, in order to allow more
columns in the screen. The column header can easily sport a tooltip with its
complete name and even a Wikipedia article in the subject.

I also implemented a rather smart column width calculator similar to Excel's
double-click in the column header's vertical border.
Screen makers are willing to help you in this quest, as they make then much
wider then before. Of course, you don't want to have anything else in the
screen besides data, like navigation artifacts and menus, do you? Well, if
you can't help then maybe implement sort of a blind that politely leaves all
the real estate to the data and reshows the nav stuff when the user shows a
will to navigate.
I always measure the percent of the screen that finally contains actual
data, and many times it's really small: this can be used as an argument to
hide temporarily the branding and golbal nav. Consider using a nice
background watermark image to keep banging the user's mind.

Another useful resource could be displaying the content in smaller sized
font. But not everybody can read small text, for example I can't. This
should't stop you to allowing the users to reduce text size within their
comfort zone.
The font reduction should not trigger a column-adjust frenzy: you'd better
set column widths in em units or so.

All these features need affordabilities but without annoying the user with
many visible artifacts.

Another useful feature is to let the user export the data to an Excel sheet
or similar. I set one-click export buttons in some Windows applications that
would write an Excel file that included all the formatting, like fixed
header rows with light gray background and adjusted column widths.
Doing the Excel thing perfectly requires learning quite a lot of stuff, but
else it's deceiving: you can slap the user a CSV file and let them either
consume it with no frills (deceiving) or have to style it *every single
report *(also deceving).
Notice that in Excel exports the total cells should be loaded thet a
formula, not a fixed number. Because the idea behind such export is to let
the user peruse the information in an active mood, instead of just looking
at it in the screen while drooling. For example a user might be using the
screen content to integrate it into a report for his boss.

Please contact me for any clarifications. Hmmm ... New Zealand ... I'm in
GMT-3 (but it's Spring here!)
--
Juan Lanus

15 Oct 2008 - 10:04am
Josh Seiden
2003

I would second the recommendation to look at Tufte.

The basic issue here is that grids are easy to implement, but rarely
good for users. There are numerous tactics that you can use to avoid
(or minimize) the use of grids in your applications.

I would start by questioning your first assumption: WHY are you
displaying large amounts of data? Is it because the user needs to see
a large amount of data, or is because you are using one
general-purpose display mechanism to serve many needs?

If the user really needs to see a large amount of data, then I would
move to a graphic visualization. That is usually a better way to
create meaning than a massive grid.

If the answer is the latter, then you should start teasing out the
use cases, needs, and goals, and the begin creating more targetted
presentations to support them. These targeted presentations will
likely require less data, and can then be created without using a
huge grid.

I've used both of these tactics successfully for financial services
apps.

Good luck...

Thanks,
JS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34312

15 Oct 2008 - 10:24am
mark ahlenius
2008

Hi,

Joshua makes some very good recommendations. This whole thing also
depends on your target audience. If its financial traders - they are
used to such complexities (not that its a good thing, but they are
accustomed to it), if its general users -especially those of us over
40ish, then vision can become an issue with very small print.

One more thing, if you can get a hold of the Tufte books, make sure you
read and pay attention to his section on "chart junk" - aimed at how not
to do spread sheets. He has quite a bit on that, and its a very
worthwhile read. I like to refresh myself on that from time to time.
Also follow the KISS principle.

best,

'mark

Joshua Seiden wrote:
> I would second the recommendation to look at Tufte.
>
> The basic issue here is that grids are easy to implement, but rarely
> good for users. There are numerous tactics that you can use to avoid
> (or minimize) the use of grids in your applications.
>
> I would start by questioning your first assumption: WHY are you
> displaying large amounts of data? Is it because the user needs to see
> a large amount of data, or is because you are using one
> general-purpose display mechanism to serve many needs?
>
> If the user really needs to see a large amount of data, then I would
> move to a graphic visualization. That is usually a better way to
> create meaning than a massive grid.
>
> If the answer is the latter, then you should start teasing out the
> use cases, needs, and goals, and the begin creating more targetted
> presentations to support them. These targeted presentations will
> likely require less data, and can then be created without using a
> huge grid.
>
> I've used both of these tactics successfully for financial services
> apps.
>
> Good luck...
>
> Thanks,
> JS
>
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=34312
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>
>

15 Oct 2008 - 2:33pm
Oleh Kovalchuke
2006

If by collapsing you mean displaying stacking multiple rows under the same
column heading, I think this is a good idea, which prevents horizontal
scrolling of the grid.
Off the top of my head, Kayak presents search results this way.

--
Oleh Kovalchuke
Interaction Design is design of time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On Tue, Oct 14, 2008 at 11:29 PM, Juan Ruiz <Juan.Ruiz at hyro.com> wrote:

> Hello UX experts,
>
>
>
> I need some advice in regards on how to display large amounts of
>
> financial information on the screen.
>
>
>
> My client is an Insurance Provider. They currently have re-designed an
>
> internal application for their insurance products. As you could
>
> imagine, there is a lot of data to display. Currently they display
>
> the information in a table format (grid format), which extends horizontally
> and
>
> vertically. For example, column headers are
>
> - Client Number
>
> - Client Name
>
> - Trading Name
>
> - Policy Number
>
> - Type
>
> - Start Date
>
> - Transaction
>
> - Internal ID
>
> - Channel
>
> I was wondering if you could provide advice on how to display large
>
> amounts of data (specially in the financial sector), if you collapse
>
> columns together, or if you have any tricks under your sleeve for
>
> this sort of situation :) are there best practices?
>
>
>
> Thanks!
>
> -Juan
>
>
> Juan Ruiz
> Senior User Experience Architect
> -------------------------------------------------
>
> hyro
>
> P 1300 800 500 (in Australia)
> D +61 2 9215 4279
> M +61 421 448 780
> E juan.ruiz at hyro.com<mailto:juan.ruiz at hyro.com>
> W www.hyro.com<http://www.hyro.com>
>
> AUSTRALIA | CHINA | HONG KONG | NEW ZEALAND | THAILAND
>
> ---------------------------------------------------------------------------------------------------------
> Hyro is Hiring! For excellent career opportunities visit
> http://jobs.hyro.com
>
> ---------------------------------------------------------------------------------------------------------
> ASX : HYO
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

17 Oct 2008 - 3:41pm
Juan Lanus
2005

Good point, Joshua: why are we displaying big grids? Actually, it's
impossible to read it all before it becomes obsolete. Or at least without
severe personality damage.

When I face these situations I ask the user what's their purpose. Several
times I was asked to produce s long listing (in paper!) because the listing
has a grand total and they want to see it. Only the total.
We must do what the user wants but maybe not the way they want
(homermobile).

Now, if the purpose is to build an understanding of a trend then making the
graphic is OK.
But if the user is auditing transactions and has to see them in full then
the graphic facet is not an option, which seems to be the original request.

But yes, I'd say that before displaying big listings in a screen we have to
make the user justify that need. Screens are not for displaying long
listings, hence the questions like this that reappear every now and then.

If you finally display the grid then be wary. There are fancy AJAX grids all
around that might not be able to display but a few hundred rows before
flopping, and that will not let the user sort by state AND date, or many
other issues. Offer the guy an Excel file ...
--
Juan Lanus

Syndicate content Get the feed