UXD - User eXperience Design

Use a Task Flow to Show “How do I ___?”

Although task flow diagrams (sometimes referred to as interaction flows, process flows or work flows) are a standard in most IA’s toolkits, it can be confusing for those unfamiliar with this particular tool to know when to start diagramming. When in the process is it started? How much information is needed before diagramming? How much detail should be added? When is it considered complete? 

The short answer is to start diagramming once the task is identified because it’ll help in flushing out the requirements. The diagram starts to identify what the user and the system need to do. It delineates a repeatable pattern of activity. It answers the question: “How do I _____________”.

After you have an identified task (I like to use Use Case Diagrams to call out the high-level tasks), the start point and end point need to be established. For example, let’s say your business requirements state that the web application is only accessible by authenticated users; therefore, a user needs to successfully login in order to see the home page. The initial diagram has the user starting on the login page, submitting their information and viewing the home page after the system logs them in.

But wait … I did say *successfully* login, didn’t I. O.k., so we add a decision point to the diagram to show that only successful logins allow a user to access the web application. Don’t worry just yet what the details are for the system to successfully authenticate a user. The purpose of the diagram is to identify the process, not to define it. For now, all that's needed is to show that the login information must be vetted before the system allows access.

Granted, the previous examples are simplistic, but simple is where task flow diagrams start. This basic statement “How do I ____________” turns into an initial task flow, delineating the steps needed to complete the task from start to finish based on the information known at that time. The first iteration is generally the ‘happy path’ and identifies the main flow of a task.  As more steps are uncovered through requirements, the flow is updated and modified to accommodate the new information and show the various decision points and/or alternative paths as they become known. The end result is a flow diagram that conveys both the overall structure of the main user tasks and the sequencing of activities to be programmed into a repeatable activity.

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.

Use Case Diagrams

Projects start off at the 60,000 foot level -- the client wants a widget that allows their users to do X, Y & Z -- and need to be brought down to a level of detail where coding can begin. Something I use to start this process is a version of the UML Use Case Diagram.

For those of you not familiar with it, a Use Case Diagram describes the needed functionality in a system. Unlike flow diagrams, however, the use case diagram doesn’t represent the order or number of times the functionality needs to be executed and it doesn’t display any subroutines. Instead, it’s a high level diagram that identifies the primary tasks an actor/persona needs to be able to do.

The beauty of this diagram is that you’ve now captured the overall view of what the system needs to be able to do in order to allow the user to complete all their tasks. With the high level activities clearly identified, the diagram easily lets you communicate with your client and get their sign off that the needed functionality has been accurately captured. From here, the team can move onto further defining what’s needed to support this functionality: data modeling, user stories, task flows, etc.

It Starts with the User Story

Having recently been asked about the difference between a use case and a user story, I came up with this explanation:

Use cases detail the interactions between an actor and the system in a sequence of steps and are generally used to capture the functional requirements of a system before implementation. Because of their scope, i.e., they take in more exception scenarios, they can be too large to be used for iteration planning since they would be split across multiple iterations. Also, there is a bit of a learning curve to interpreting use cases which can leave the non-technical customer out in the cold.

A user story is a short description of a feature as told from the point of view of the user (generally your persona). They consist of one or two sentences written in the language of the user, and are used to estimate the degree of difficulty to implement (which ties in with iteration planning). At Pathfinder, we also include acceptance tests when we write the user story as a way to set out the criteria that determines when the story's goals have been met. Again, written in plain English so that both technical and non-technical team members understand what success means for that feature.

For our Ruby on Rails projects, we're writing our user stories in a format that'll help the developers convert them into automated tests using the Rails framework:

As a [role]
I want [feature]
so that [benefit]

From here we create the acceptance criteria, which we write as scenarios in a specific format (givens, events and outcomes) in order to help with writing the automated tests:

Scenario 1: Title
Given [context]
  And [some more context]…
When  [event]
Then  [outcome]
  And [another outcome]…

We'll then go on to create flow diagrams, requirements and wireframes to further flesh out the details of this feature, but it all begins with the User Story and Acceptance Tests.

DUX2007 - Ubiquitous Computing

Adam Greenfield of NYU’s Interactive Telecommunications Program gave a great keynote presentation at DUX07 on ubiquitous computing -- embedded devices that are wirelessly networked, imperceptible, mobile and post-gui. Devices that are not perceived as computers by the people who use them, but rather as a facet of their lives. An example he cited is the Nike+ product for runners, which pairs with an iPod to give you feedback on how you’re running while you’re running and records info such as distance, time, etc. You can then sync your workout data to either iTunes or the Nike site, where you can then become part of the Nike+ community. It is a computer, but to most people it's just a piece of plastic you put on your shoe.

Ubiquitous computing. Existing or being everyware. Perceived as a facet of the user’s life. Eroding the distinction between product and service

Consider the automobile. When the first Model-Ts rolled off the assembly line, the car was a product. You drove it here and there and that was basically it. With the addition of On-Star, the car’s autonomy eroded as it was now networked with a diagnostic tool, roadside service, emergency contact, etc. The perception of a car as only a product began to erode as well; the car began to evolve to a platform. Fast forward a decade or so and we now have car as a service -- the Zip car. Glimpsing into MIT’s Smart Cities project, we begin to see the car as an interface to the city and not the engine.

As designers, then, our challenge is to design for these product/service ecologies.

