UXD - User eXperience Design

Site Maps -- Still Needed for Web Apps?

In a previous post, I talked about creating a Use Case Diagram as a means to moving the 60,000’ concept to a level of detail that’ll allow us to begin development. Since that diagram identifies the overall functionality, the team can use that to start designing the data model, writing user stories and generally working towards a more detail view of what we’ll eventually need to develop.

The site map is another diagram I’ve found helpful to bring further definition to the concept.

On some projects, usually those that were understaffed, the site map was typically drawn up after the project was in the end stages of development and only because someone in marketing asked for it. Oh, everyone on the team knew what was being built and the relationship between the areas, but it was all verbal -- no one had taken the time to set it down on paper.

At Pathfinder, we sketch out a site map early in the process to give a physical representation to the verbal concepts floating around the team. The ‘we should separate this’, and ‘let the user skip from here to there’ and ‘oh yeah, both these areas relate to each other’ kind of ideas that float around before requirements are actually written.

The very act of documenting work to further define the concepts and gives the team a visual artifact for future decisions. The site map, no matter how rudimentary, begins to identify and categorize the user activities into a relational hierarchy and provide a framework for the application. It helps in project scoping and planning because it begins to further identify the details of a project, which can then open a conversation as to what is needed now and what can be postponed to later. It is a concrete drawing that you can show the client and ask, do you agree? Is this what you want?

As with Use Case Diagrams, a Site Map gives you an overall view of a project -- not necessarily all the details but a high level view of the end goal. Both documents are relevant because both give you a checkpoint to refer back to once you’re in the details of a project to make sure that you’re still on track to meet the project objectives.

Design can be Used for Good and Bad

Every so often I'm rudely reminded that much of the information I get comes from a source who's goal is to sell rather than inform.  It is those times that I'm also reminded of the critical role that design plays in supporting the goals of the organization (wether they be to inform or to sell) by shaping user behavior.

Case in point.  I use Yahoo Finance to track my stock portfolio and stay financially abreast of the day.   I choose Yahoo over the many others out there because I'm used to it.  It has a simple interface and I know where everything is located.  It also has great tools, and it aggregates information from many many other sources in one place, which I find invaluable.  However I just recently noticed that Yahoo Finance is serving some text ads on the site now.  I wouldn't otherwise be too bothered by them, but they've been designed for the express purpose of looking like real (un-sponsored) content.  They're right up there on the right hand side of the page, occupying the top of one column in a three column layout.  The ad titles are just about the same color as the headlines and links on the rest of the site.  And while the other section titles are all orange and bold--designed to give structure to the page and let you know what section your in-- the only way you can tell that your reading ads is from the truly inconspicuous (light-grey on light blue, thin, all caps) 'Advertisement' header.  

This really infuriates me, especially because it's a finance site, and I can't help but notice the content of the ads.  For instance, right now I'm looking at the front page, from left to right I see a snapshot of the Dow's performance today, a headline saying 'Stocks mixed ahead of jobs report' and a couple of blurbs on 'Hottest China Stock' and '16 Hot Dividend Stocks'.  Now I'm sure you can guess which ones are ads.  And yet I can't help but see the ads and incorporate them into my understanding of the days financial news.  They were designed to be scanned, and that's exactly the kind of information I need to be able to filter out when I'm scanning a page like this.

The fact that these ads persist is a clear indication that Yahoo is concerned less about an informed public and more about using its real estate to extract as much equity as possible.

Powered by ScribeFire.

Get in the Flow (Task Flow that is)

Call them what you like (task flows, work flows, process flows), flow diagrams are an important part of any software project. As a developer, you may be more familiar with sequence diagrams, a nifty way to visualize an exchange of messages between different processes and the order in which they occur.

Well another useful diagram is the end-to-end task flow. This handy dandy diagram shows all the steps necessary for a user to accomplish a task. Buy a pair of shoes? Select shoes, select size, add to cart, go through checkout process. Simple and easy.

And yet, what is it really telling you? Well, a flow diagram gives you an overview of the end-to-end process, the start to finish if you will. It lets you know what the user needs to do in order to start a task (select those really cool shoes) and what defines that the task is completed (display order confirmation). In between those two points are all the necessary steps to go from start to finish.

Initially, the in betweens are very high level (as evidenced by the above diagram). As more information becomes available, the flow is modified, added to, subtracted from and generally redrawn to show not only the user tasks, but also the system tasks (return error message, validate and continue), alternative routes (continue shopping, display upsell message) and decision points.

I've found flow diagrams to be very helpful because they let team members know how their stuff fits into the big picture. Let’s face it, on most projects the end-to-end flow is never developed lineally by one developer. Instead, it’s broken down into pieces and parts and assigned to various people. Seeing the end-to-end diagram up front gives you the overall picture of how an entire feature will play out and, more importantly, shows you how and where your piece fits into the whole. It'll get you thinking about potential points where code can be reused (sweet!) or better ways the data can be used at the presentation layer.

End-to-end diagrams let you see that what you're working on is no longer a lonely story in isolation, but rather something that’s part of a defined sequence that contains a beginning and middle and end. It ties what you're doing into the whole and brings a coherency to the process. This is especially valuable for large features that are spread out across teams and even iterations.

Technorati Tags: task flows, information architecture, diagrams

Color for Developers, part 3

Through a glass badly

"This is not a pipe."  R. Magritte

You are reading this on screen. It is not what I expected.

