Designing a Web app UI, part 2: The Concepts

by Tom January 4, 2010 • 04:16 pm



Quite a while back, I shared some insight into a project where we were designing the UI for a soon-to-be-released Web app. Now we’ll take a look at the concepts we presented the client and the feedback they provided. As before, the client and project are held in confidence. Here’s a look at our first round:

Concept 1:


There were some discussion early on about setting this Web app apart from several others by turning to a bold, high-tech interface. We thought the programming tech behind the product could support the approach. We used the option to illustrate some interface ideas that we developed in our sketches—you’ll see options for users to customize the size of the text and cell padding on the financial table. We knew the dark interface would be a challenge, but when it was loaded into a browser, the extraneous interface fell to the background, and allowed the primary work area to be the clear center of attention. Since we had more traditional approaches covered in our other options, we kept this one edgy.

Concept 2:


Since some of the core application programming constraints affected what we could and couldn’t do with the underlying structure, we focused on the usability of the app and what features might improve the experience in the end. During sketch development, we thought an important part of this particular app might be a way to share—in real time—not only updated information, but also context for that information. There were to be quite a few contributors working on interrelated data at the same time, and there would be the need quite often for colleagues to clarify details about a particular value, and since every report was “live”, this needed to happen in a seamless interface. Integrating a robust chat function would allow people to collaborate over reports generated on-the-fly with urgency and clarity.

Concept 3:


This concept felt like it might end up being the closest to reality. We muted the bolder colors of the other concepts and played with a few nice interface customizations. There were also some important visual legacies that users might bring with them if they were used to working with Excel data or Google docs. We worked hard to retain a unique and appropriate UI even as we drew closer to other established applications.

If you were developing breakthrough Web application technology would you develop a visually distinctive interface to complete the package? Or would you keep things familiar and let users settle in before they notice some of the under-the-hood surprises?

In part 3 (of 3), I’ll reveal the final client direction and how we resolved some interesting issues that developed in the refinement stage.

« Back to main