Back to the Nike+:  although the device is basically a pedometer it only works for runners, not walkers. In addition, participation in the Nike+ community requires Flash because that's what the Nike site uses. This is a closed ecology and by their very nature, closed ecologies are brittle. Greenfield, therefore, advocates designing these products/services to use open frameworks because of their openness, their ability to be flexible and extensible. The downside of an open framework is a loss of control and for companies heavily vested in controlling their brand, this option may not even be considered. His argument, however, is that open frameworks aid in a product’s long-term viability.

Some final thoughts from Greenfield:

• As designers, we can no longer assume that the product we design will be a standalone product.
• Everything that can be networked, will be.

A final thought from me: it's an exciting time to be designing.

Technorati Tags: Design, User Experience, Usability, DUX07

DUX2007 - Data Visualization

Data visualization was touched upon a number of times throughout the DUX07 conference.

In David Pescovitz’ keynote address on Monday, he mentioned that since the 1980s we’ve seen three waves of technology: PC Computing, communicating, and sensing. We’re now in the fourth wave which is sense making -- how do we make sense of all the data that’s out there. How do we deal with search queries that return hundreds of thousand of lines of results. How do we start to make connections between the data.

One way we deal with sense making is through data visualization -- a concept which is starting to filter out beyond the research labs into the commercial space. Through data visualization, we can take huge sets of information and present them in such a way that it:

• allows us to immediately see how items are related to one another;
• gives us a more immediate way to see patterns;
• becomes a default to try and understand huge amounts of information.

In addition to visualization, Pescovitz touched a bit on how we're using collective filtering to try and make sense of all this data. We turn to social networks we may trust, such as Digg, to take advantage of the filtering layer created by that network’s society. Anything to help us get a head start on parsing the data.

Later on in the conference, Nick Cawthon talked about aesthetics and efficiency in visualization of data. His talk referenced research he had done using different types of data visualization in order to determine what participants thought of the graphic (pretty or ugly) and whether or not it worked (they could complete a task such as finding a file). An interesting outcome was that the higher the user-rated aesthetic, the more reluctant the user was to abandon that particular data visualization. At a basic level, if the interactive graphic was perceived as “pretty”, the user was willing to spend a bit more time trying to learn how to use it.

Fascinating ideas and I know we're just scratching the surface of its potential.

Technorati Tags: Design, Information Architecture, Usability, DUX07

DUX2007 - Simplicity

Too often, the overarching requirement we hear from clients is that the product must be simple to use. As designers, we nod our heads and agree that yes indeed, simplicity is a worthy goal for this project, without ever defining what is meant by simplicity.

At the opening night of the DUX07 conference, B. J. Fogg, from Stanford University's Persuasive Technology Lab, talked to us for a bit via video about his recent explorations into simplicity. What exactly does simplicity mean? What are the determining factors of simplicity, i.e., what am I looking at in order to rate whether or not a product is simple to use?

To Dr. Fogg, simplicity is not a characteristic of the product but rather a perception of the experience. From his studies and research, he's determined there are six elements of simplicity:

• time - can I spend the time learning to use a new product? no? then it's not simple
• money - can I spend money on a new product?
• physical effort - does it require exertion beyond my usual effort?
• brain cycles - do I have to think for a long time?
• social deviance - does it go against the social norm?
• non-routine - does it break my routine?

These six elements vary by individual and by context and there are trade-offs. For example, if I'm a college student who has time but not a lot of money, I might be more willing to invest my time in learning a new product than, say, a business executive who doesn't have the time but would be more willing to spend a little more money on a product that doesn't require a lot of time.

Simplicity, therefore, is a function of the user's scarcest resource at the time. To state it another way: a product, task, etc., is truly simple until it requires a resources that's not available. But remember, Dr. Fogg said that simplicity is determined by the perception of the experience. Which means a task can be perceived as simple if it uses less resources than expected.

Now I'm not saying that from now on we market our products by setting the expectations high to guarantee the perception of simple .... but it sure is tempting.

Technorati Tags: Design, Information Architecture, Usability

Busy. Busy. Busy.

I've been a tad bit busy lately starting up one project and entering the UAT phase of another. More importantly, though, I'm still alive in my Pick a Loser football pool (for those of you keeping track, Arizona kept me in the game). In the meantime, here are some links you may or may not find interesting -- click away at will:

• Too often, implementing search engines within a project are an afterthought rather than a well planned feature. Read up on Strategies for Improving Enterprise Search to prevent having a "neglected orphan" in your project.
• Not sure how to break it to the Marketing Director that the approved brand colors just don't translate well on the web? Don't Let Branding Kill Your Brand gives you some useful discussion points for extending the brand experience.
• It's all about the Experience, my friend. Peter Merholz explains it best in Experience IS the Product.
• Designers Rule! 'nuff said.

iPhone and Air Travel

I just might need an iPhone. Let me back up a bit. When the iPhone debuted, our CEO purchased one for the office so we could take turns using it, playing with all the features, admiring the GUI and generally looking cool at the local neighborhood hangout. I loved it but not enough to buy for various reasons (couldn’t use one hand to hold and type, didn’t fit in jeans pocket, too nice to just throw in the bottom of my purse, no iChat). So, I looked cool for a weekend and then turned back into regular me come Monday.

Well, the other week I was 'lucky' enough to once again experience early 21st century air travel which, as you know if you’ve traveled lately, means delays, delays, delays. The plane is late, the crew didn’t show up, the gate changed, the gate changed again, it’s sunny outside, it’s the third Tuesday after the fourth week following the geese flying south, etc, etc.

