Designing for Specific Audiences- in this case Finance

24 Apr 2008 - 9:34pm
8 years ago
10 replies
1201 reads

Has anyone on the list been involved with designing any web applications for
a finance oriented audience?
I am working on a web application that is very involved and complex. And we
are still only in the beginning stages of pulling together design drafts and
a prototype for an 'alpha' audience to test out and give me feedback for the
next iteration.

Interested in hearing any feedback on designing interfaces for this unique

Thank you!

Paige Saez

Interaction Design.Media.Art.Love.


28 Apr 2008 - 6:04pm
Harry Zupnik

Hello, Paige;

Which specific audience do you have in mind? "Finance" is way broad (I've only done about a quarter century of work designing stuff for Financial audiences ...;)
This can include institutional traders, retail brokers/"wealth managers", funds managers/trust officers, small businesses needing to make credit decisions, and individual customers with various levels of sophistication, e.g. someone monitoring their retirement plan, online banking and bill-payers, active traders, credit card users, etc.

These tend to be rather different audiences with very different requirements. Also, venue (place of use) makes a difference - do I want to check my account from a workplace where I generally do something else (like designing websites - so I want to get in and out and transact quickly)? or is my job "finance" so I have the time to access a richer information set and use more analytic tools to support my financial decision making and transacting for my job?

Some general things about "finance" interactions
(1) they tend to be information dense
(2) information often changes rapidly
(3) you often need to see a history (transactions, or market trend)
(4) it's easy to make [user] mistakes and the client company doesn't want to be liable.
So UI, especially presentation, "reasonableness test (in case of a transaction, etc.) can be rather important.

So let's answer the user questions (personna, purpose of interaction, venue, device) and then get I'll be able to help you more ...

Good luck
1 917.696.0707

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

28 Apr 2008 - 11:49pm
Andrea Gallagher

Hi Paige-

I'll echo what Dante said - the professionals in financial services
are very happy with dense information. If you are afraid of making
your screens dense, you can often slow down the interaction enough to
frustrate these users.

This is an area that really needs good personas and task analysis.
I've benefited from personas more in FS than in other industries.
It also helps to be aware and sensitive to the other tools that will
share screen space and attention with yours. These users multi-task
a lot, and often juggle tasks through the day.

Third, get to know the language and use it appropriately in the
interface. As with most experts, FS professionals use jargon both to
speed communication and as a badge of membership.

Hope that helps,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new

29 Apr 2008 - 11:42am

Thanks so much for all the advice so far. I am definitely getting a
better hold on what is being built and for whom.

My biggest concerns so far have been around exactly what has been
spoken to; The level of interaction density, the complicated
interfaces that defy my understanding and the level of complexity
that this particular audience can tolerate.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new

29 Apr 2008 - 12:35pm

I share the experience that professionals in the financial services
industry seem to crave a remarkably high level of information density
and favor what they perceive as "quick" access to information.

For example, in one application we found that potential users
disfavored a navigation design that was deeper because they felt that
having to make extra clicks (navigating down sublevels) was slower
than a broad, shallow navigation. In terms of clock time, navigating
the broad design was slower, but their perception was that more clicks
= more slow.

I've also found that (like a lot of specialists) financial
professionals are very language-sensitive. In a couple of cases I've
worked on applications that received negative feedback because of what
the professionals perceived as misuse of "market lingo" (their term).
This poses some challenges because the lingo can change in subtle ways
from situation to situation. For example, "international" trading can
mean "trading exclusively non-US securities" in one context and
"trading securities of all countries, including the US" in another.

I've also found a wide variation in terms of how "freeform" users want
things to be. Workers (traders) at large financial institutions (e.g.
major Wall Street banks) seemed to favor rigidly defined roles, no
customization, and strict access controls. Conversely, workers who
held the same job title (trader) at small hedge funds wanted high
levels of customization, free access to everything, and large amounts
of self-determination in application appearance and behavior.

Best regards,

1 May 2008 - 6:47pm
Leah Buley

Hi Paige,

I'll add that downloading your data and uploading their own is also
important to this audience.

FS professionals and savvy investors tend to employ a surprising
hodgepodge of tools to run their own calculations. This can include
proprietary tools, for-pay tools, other people's web sites, and
their own homegrown spreadsheets, so if you're offering tools, make
it easy to move data in and out of them.


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new

4 May 2008 - 11:32am
Gloria Petron

I have a few questions to add to Harry's:
- Are your applications client-facing or employee-facing (or a blend of
- Are you on an agency/consultant side, or are you a part of an in-house
design team?
- What is your relationship with the I.T. developers who will be building
the solution?
- Is the solution you're working on web-based since birth, or is it a
migration of a green-screen application to a web-based format?

Here's an energy pellet for the learning curve: read *The Inmates Are
Running the Asylum*<>,
by Alan Cooper, a former programmer who does a great job of de-constructing
the manner in which software development typically plays out. He explains
successes & failures, the mindsets of upper management and programmers, and
the obstacles you can expect to encounter. You're going to be in for a bumpy
ride anyway, but this book can help explain the bumps.

4 May 2008 - 12:05pm
Harry Zupnik

Hi, Gloria & Paige;

Good additions; some comments:
the question about whether the sytem was client-facing or employee
facing is part of what was intended with the "which audience"
question I posed first... you can break "financial" interactions
down further by asking if it's DIRECTLY client facing or INdirect
(e.g. a broker, funds manager or IA betw. client and provider).

For Gloria's last question, I make the heroic ( but reasonable ;)
assumption that there ALWAYS is a piece of back-end or legacy app
that you will have to integrate with.

Why the question about agency v. insider? and relationship w/
developers? These shouldn't affect requirements, altho they may
have major impact implementation details & trade-offs...

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new

4 May 2008 - 12:12pm
Harry Zupnik


Have you already looked at some of the very good "finance-related"
web sites that are out there already? Not knowing exactly which
type of "finance-related" transactions you have in mind, you might
look at Fidelity dot com, Diversified (DivInvest dot com) and
CitiBank dot com (which doesn't look at all flashy but works great.

I can send you to some bad ones too ;(

1 917.696.0707

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new

5 May 2008 - 12:23am
Gloria Petron

Hi Harry,
It's true things like "agency vs. insider" and "relationship w/developers" *
shouldn't* affect an application's requirements, unless we decide to talk
literally about the physical document, which is a whole other topic. But you
answered the question yourself: the physical setup between a UI designer and
a development team has a big influence on how those requirements get built.

Since there's still so much I don't really know about Paige's project,
though, it would be premature for me to get crazy with the rambles just yet.

Best regards,

Syndicate content Get the feed