As I’ve mentioned, I’ve been working a lot on UIs for internal desktop applications at financial companies. It’s interesting work - it has some unique challenges and some great opportunities.

One of the challenges is that users usually perform very different tasks requiring specialized tools with complex data requirements. For example, researching a stock requires consuming research, news, technical information, market information, mathematical models, portfolio risk metrics, etc. Trying to put all of that in one application is usually chaos.

One of the advantages is that users are typically operating with multiple monitors. Two generous monitors at least; four is common; I’ve heard tell of eight.

So for several projects now we have advocated applying the latter to the former to create an independent windowing framework for complex application suites.

Read the rest of this entry >

An illuminating issue came up on one of my projects the other day - one that touches on one of the inherent challenges of design in an agile process. That issue is re-use of features.

First, a little background. There are numerous broad domains in information architecture / UI design. You got your consumer web sites, ecommerce, application UI, etc. Another way to slice domains is by the dev/user ratio. For most consumer-facing sites or apps, your looking at a small pool of developers supporting thousands or millions of users. On the flip side are internal enterprise applications where the ratio is inverted. That’s where I’ve been working lately. Specifically for companies in the financial services industry. The organizations I’ve been working for have a hundred or so development and support staff maintaining apps for 10 to 100 users. These are core, mission-critical applications (can I sneak more business jargon in there? Let’s see… “strategic” - how about that?).

Read the rest of this entry >

As I have mentioned, I’m an information architect. That sounds fancier than it is. Mostly I draw boxes. Some of the boxes that I draw are grouped into site maps.

Site maps are a visual representation of the organization of a website. Typically, that means the pages of a site, buy they can be used for content or UI features or other things. I am concerned here with the traditional page-based site map as often produced by web IAs.

And I am talking about them because they suck. They are not as valuable as people think. Why? Read on.

A warning: this is going to be very long and boring for anyone who doesn’t spend his entire day worrying about categorizing content.

Read the rest of this entry >

By way of Information Aesthetics comes Web Without Words, which is a project to take a popular web site and reduce it to boxes to get a broad view of the site’s layout. It’s an interesting exercise. The initiated among you will recognize this as a crude wireframe. Normally, we don’t work backwards like this (take a design and wire it), but on occasion we do and it might be worth doing during projects as well. 

If you reduce your design to blocks you can do a quick gut assessment of whether or not you’ve got your hierarchy right and it’s matching up to the original work you did on organizing that content in the first place. If it falls down, then do it again.

Of course, if you’ve read my previous rant about the problem with web design, then you would know that if you were doing design right, it would look an awful lot like the boxes anyway, so no need for the devolution exercise.

Read the rest of this entry >

I’m a designer. Well, these days I get paid to be an information architect. But I am a designer by training. And a web designer by experience.

I also have an iPhone, and I’ve gotten into using Google reader to bring the world to my doorstep. Reader shows up on the iPhone in its mobile version (which I like) and I have opted to use the “Reformat linked web pages for mobile” feature (which I like a lot).

That feature alludes to everything that is wrong with the web.

Read the rest of this entry >

A theme that seems to be running through my professional life lately is complexity. More specifically, the making of things more complex when you don’t really have to. Everyone does this (well, I think; it could just be me; I am given to overthinking things).

Am example: at work recently we were tasked with illustrating a design concept through a scenario. This gets done every day And every time we try to invent a new and better way to do it. That’s largely because I haven’t seen a good way to do it. And also because of the demonic grip of Powerpoint on our clients.

At any rate, what we came up with, via a feedback loop of overcleverness, was a system that would allow us to output our scenario as one big poster, as a PDF, or as images to build into a Powerpoint preso. All from the same artwork. I was pretty pleased with myself.

As you might guess, being outside the issue, our grand vision didn’t materialize and what we ended up with was a Powerpoint that was exceedingly complicated and tedious to modify.

What I thought was a smartly flexible system that would enable lots of different output formats became a beast that was efficient for none of them.

The lesson - which you would think was obvious but certainly wasn’t in this case: solve the problem you got, not every damn problem you can think of.

If we’d picked a format and moved forward, we’d be a lot happier. Sure, if the client wanted us to change later, we’d have a problem. But that wasn’t the problem we got.

My business card says I’m an information architect, so I suppose I should talk about that. 

At my company, we’ve been talking about what information architecture is and what it produces. The staple crop of IA is the wireframe. And I will now proceed to savage it.

Read the rest of this entry >