Luckily I was traveling with my CEO who had the foresight to bring the iPhone. Which led to my iPhone epiphany: when you’re stuck on the tarmac hoping that #49th in line isn’t really as bad as it sounds, surfing the web is a much better distraction than counting the planes as they’re taking off. And surfing the web on a cool device just adds to the sweetness.

Thanks to the iPhone and EDGE network (as slow pokey as it is), even when sans wifi I can still waste a considerable amount of time checking email (personal not work), checking faa.gov (for further delays), catching up on some reading (love Safari Books), using the widget to check random cities forecasts (because I can) and generally doing most anything to avoid pulling out my laptop and doing meaningful work. Beautiful! If I continue to travel (which really means sitting on tarmacs bored to tears), I just might have to pull out the old credit card and contribute to Apple’s bottom line.

For an actual review of the iPhone, check out what my colleague had to say.

Technorati Tags: iPhone

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

Personas and Football

This year I’m once again in the Pick a Loser football pool*. Each week, I pick an NFL team that I believe will lose and if they don’t lose, I’m out of the pool. So, for example, the first week I selected my team, the Chicago Bears, to lose (so much for fan support). They complied so I'm still in play. I can only select a team once; therefore, da Bears are off limits for the rest of the season (even though I’m fairly confident they’ll lose another game or two).

My point here is not to kvetch about our quarterback (don’t get me started) or our running back (oy), but to mention that once you Pick a Loser, you start experiencing the NFL games a bit differently. It’s not that you’re actually outright rooting for them to lose (poor sportsmanship, old bean, not at all done), but you begin to look at which team excels in mishaps, penalties, and/or position weakness, or which team is thrown off stride by an unexpected change in personnel, and how you can exploit that to ‘win’ that week.

In other words, when picking a loser I am adopting a different persona than when I pick a team to win. I have different goals and objectives, looking at the stats (data) differently and end up going down a different path (workflow) to make my selection.

This, my friend, is the point of having personas on a project. You use them to identify the different ways a user needs to interact with your product -- their point of view determines the different paths and interactions they need to take in order to achieve their goals and objectives. Once you know the different points of view, it’s a lot easier to design a flexible workflow that accommodates your users. A win-win for all.