One of the biggest problems for any on-screen designer is the weird backlit medium we fish swim in. This is true if you are creating interfaces for browsers or desktop applications.

By now you are asking why, why does he continue to torture us with these vague allusions and puzzling suppositions. Well it is just my sick idea of fun, really, but here is a simple test. Make a pdf of your favorite picture of a human. Put it on a flash drive and walk around to a few of your colleagues computers and compare the different displays. Extra points can be scored in two ways:

1] try a PC and any other platform, Mac, SGI, Treo

2] try laptop, lcd and CRT screens. If you can still find a CRT screen, they are fading into the dust of time or the junkyards of third world countries as we speak.

Of course you will find that the image of Britney Spears moments after the haircut discloses an array of skull colors limited only by the number of screens it is displayed on.

Individual hairs may or may not resolve, and the level of contrast will have a happy variety as well. This is where you work. Every one of your users sees this differently.

So great, isn't that a big mess, can we please just ignore it? Well no, that isn't really playing well with others. What we need is a basic strategy for accommodating this tragic reality.

There are commercial solutions to calibration available, or most Adobe programs ship with basic calibration tools. These will help... but only you. There is no way of knowing if your users ever did this, and we know that asking is not a scalable strategy.

Unless you are in a highly controlled situation, in an industry where there is a financial benefit directly tied to color fidelity, you can bet that no one really cares.

So what is the solution?

1] Design it a bit crude. Don't expect someone's screen to display a reliable difference between zero, 10 and 20 percent black, that is too subtle. Try 0, 15 and 30

2] Test it. Test it some more. Don't beat it to death, but it can definitely be too subtle.

There we go. In a few short blogs the secrets of your universe revealed. You have grasped the remote from my hand, grasshopper, do not watch Jerry Springer with the powerful tools you have been given.

Wireframes: Much More Effective than Interpretive Dance

Wireframes are a valuable tool in designing a site or application. They enable us to communicate both the layout and page content to fellow team members and business stakeholders and get their signoff. They’re essential because they force viewers to focus on the content, not the visual design, which means preliminary design meetings won’t get sidetracked into discussions on colors and fonts.

Basically, wireframes are a sketch of the business and user requirements. Since they are a drawing, they allow us to demonstrate how these requirements, nicely bulleted in a list format, are translated to a visual medium. In addition to showing that the requirements are met, wireframes can generate discussions uncovering what may have been overlooked. As the project progresses, we use them to begin explorations on how the user will interact with the screens and which data is affected.

Information Visualization tools

Some would argue that Web 2.0 is a social revolution, not a technological one.  Social networking tools such as Blogs, Wiki's, bookmarking and tagging sites, Mashups, and APIs allow collaboration between users and communities of a much greater quality than ever before. 

As these new tools allow users to share and collaborate in ever more sophisticated ways, social data increases in quantity and complexity.

Emily Chang has posted about a few innovative tools that help users navigate that data...
Visualization and Discovery 

Rapid PowerPoint Prototypes for Ajax and Rich Interactions

As applications take the web from static pages to dynamic screens, how can the designer effectively mock up and vet early-stage dynamic screen designs? PowerPoint provides one possible vehicle.

We have found PowerPoint to be effective because it has very easy to use animation, screen transition and click-through capabilities. While the prototypes we produced were not highly polished, they were highly effective in vetting the ideas for a new website IA with three key groups: stakeholders, developers and graphic designers.

One specific effect that was used was the screen transition called “Wipe”. The Wipe effect (available in up, down, left and right versions) enables easy simulation of things like sliding drawers. You simply make a slide with the closed state of the drawer followed by a slide with the open state of the drawer and apply the Wipe transition.

Though the technique is simple, it is quite effective at communicating the screen ideas to users and developers.

Requirements Visualization, V1

At Pathfinder, we have developed some responses born of our collective experiences to the problem of huge requirements documents.

The problem is that on a complex project, a network of interdependent decisions is constructed, then shoehorned into an essentially linear document. While this functions as a form to analyze these problems, it's very [linear] nature makes it... well, boring! Even developers and designers are human!

The functional result is that it ends up as a doorstop somewhere in the office, or finds a quiet angle of repose near a bookshelf and no one ever reads it. These typically represent months of work by large, passionate teams and great expenditures. Not an ideal outcome.

What can prevent this? With all our focus on our favorite personas, and the scenarios we construct to walk them through, it is easy to forget that the person who was just handed 150 pages of your careful work is arguably your most important audience.

Take a moment and review that the order of the parts feels obvious. Make sure that the document has a clear and accessible structure. This means a contents page with content areas that have immediately understandable names. Even though it may seem unnecessary to you, having spent the last 4 months on it, a general overview that orients a first time reader is appreciated. This sets them up for the detailed decisions that follow. Starting someone in the middle of these processes, as I too often see, tends to make people glaze over and just make it up as they go.

Comprehension is more important than brevity here - at PFA, we find that annotated pictures are far more specific & engaging than trying to describe with only text things that can be easily shown. If that adds pages to the document, it is a small price if it gets read and understood. These visualizations do not need to be elaborate. In fact, we are facile at understanding abstracted representations - look at the drawing languages of cartoons. The messages are clear, despite the fact that Mickey has only three fingers or Charlie Brown has a single squiggle that stands for hair.

In sum, showing what you intend is powerful, yet doesn't need to be elaborate in production. The other side of the coin is to spend endless amounts of time illustrating a solution at the expense of more iterations, but that's another blog.