As for me, I survived week 2 (the Chiefs in case you're interested) and now need to figure out my week 3 loser.

*disclaimer: naturally for all the kiddies out there, you should never try this at home because gambling causes your hair to fall out


Technorati Tags: personas, user experience, design

Powered by ScribeFire.

Design Doesn't Just Mean Color

In discussing our SDLC process with some colleagues, I pushed for having a separate phase between Discovery and Development; a phase where we can take the knowledge gained from Discovery and begin sketching out high-level solutions in order to get a handle on the scope before going into iteration planning. In other words, a Design Phase.

I quickly discovered that some people hear the word ‘design’ and automatically associate it with the look and feel of the GUI, regardless of what else is being said. Until I understood that, their argument that there was no need to call out an entire phase for design made absolutely no sense. To me, using design in this context means to figure out how to do something at all levels, i.e., taking the requirements (Discovery Phase) into high-level schematics (Design Phase) to better understand their relationships, dependencies and impact in the end-to-end process. Obviously, I hadn’t explained that well.

Much conversation ensued, including the standard weeping and wailing and clutching of the pearls when passionate people get together. Amazing how we were all speaking English and yet totally missing what was being said. Until someone (the former English major, of course) effectively put us back on track by saying “Ok, but what do you mean by ....”

Ah-ha! Define the terms. With a BA, IA, and Tech Arch conversing, we found we were using the same terms to mean different things and different terms to mean the same thing. Well once we started speaking the same language, we agreed there is merit in having a separate phase specifically for design and revised the diagram accordingly. As a team, we were then able to define what that means to our process. 

I could say that as a team we designed our SDLC process, but I’m not even going to go there.

Technorati Tags: SDLC, Application Design, Design Phase

We Don’t Need No Stinkin’ Requirements

The other day I was reviewing a statement of work for a potential project when the client came to  the line item allocating time for requirements. Oh, the client stated, we don't need to gather requirements. We do Agile development.

*Sigh* This myth of no requirements needed seems to be prevalent lately.

Well I hate to break the myth, but projects still need requirements regardless of the method used for development. The reality is you can’t create something unless you know what it needs to do. In order to know what it needs to do, you need requirements (business, technical and user).

The differences come in with the methods for gathering requirements. Some teams make requirements gathering the central activity, creating documentation detailing everything down to the nth degree before development begins. Other teams put less emphasis on knowing all beforehand and instead start with sketches or three sentence "stories", knowing that details will be filled in and added as the project progresses. Side note: make sure you have some way of documenting those hallway conversations because, yes, those are actually requirements gathering and it's good to keep a record somewhere accessible by the project team.

At the most basic level, the purpose of requirements is to define the problem you're trying to solve. Whether your team waits for a complete definition of the problem before starting development or starts with the basic outline depends on your development method. But you still need requirements. After all, if you don't define the problem, how do you know when you’ve solved it.

Not sure how to write requirements? Check out my colleague's post: Writing Requirements

Artifacts of a Presentation

We had an company brown-bag lunch the other day, presenting a case study of one of our Agile projects where UXD and Development are integrated into one, big happy family. It was a great talk, explaining how UXD fits in with the Agile process and highlighting the bumps, expectations and jargon differences all members had to overcome in order to meld as a team. Discussion was generated throughout the lunch, and we all agreed that we’d like to continue the talk at another brown-bag. Good feelings all around.

A pity that the dynamic of the talk wasn't captured on the slides. As we’ve all seen on a million other presentations, the slides displayed a bulleted list of talking points. Very high level and maybe effective during the presentation but loses all effectiveness after the fact. Unless you were an attendee, reading the bullet points afterwards will only give you the vaguest idea of the topic and probably won’t even hold your interest long enough to finish viewing all the slides.

And yet, think about it -- this file is the artifact that lives on as a representation of the talk. It should be strong enough to be used as a marketing piece; or a blog posting; or the foundation of future talks. Which means it should be able to stand on its own and be meaningful to readers who never attended the original presentation.

What is Role of an IA?

I was recently asked what the difference was between a BA and an IA. The person asking mentioned that a BA can end up doing wireframes and an IA will at times write business requirements, so how do they differ.

While the skills may overlap, I think the difference arises in the point of view each bring to a project. The BA tends to be more business focused, sussing out the needs and requirements of the business. The IA tends to be more user focused, championing their needs and desires. (Yes, this is overly broad but let's go with it for now.) That doesn't mean that BAs don’t "get" user-centric design or that IAs can't write business requirements. However, while we may have overlapping skills, I think where we diverge is more in our focus than our skills.

It's this divergence of focus, in fact, that brings a richer element to a project team. In an ideal world, well-designed software will meet the business needs, the user needs and the technical needs. To achieve this ideal world, a project team needs members who can understand and balance the needs of all three and still meet the release date. Rarely can one person fill all three roles since they are usually not an expert in the world each role represents. It’s the understanding of the nuances of that space that enriches a project.

We’ve recently started a BA/IA collaborative group at Pathfinder -- an informal group that'll meet, discuss successes, frustrations, etc.,  and hopefully come away with a better understanding of the strengths we each bring to a project. I'll let you know how it goes.

Agile UXD

Instead of the typical hand-off of deliverables accompanied by a firm handshake and a heartfelt "good luck!", recent projects have us iteratively engaging with both the business stakeholders and the developers early on in our design process. Yes, we've gone agile and that's not necessarily a bad thing.

Once a project has the green light, we begin by directly working with development in an iterative fashion, bringing them into our process and getting their input early on in the project lifecycle. First up, translating the initial requirements into visuals -- defining actors, diagramming the user activities, task flows and personas. During this flurry of visuals, we're presenting and discussing the diagrams, etc., with the team to determine that we’re on target and to get their input. From here, iterations of screen flows and wireframes are diagrammed and discussed with the developers to demonstrate how the presentation layer and user interaction are being envisioned, get their input, check that requirements are being met, that the back-end can support the design, etc., etc. Rinse and repeat.

Design? Meet Research.

A running discussions I have with my mom revolves around a cellphone: I think she should have one; she disagrees. I say it makes sense to carry one in case of emergencies; she says her regular phone is good enough for her. I say her regular phone doesn’t work in the car; she states that you shouldn’t talk and drive. Her logic defies a response.

But what I think she really dislikes about cell phones is that they’re just too complicated to use. When my mom looks at my phone, her first question is, well how would I know how to use it?  A valid point. She is accustomed to a landline -- you pick up the handset and there’s a dial tone (no, don’t even start -- she has no cordless phones). Her phone has raised buttons, not a flat touchpad, and these buttons contain numbers, not icons. (I have to admit, I don’t blame her about the icons. I couldn’t even begin to describe the icon on my phone to pick up a call -- it has no name. You have to train yourself as to its meaning.) What she really needs is a phone designed just for her.

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.

The Art of the Thumbnail

I’ve been a designer for a number of years and during that time, I’ve encountered many people who refuse to sketch out an idea because, as they insist, they’re “not artists”. Instead, they rely on verbal skills and attempt to paint a picture of a concept that probably sounds really great in their head, but just isn’t sounding all that great in their description. And even though they realize their audience isn’t even remotely on board, they’d first resort to interpretive dance rather than sketching out an idea. Because, as they claim, they’re “not artists”. Well neither am I. In fact, finger painting back in kindergarden was probably the pinnacle of my artistic career.

However, I did learn about thumbnail sketches, which are very small, rough sketches that let you quickly outline the basic elements of an idea. They’re an easy way to visually let other people know what you’re thinking. By their very nature they’re not a pretty or perfect drawing--objects overlaying other objects, lines scratched out, arrows pointing to a different version, a big X to abandon the initial idea which is now evolving into a new thumbnail, etc., etc. They’re small drawings, done quickly to work through an idea.

1 Picture == 1,000 Words

For most of us, visual presentation has a greater immediate impact than text or numbers alone. Graphs are effectively used in presentations for that very reason: they quickly convey that Column A is larger than Column B, or that Line 1 has outperformed Line 2. They allow us to easily grasp the overall concept before drilling down into the details. When done well, they allow us to convey complexity with ease (see Tufte, Edward).

When a search engine visually presents the results in a manner that allows me to quickly grasp the depth of the search, quite naturally it catches my eye. Grokker.com is a search application that displays the results both in an outline view and a map view. The user can toggle back and forth between the two views before selecting their preference for viewing the results.

Nice Reference Tool

There I was the other day, skimming through the New York Times online when I mistakenly double clicked on a word (which is why I shouldn’t continually mess with my mouse settings, but that’s another post). The next thing I knew, a popup window appeared displaying a definition of the very word I had double clicked. Disconcerting at first but with a closer look I realized  that the New York Times has given me a reference search tool right at my fingertips.

Putting it to work, this time intentionally, my double clicking on “hubris” returned the following:

The Evolving Web

Semantic Web. Web 3.0. The Intelligent Web. Whichever terminology you want to use, it's a vision for the Web in which information is given explicit meaning, making it easier for machines to automatically process and integrate said information.

Currently, the Web is based mainly on documents written in XHTML, a markup convention that is used for coding a body of text, interspersed with objects such as images and interactive forms. These documents are designed to be read by people, not machines.

With the semantic web, content will be able to be expressed in a form that can be understood, interpreted and used by software agents, thus permitting them to find, share and integrate information more easily. It involves publishing the data in a language specifically for data (Resource Description Framework (RDF)), so that it can be manipulated and combined and presented to the end user.

Don’t Confuse the User

You’re the team lead for developing the next killer app, and word is passed along that the marketing campaign is being built around the user-centric design of your new app. Unfortunately, no budget has been allocated to hire someone with the desired skill set to achieve this lofty goal. Your developers are heads down into the code and have neither the time nor interest to become user experience gurus. What to do?

Establish a set of guidelines for your developers to follow. It won’t cover every scenario but it will encompass the basic rule of usable interfaces, to wit: don’t confuse the user. Such things as deciding on and applying a consistent terminology (e.g., section names matching up with navigation names), using expected widgets (checkboxes v. radio buttons), and applying consistent behavior (too numerous to mention) are the backbone to creating usable software. If there’s time, add in messaging for the user -- success messages and waiting messages (such as ‘retrieving data,  please hold’) are vital to assuring your user they didn’t make a mistake and a good way to prevent double clicks on submit buttons.

Listen, the reality is that most projects are not fortunate enough to have a separate user interface design team. Anything that can help your developers to at least start thinking about issues regarding user interaction is a good thing. Creating a set of user guidelines is a good way to begin.

#*&)#*$)# Software.

Nothing is more frustrating than having your software beep at you when you’re trying to do something you *know* it can do, and you’re flummoxed as to why it’s resisting your every effort to continue on with your work. All attempts are met with the same impersonal beep, whereupon you conclude that (a) the software hates you and (b) your only recourse is to begin swearing with enough proficiency and creativity to make a sailor blush. You just might be the victim of a mode error.

Wait, how did I get here?

The importance of navigation is a given when designing a site. Design it poorly and it’ll have the same effect as having no navigation, i.e., leaving your users lost and confused and rendering your site useless. Taking the time to create a well-designed, well thought-out navigation is worthwhile because good navigation is a critical component in convincing a user to come back to your site. After all, if the user feels they’ve done nothing but encounter obstacles and roadblocks while attempting to attain their goal, where is their motivation to return?

Hey! you protest. I’ve already clearly defined the Global and Local navigation and the taxonomy is spot on. What’s next? O.k., here are two other ideas that can be brought into play to assist the user in getting around your site.

You Are Here. It used to be a standard navigational guide to unlink and visually highlight the navigational element for a section when the user was on the main page for that section.  The majority of large sites, however, now use one global navigation template for ease in maintaining their code. And more often than not, most teams can’t or won’t take the time to build in multiple if/then statements to change the look of the navigational element based on context. But it’s so worth it. Highlighting and unlinking a global navigation item when the user’s on that page comes with two benefits: it gives the user the visual recognition of their present place, and prevents them from clicking a link that sends them to the page they’re already on.

Differentiate Your Links. Not all links are created equal. Some go to other pages, some expand areas on a page, some download documents, etc., etc. So if these links all behave differently, shouldn’t they be displayed differently as well? Handle off-site links by letting the user know they’re leaving your site (see the external  links section on any wikipedia page for an example). Or consider changing the cursor from a hand to a pointer when a link is no longer active (sometimes you don’t want a link to be active in the hover state, e.g., when the link is used to display a dropdown menu on mouseover and not to link to another page). Combining CSS with your creativity, itemize the various types of links you have on your site and come up with ways to differentiate their visual display to clue the user in to to the link's behavior *before* they click on it.

Navigation, in all of its forms, is key to giving the user a good experience. If they’re lost and confused, chances are you’ve lost them as a site visitor. Keep them happy, and they just might visit again and again and again.

Do you know your SiteKey?

SiteKey is a system some sites (notably banking sites) use to prevent customers from logging into fraudulent sites dummied up to look like the actual sites. During registration (or updating an account if it was created pre-SiteKey), the user is asked to select an image they would like to associate with their account. Thereafter, the SiteKey image is displayed when the user logs into the site, reassuring them that they’re logging into the actual site. In theory, displaying the image instills trust and confidence in the user.

The reality, according to a joint study conducted by Harvard and M.I.T., is that users tended to enter their password regardless of whether or not the image is displayed. Only a few refused to enter their password citing security concerns. Not good.

Now, keep in mind that the test was done in a controlled environment with the users being asked to conduct routine online banking activities. They may have felt secure in their surroundings (an official test, Harvard, M.I.T., etc.), and it may not have bothered them to find no image being displayed (if they even noticed). Plus, typing the url directly into the browser vs. clicking a link from an email generates different levels of security which may have caused them to go directly to the input boxes for login.

But perhaps the images (or lack thereof) were ignored for other reasons. For those of us who only rarely login to SiteKey sites, it’s next to impossible to remember the image that we’ve selected. Face it, I can barely remember my passwords. So even if I see an image, I have no level of assurance that the site is legitimate since my recollection of whether or not the proper image is being displayed is spotty at best.

However, there is one exception -- a site that allowed me to upload my own image and associate it with my account. Because I could use an image that is meaningful to me, the SiteKey implementation thereby became a much more effective tool in alerting me to the site's legitimacy. Amazing how things improve once you involve the user.

Why User Research Matters

What if you brought in users to test your application and the final result was one big collective yawn. It’s not that the product wasn’t usable -- oh, maybe some minor tweaks to the presentation layer could improve things, but overall all tasks were completed fairly well. No, it’s more that the users had no desire to use your product because, well, because quite frankly it didn’t answer their needs.  In short, the proposition was wrong from the very beginning.

To steal a quote from disambiguity: "If you’ve got a flaw in your thinking at the top of the chain, then no amount of surface usability is going to save your product."

I know it sounds fundamental, but the fact is that the value proposition you’re offering needs to solve real problems for real users. Concepts are great and brainstorming is fun, but if the user is not an integral part from the very beginning, they may decide they don’t want any part of the result.

The good news is that the value proposition can easily be validated by conducting user research early on in the project cycle. Talk to the people you’re designing for, understand their needs and check to see whether or not your ideas and concepts are on the same page with their goals.

Usability starts at the very beginning, with user research. For a minimal amount of time invested at the start of a project, you’ll save yourself a lot of wasted time wandering down the path of functionality that solves the wrong problems or even worse, is not even wanted by the users.

Ideas for User Research

User Research isn't limited to sitting behind a glass window, nervously chomping on M&Ms while glaring at the hapless user who’s attempting to navigate through your next killer app. There are different types of user research that can be incorporated throughout the lifecycle of a project, often at minimal costs to the company but with maximum results towards a more usable product.

User research methodologies generally fall into the two broad categories of Qualitative (why is something happening) and Quantitative (what is happening). With Qualitative research, you use a small sample size to discover new insights which can then be tested or proven. Quantitative research uses a large sample size to test or prove something, perhaps one of the insights you uncovered during your qualitative research or to determine the primary browsers you want to support.

Starting with Quantitative Research, here are some methods you should consider incorporating into your next project:

User Surveys uncover what the users say. You’ll get a large sample of responses on your users’ goals, behaviors and attitudes (assuming you have a well-designed survey of course). Surveys allow you to easily gather data on almost any topic and the results can then be ranked and assigned a priority for future design, scoping, etc..

Site Traffic Analysis tells you what your users do. An analytics tool's output tell you how your site is navigated, which pages are abandoned, which content performs well, which browsers you users are actually using, and so on. Your logs files will tell you some of this information as well, but slog through those files just once and you’ll soon realize the value of an analytics tool.

Information from these Quantitative research methods will tell you what is happening but not necessarily why it’s happening. For that, you’ll need to conduct some sort of Qualitative research, such as:

User Interviews let you learn about your users. Either from talking to a person face-to-face or over the phone, interviews yield detailed information about your users’ goals, behaviors and attitudes. They are usually better when conducted one on one rather than in a group because you can remain focused on that one individual and what they're saying. Keep in mind that loosely constructed conversations, rather than a formal script, allow for unexpected tangents that can lead to surprises and insights.

From Field Studies, you’ll gain context about where and how and when people actually use your software (or the competition) as you observe them in their daily routines. From this direct observation, you’ll also gain an understanding of your user’s attitudes and perceptions  which will help in designing the user experience.

Usability Testing is done to observe user behavior. It is different from a field study in that you’re not merely observing the users' actions, but you’re also directing their actions. It lets you watch how people  use your application to perform specific tasks and where they encounter obstacles, which features slowed them down, which elements were confusing, etc. Usability Testing yields a richer quality and quantity of information than a survey.

Installing Software? Nah, I have a Browser

Let me tell you about my day which, for most of you, will sound very familiar (the actions if not the details).

When I came home, I was glad to see that not only had my Netflix DVD arrived, my updating of my queue was successfully completed before this latest mailing was sent out.  Putting the movie aside momentarily, I popped online to pay a bill because I realized I had never received the paper bill which should have arrived by now. But no worries here because I figured there was an online option available, which there was, so I easily took care of that outstanding item.

I then jumped over to the Benjamin Moore site and, using their interactive tools, was able to see what my friend’s house rehab will look like with the colors she’s selected. It should end up looking very nice. Then, being the good daughter that I am, I sent my mom some flowers (to celebrate the warmer weather that will surely arrive one of these days!) before settling in and watching my movie.

So in one evening I received the correct product thanks to real-time data management, accessed an accounts payable system, an interactive color tool, and a purchasing system. The Web has become an integral part of our lives, evolving from a static, digital publishing medium into a series of interactive applications that we use on a daily basis.

What struck me about all of this, however, is that not once did I have to insert a disk and install software in order to take advantage of what’s out there. Now perhaps you don't consider what you’re viewing on the web as software, but consider this: moving forward, we’re seeing an increase in the availability of hosted apps such as Google’s docs and spreadsheets and Adobe’s soon to be released online version of Photoshop. Features that used to require loading software in order to access are available via a web browser. Makes you wonder if maybe that dvd tray *is* a cupholder after all!

User Task Flows Help Developers:

Work out the Workflow. Making changes after a product is released is much more costly, and sometimes not even feasible, than identifying issues up front and solving the problem before coding begins. Documenting the user task flows during the design phase allows team members to walk through the tasks as the user, identifying available actions and uncovering places where the sequence doesn’t match the user model. Decision points are identified and subtasks mapped out, giving the developer a visual of not only what the workflow needs to allow but how flexible it needs to be.

Model the Data. Creating task flows that diagram the end-to-end tasks throughout the system generates a picture of how the software will be used and how the user will interact with the data. Developers will begin to identify how and where the data is needed throughout the application. In turn, this will help them structure and organize the data in a manner that supports the users’ needs, rather than having the user modify their behavior in order to support a theoretical data model that doesn’t match their reality

Identify Patterns. Task flows gives the team a wall of visuals representing various tasks throughout an entire application. Scanning the flows allows them to quickly identify recurring patterns throughout an application. This, in turn, lets development begin to address creating reusable components or extending existing ones to allow the flexibility of reuse throughout the application

See the larger picture. Documentation binds large teams together. The end-to-end flow isn’t developed linearly by one developer or even by one team. Instead, it’s broken down into features with various teams coding the stories for that iteration. Creating end-to-end task flows is the perfect vehicle for letting a developer see the overall picture of how an entire feature works and, more importantly, how and where their piece fits into the whole. For developers it’s no longer one story in isolation, but rather a relationship of their one story with entry and exit points that define the sequence.

Web Accessibility is Good Business

Over the last few years, more and more basic services have been moving to the Web (banking, paying bills, canceling utilities, etc.) Whether the move is initiated as a cost-saving device or as a way to make the services more readily available, the fact is that moving every day "life administration" online means accessibility gains in importance.

Web accessibility is a broad topic but in essence it means your pages are accessible by people using a wide range of user-agent software and devices, in addition to the standard web browsers. The foundation for achieving accessibility is separating out the content and structure from the presentation and behavior of a page.

Use semantic markup to structure the document.

Semantic markup provides a framework for explicitly describing things. It is descriptive enough to allow machines to recognize it and make decisions about navigating a page. For example, the use of header tags <h1> allows users of screen readers to scan the headers on a page. Or a <strong> tag allows an oral user agent to apply a different voice for emphasis. An added benefit is that semantic markup still gives the content visual hierarchy even if the external style sheet fails to load.

Use CSS instead of presentational markup.

Style sheets define presentational characteristics. Presentational markup (e.g., <font>) does that as well, but it does not allow a user to adjust the presentation to suit their needs. When presentation is defined in a style sheet, it allows different users to override the author's styles with their own. This way, a visually impaired user can display a large text alternative by defining his or her own user style.

Ideally you want to use external style sheets so the presentation information for the site is held in one place and can be updated quickly.  In addition, external style sheets enable you to have consistency across pages and  implement global changes in just one file.

The Web Accessibility Initiative of the W3C, of course, has extensive guidelines and details on how to achieve web content accessibility. It's worth reviewing and implementing because after all, you want your site to reach the largest possible audience. Web accessibility increases the odds of doing just that

Ambient Signifiers

I recently came across Ross Howard’s essay on ambient signifiers, subtle design elements that give the user context.  They work at a more subconscious level than overt signifiers; yet, even without a conscious effort from the user, their constant presence affords an effective means of communication.

The author’s musings came from his experience with the Tokyo rail network.  Along with a station’s obvious and somewhat standard clues (signage, train colors, audio announcements, etc.), each station has its own chime melody. By remembering the chime for their final stop (which they’re exposed to while waiting for the train) along with the chime for the station before their final stop (which they can hear when the doors open), commuters can more or less ignore the passing landscape and still be cued into their surroundings. Ambient signifiers allow them to maintain a sense of where they are without having to actively seek it out.

Moving into the digital realm, consider when a browser changes the background color of the location field once the user is on a secure site. It’s a subtle change, but once the user associates it as an indicator of a secure site, a quick glance at the field will reinforce that they’re in the secure portion of a site.

The challenge is how to integrate this concept into your web design methodology. Overt signifiers, such as navigation, will always be necessary but perhaps we should also develop a vocabulary of ambient signifiers as reinforcement. A deepening of background colors to indicate sections a user visits often; a lightening of colors to indicate links to older items; differences in font size to show depth of a category, etc. Once you start thinking along these lines, you realize there are a number of ways to incorporate this concept into your design, aiding in the effective use of the site or web app.

Using Design Patterns

Design is a creative process, not a recipe. Good design is an iterative process where refinement is incorporated into each successive rendering. So how in the world does a pattern fit into a creatively, iterative process?

First off, let’s discuss what design patterns are. In essence, design patterns are a record of best practices derived to solve a particular problem. They are an abstract capture of a common structure, without dictating the concrete details. They give you a basis for where to start in order to come up with a solution. It is up to the designer to adapt the pattern to their particular context in order to solve the recurrent problem described by the pattern.

Actually, if you’ve been designing for a while you’ve probably already incorporated design patterns into your toolkit. Let’s say, for example, you’re designing a screen that requires a large amount of data to be presented in a very tiny space. Staring off into space, you remember a previous project and how you solved a similar problem. You adapt that solution to fit the context of the current application and viola! You’ve just used a design pattern.

Or you’re in a design meeting debating the merits of using breadcrumbs vs. a sequence map. Well, you’re actually debating two navigational design patterns – in this case, best practices that help with context. The chosen pattern solves the problem of giving users a sense of where they’re at in the application. How you implement the visual presentation of the pattern is up to you.

The recent books and articles on design patterns are, in effect, a formal codification of best practices that can aid in designing an elegant solution and also provide a common language for team discussions (sequence map is understood; 1-2-3 thingy at the top might not be). The more experience you have, the less likely you may be to consult design patterns. However, if you’re new to the field, encountering a problem for the first time, or wish to establish a common language for the team, they’re a good place to start.

And to help you get started, here’s a list of pattern repositories you might find interesting.

Onward to Web 3.0

In 2007, we’ll be seeing how Web 2.0 matures from a trendy buzzword into the realm of web standards. With the 2.0 technology and interaction, the idea of ‘community’ won’t be limited to a few oddball sites but will rather become an integral part of many mainstream sites.

You can already see this happening with the array of social bookmarking and media sharing links. What began as an oddity of icons encountered on the rare blog or two, is now becoming a standard one-click sharing device on such venerable sites as the New York Times. It’s a global community out there!

So with the maturing of Web 2.0 a given, the obvious question is what’s next? If I knew, trust me I’d be buying stock in the next killer app right now. But indications seem to be pointing towards a connection of data in a more intelligent manner, making it more relevant to the user.

Let’s face it, there’s a lot of data out there that in theory is searchable but not always connectable without spending a lot of time pouring over the results. And who has time for that. So we usually end up taking the first few results and running with that, but it doesn’t always work out.

So, what if we had a system that could rank and weigh people’s comments (which are fast becoming a standard feature thanks to Web 2.0) and, by cognitive deduction, find just the right result for that user. That is, our system would mine the data in the Web to detect relationships between the information that’s out there. Once established, it would be easier to extract and aggregate information tailored to fit the user.

Pie in the sky? Well the folks at the University of Washington don’t think so. Check out what they’re doing with their KnowItAll and Opine systems. Play around with their demos and think of how this would change your interaction with, say, a travel site if the system could provide a useful and meaningful result by distinguishing between concepts such "great" and "almost great".

"The system will know that spotless is better than clean," said Oren Etzioni, an artificial-intelligence researcher at the University of Washington who is a leader of the project. '"There is the growing realization that text on the Web is a tremendous resource."

And so in the next few years, we just might see this definition:

Web 3.0 – a web of connected data; i.e., moving from a web of connected documents/sites to a web of connected data.

Introducing the iPhone

oh yeah!

What's on my Bookshelf

Having recently been asked to review a book on CSS (which at first glance looks good but I'll go into details in a later post), it caused me to take a look at the crop of knowledge currently gracing my bookshelves. Hmmm, I thought. If I wanted to recommend two of those books, which two would I recommend? A nice little challenge. Deciding to keep the choices within the realm of the practical, rather than the theoretical, here's what I came up with.

First up is Designing Visual Interfaces, Communication Oriented Techniques by Kevin Mullet and Darrell Sano. The book begins with explaining the principles and elements of design and how they can be applied to user interface. There is no "one size fits all" solution but rather a discussion about techniques such as hierarchy, relationship, balance, etc., how they are used and why they're important in software design. The author also gets into module, programs and how structure, predictability and efficiency apply. Further chapters explain establishing modular units or using a grid layout. In other words, the book gives a great explanation of what design theory is and how it's the structure for well-designed user interfaces.

Next up, Designing from Both Sides of the Screen, How Designers and Engineers and Collaborate to Build Cooperative Technology, by Ellen Isaacs (interaction designer) and Alan Walendowski (software engineer). The book is divided into two parts: The Goal and The Process. The first part takes you through designing software with user centric design principles followed by the second section, which walks you through the process of building a software application illustrating what the authors did and, more importantly, why they did it. It's a good case study in creating technology that cooperates with people, shows how good designs help the user flow into their tasks instead of fighting them, and shows how design and engineering goals need not oppose each other. An good description of a theory and the application of same.

So there you have it, two recommendations off my bookshelf. The first promoting design principles and the second advocating user centric design. What's on your bookshelf?

The 'New' Look of Web 2.0

Filtering through the webisphere are various articles, blog entries, comments, etc., about the new look of Web 2.0 sites. Frequently cited are their clean design, strong use of color, utilization of font size to emphasize hierarchy, and so on. All true. These sites are great to look at and to use -- they're clean, easy to grasp and move the eye to specific points. But are the site designers doing anything new?

As the concept of the web has grown from a bunch of clickable links into a more sophisticated medium, standards from other professions have filtered into our world. The most obvious example is the integration of software practices such as mapping out site flows and writing well-formed code, which are (hopefully) practiced on even the most basic sites.

On the design side, after some trial and error, certain knowledge and practices from the physical world have successfully migrated into the digital world. Some have fallen aside (the brochureware sites of the early days come to mind). The 2.0 web sites receiving these plaudits are the result of the site designer's understanding of the elements and principles of design along with a good dose of typography and page layout.

Is this new? Not at all. However, what is new (or perhaps I should say more prevalent) is the application of the underlying principles of good design while exploring the creativity allowed by Web 2.0 technology. And when done well, it truly is a wonderful site to behold.

Hello!

I've recently come aboard the Pathfinder UXD team, so from time to time I'll be popping up on this blog where I'll give voice to random thoughts and ideas. I've been working in the web since the mid-90's starting with design, going through development and returning to the presentation layer as a champion for user-centric design. It's been fun witnessing the changes, growth and maturity in this medium, and I look forward to '07 and seeing what further developments Web 2.0 will bring.