photo credit: Sinaasappeljuice

At Pathfinder, we do our best to help our clients experience the software through the eyes of the user. Defining a feature includes explaining who will be using it, what they need to accomplish, why they need to accomplish it and how they’ll actually do it.

We start with personas (who) — they define the user base and let us identify the primary users whose needs we should focus on, which in turn drives the feature list. Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software. Myrna is not so easily dismissed, especially once her needs and goals are identified.

We move onto user stories, all of which are written from the point of view of the personas:

As Accounting, Myrna needs to quickly extract time expended per project so she can calculate the actual costs.

Our user stories state both the user’s need (what) and business benefit (why) from meeting that need. The story is no longer some randomly floating idea; it’s now anchored to an identified user and given context within the scope of the business by specifically stating how the user and/or company can benefit from this feature.

From here we move onto acceptance criteria (how), i.e., defining how the user expects the feature to work. Since they’re written from the point of view of the user, they’re easy to understand and aid in experiencing the feature before it’s built:

Given that Myrna has clicked on Reports > Costing Report
   And that the costing report page has successfully displayed
When Myrna selects one or more projects
   And she specifies a date range
   And submits the request
Then the costing report will show the hours by project for each resource for the specified date range

Even without delving into the details (e.g., how does the user select one or more projects), you still have a pretty good idea of how someone will interact with this feature; i.e., you’ve established a foundation that interaction designers and information architects can now build on. Acceptance criteria, btw, are also great at uncovering any user story you might have missed, such as: does Myrna need to save this report after it’s generated?

Designing software with a user centric point of view begins with defining the Who (Personas), What (User Stories : User Needs), Why (User Stories : Business Benefits) and How (Acceptance Criteria) of feature stories. With this knowledge, we can then create a well-designed feature that we’re confident will meet the users’ needs.

Related posts:

1. It Starts with the User Story
2. Definition of a Feature (Given … When … Then)
3. The User Interface is the Root of All Evil

Ack! On the one hand, good for them for alerting me that an error had occurred. On the other hand, what's up with that message? I had no idea what I could do beyond clicking ok (and after reading the message I wasn't sure all was ok). A bit unnerving, but it did get me thinking about how applications deal with error messages.

The idea that non-technical users will be viewing error messages is one of those things that tends to be overlooked. You’re so focused on getting all the features up and working that dealing with errors on the presentation layer are often left out of both design and implementation.

Even if time is crunched on a project, however, here are three scenarios you should always cover in a user-friendly fashion:

Validation Errors

At a minimum, submitted forms should validate that all required fields have data and that certain data (such as email addresses) are properly formatted. My personal preference is to catch the obvious errors (e.g., empty fields) using client-side validation which gives the user instant feedback and allows them to correct their errors before actually submitting the form. Regardless of whether you’re using client or server side validation, however, you should still alert the user as to what went wrong — without using technical lingo — and highlight the fields containing the errors.

404 Errors

Design a useful “page not found” page. Make it as clever or funny as you like, but make sure you give the user alternative ways to find the page they were looking for so they don’t feel so helpless. This can be done by providing a site map, a search box or a list of top-level categories.

500 Errors

When a page blows up, unless you’re in a development environment you never want the user to see the stack trace. So, make sure that (a) there is a page in place to display when a 500 error occurs, (b) the app knows to display that page and (c) it gives useful feedback to the user.

In an ideal world, of course, errors never occur (ha!) but should they happen, your job is to let the user know what went wrong and provide guidance on the next steps. Time spent up front designing good error handling will alleviate user frustration down the line.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Oops! Our Bad.
2. Usability review: Amtrak.com checkout process
3. Stop, Reload, Error Loading Page 404: Converting Web 1.0 to 2.0

Why use them?

Wireframes are a great communication tool for all members of a project team. Instead of an abstract list of requirements or a verbal description of a concept, the visual nature of a wireframe allows everyone to see exactly what it is they’re discussing. They are usually black and white (sometimes with shades of gray) schematics because we want to get feedback on the page structure and behavior, not the visual design. However, wireframes created for mature applications can readily incorporate existing visual design since that language is already defined and shouldn’t divert focus from the reason we’re looking at wireframes.

Annotated Wireframe

Although a picture is worth a thousand words, adding annotations to a wireframe lets the viewer immediately know the expected user behavior of various elements on the page. While a more detailed explanation of the behavior is generally contained in the design specs, adding a shorter version here is extremely helpful.

Here's an example of what an annotated wireframe can look like:

Who uses them?

All team members. Because they are a visual artifact of what is proposed to be built, they are an easy and cost-effective way to get the stakeholders to sign-off on how their business requirements will be translated to software, before any code is written. They also give development a heads up on what the page will look like and how it’s expected to behave; which means they also let QA know what to expect once the feature is ready for testing.

While I sometimes have to educate clients new to software development on the benefits of wireframes, once they see them within the context of a project, they're sold on the benefits and understand their usefulness.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Wireframes: Much More Effective than Interpretive Dance
2. Developing Good Wireframes Ahead of Visual Design
3. Wireframes in Omnigraffle 5

photo credit: theD40kid

A few years ago, I worked on a team that was trying to move the business side away from the waterfall method into more of an agile approach so there wouldn’t be such a disconnect between design and development. Since there was no blueprint on how design could be done in an agile fashion, resistance was very high. One of the major sticking points, however, was in documenting requirements. The business side controlled the process which meant no one could see or review the requirements until they were released by the analyst. In a world view of us vs. them, collaboration was not very high on their list.

Collaboration, however, is high on the list for agile development. So, how to resolve this conundrum and begin to merge the two teams. The eventual solution was to use a wiki for documentation and to note when requirements were still in draft form. This process raised the comfort level of the analysts that they wouldn’t be unduly criticized before they’d finished writing, but still allowed for review and questions by others. It took a number of cycles before the analysts were comfortable with having their drafts visible by all, but eventually it happened.

The next hurdle to overcome was the format for the wiki pages. Luckily, the analysts were accustomed to using a Word template and, therefore, were in agreement that a standard template needed to be used. However, a one-to-one translation of the Word template to the wiki just did not work. For example, was a title page really necessary (yes, they actually reproduced this as a wiki page). No? gone. What about a notation of who revised the document when? The wiki tracked changes so explicitly stating this was nothing more than busy work. Table of contents? No longer needed as the content could quickly be scanned since requirements were now for an iteration and not a release. And so on and so forth.

What works in a paper world may not translate well into a collaborative, digital world. However, changing a process doesn’t happen overnight. Your best approach is to take an iterative approach: ask the developers what they read and what they ignore on the current format — then ask the same of the business stakeholders and anyone else on the requirements reading list. Ask your team members what their workflow is through the parts they actually read, i.e., what they focus on first and so on. Once you get a better understanding of the essential components, take the original template, pare back to the necessities and organize in a manner that best suits your users. After all, just enough documentation works for design as well as development.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Integrating Design and Agile Development
2. Design Thinking
3. Agile Development, Documentation and Bringing Projects back from the Dead

photo credit: stuartpilbrow

Your project is going along fine. After the initial bumps, the team has reached max velocity and is running through story points like there’s no tomorrow. The demos are a success, with the client loving how everything is coming together. Communication between the team members and the client is working well, with enough give and take that all sides feel like they have a genuine stake in the project. In fact, the goal posts are in sight and we’re already scheduling a release plan. And then the client asks for one more feature. Not a tweak of something already built, but a new feature that has to seamlessly incorporate into the application and not look like a last minute add-on.

The initial response? The team to comes to a screeching halt and devolves into something resembling the stages of grief.

1. Denial: “But it’s perfect as it is.”
2. Anger: “What!?!?!? We worked so hard to make it work and now they want to junk it up?”
3. Bargaining: “Better to release it as is and then develop new features”
4. Depression: “Stupid project”

Welcome to feature fatigue. Many weeks have gone into creating this software and no one is happy about adding more stuff. I've been through this more than once and it really does seem to be the default reaction. Why? I'm not sure -- too many iterations spent solving problems? Relief that end is in sight only to have it cruelly taken away? Who knows. At some point in your career, you’ll find yourself in this situation and the question is, how to deal with it.

Hopefully, the new request will first have been filtered through the project manager rather than dropped on the team during a demo, as the first path tends to minimize collateral damage. In any event, regardless of how the request is introduced to the team the PM takes on the initial push-back, explains to the client the pros and cons of inserting a new feature at this late date and the effect it’ll have on the release date and/or other areas of the application (not to mention the cost).

It also doesn’t hurt to ask the client for a explanation of their business reason for this latest addition. This isn’t done to make the process difficult (well, not always), but rather to try and figure out if there’s something already built that will meet the business needs. And again, always good to point out the costs of adding in a new feature, especially if existing functionality will meet most or all of the business needs. These discussions will help to determine if this new feature is a “must have” or “nice to have”. It might be that building the new feature is unavoidable, but getting as much background information as possible helps everyone on the team make the best decision.

Once all this information is gathered and presented, the team can then move onto the final stage:

5. Acceptance: “So fine, what’s the new schedule”

followed by, team beers.

Related posts:

1. User Centric Design – the Who, What, Why and How of a Feature
2. Definition of a Feature (Given … When … Then)
3. What is Role of an IA?

“IE6 is the new Netscape 4. The hacks needed to support IE6 are increasingly viewed as excess freight. Like Netscape 4 in 2000, IE6 is perceived to be holding back the web.”

~ Jeff Zeldman, standards guru

Anyone who has worked with developing the presentation layer for web apps has become quite adept at creating workarounds in JS and CSS to try and give the user the same experience in IE6 that they’d have if they used an up-to-date browser. However, because of IE6's non-compliance with W3C Standards, a ridiculous amount of extra work (i.e., hacks) is needed in order to get the page to render correctly in this most outdated of browsers. And, as Dietrich mentioned in a previous post, the problem is that these deviations from the standard end up becoming the standard and increase the amount of time required to write and maintain code.

Unfortunately, this ancient browser is still in use by a non-negligible amount of people (somewhere between 10 to 20% worldwide) who either can’t or won’t upgrade. Not all of this is their fault; people in corporate or government settings are at the mercy of their IT department (who may not want to support a non-IE browser) and their company’s budget (no compelling business reason to eliminate the company-wide Windows 2000 machines that can’t run IE7 or 8).

Ideally, Microsoft should drop support for IE6. Short of that earth shattering announcement, however, some high-profile companies have taken it upon themselves to no longer support IE6 or to support it at a lesser level:

• Facebook tells their IE6 users to upgrade in order to get a better experience.
• Google also gives an inferior experience to IE6 users, warning that some features of their products will not run in that browser.
• 37Signals no longer supports IE6 for their products
• At WordPress, Shockingly Big IE6 Warning is a plugin that shows a warning message alerting the user why it is bad to use IE6, the security risk and the bad compatibility of Web Standards.
• Finn.no, a well-trafficked eBay-like site in Norway, posted a warning on its web page for visitors running IE 6 urging them to ditch IE 6 and upgrade to Internet Explorer 7.
• .net magazine out of the UK has a bring down IE6 campaign along with the practical suggestion of "Ensure sites work in IE6, but don't waste a lot of time fixing non-critical issues."

Internet Explorer 6 was released in August 2001. Let's give it a rest already.

Related posts:

1. Don’t be lazy, download a good browser
2. Hacking the :first-child pseudo-class into IE6 with jQuery and CSS
3. IE6: The zombie browser

photo credit: great_sea

Gauging a client’s wants and needs is as much an art as it is a science. Oh sure, establishing the requirements and needed features and potential limitations (hello legacy system) is pretty much a straightforward scenario. It’s when we get into the layout and behavior of the application that negotiating the waters can begin to get a little tricky. Bump it to the redesign of an existing application that users are accustomed to, and the trickiness factor is raised exponentially.

I’ve been lucky with Pathfinder in that my last couple of projects have been to design and develop new software. The clients come in with an idea for a better mousetrap and we build it. They’re excited, we’re excited and we get to build something shiny and new that gives the client a good experience and helps build their business. A win-win in my book.

Not all projects have such a glorious life. In a previous job, I was part of a team that was tasked with porting a legacy system over to a new framework. Naturally, there were the usual levels of complexity all projects of this type always seem to encounter. However, the most difficult obstacle to overcome was the inability of the decision maker to see anything beyond the existing user interface.

Initially we were excited about the project. After all, we had the opportunity to create a better experience for the user, not only through reconfiguration of the workflow but also in applying nifty behaviors to widgets that would save the user time and create something more in line with how they actually worked. And each time, we continually ran into the same refrain when talking to the stakeholder: but it looks different and the old way works fine. Actually, it didn’t work fine but they were accustomed to using the existing application and weren’t open to hearing otherwise. After a month of this, team motivation dropped like a rock. Three years and however many dollars later, the product launched but wasn’t usable and everyone hated it. Epic fail.

So what to do when the client (internal or otherwise) keeps muttering “just mow the grass”* even when you’re charged with overhauling the entire landscape. While coherently explaining your concepts and views is a good start, providing tangible examples of a similar implementation of your ideas is much more successful. After all, only having a verbal description of how something works is akin to shadows on a cave — very open to interpretation. Ah, but give them something they can see and touch and interact with and now you’re all at the same starting point to begin discussing the possibilities.

If no real-world examples are available, create a quick prototype to explain your idea and show how it will behave. A prototype can be anything from a series of sketched wireframes to a hi-fi page mockup in Photoshop to an HTML page stubbed out in order to show interaction. What you use depends on the situation, audience and time. Something that needs to be presented to the money people may require a bit more polish. Something that can be presented to your key supporter could be as simple as a whiteboard sketch.

The important element is that the prototype explains your idea in such a way that your audience can quickly grasp your essential ideas and comprehend how your “radical” change will actually work within their product and still support their goals. And they, in turn, can tell two people and so on and so on ….

Overcoming the myopic view of “more mowing, less landscaping” takes a bit of effort and persistence and additional work on your part. And, as we can all certainly testify, there are some folks who either can’t or won’t be open to new ideas. However, using visual examples to support and explain your ideas goes a long way towards building a consensus for trying something new. After a couple of these sessions and wins, the client’s comfort factor is increased while initial resistance is decreased, and the overall effort needed to move towards the new is greatly reduced.

* I wish I could take credit for that phrase, which perfectly describes the situation, but this gem is courtesy of John McCaffrey

Related posts:

1. Thinking about starting a SaaS or eCommerce business?
2. Visual Heuristics
3. What should our software do?

From usability.gov:

The goal of heuristic evaluation is to find usability problems early in the design of a Web site so that improvements can be made as part of the iterative design process … The result of this analysis is a list of potential usability issues or problems.

While I use heuristic reviews and find the results to be very helpful, I've never been too thrilled with the final documentation. Even when formatted nicely, they’re nothing more than a laundry list with a bunch of words and numbers and no hints or ideas on how that information can be grouped together and translated over to an application. Quite frankly, after the second page my eyes do tend to glaze over. And if my eyes glaze over, I can't even imaging how it affects the client. So I was challenged to come up with something better.

My co-worker, John McCaffrey, wanted to give his client some ideas on how to improve their site -- a heuristic review but with a sort-of Cliffs Notes component that could highlight the value of the review but not induce eye fatigue. He was also looking for something more visual to grab the interest of the client and keep them there long enough to start looking at the data. He mentioned that he really likes our annotated wireframes and an idea was born. Create a mashup of annotated wireframes and heuristic evaluation.

Our clients love annotated wireframes. Our developers love them as well. And what’s not to love? A quick glance lets you see the proposed solution and the page notes describe the interaction details. With combining the two documents into one (wireframe + review), the resulting graphic identifies the areas on the screens that the review data highlighted. The result? a visual heuristics.

Here's what I did: For the major screens, I created a page and highlighted some of the issues uncovered in the review that were pertinent to that screen. I added the relevant heuristic data points along the side, and referenced a marker on the page that related to a particular point. At a glance, the client can see the relationship between what the review uncovered and where it shows up in their application.

Because we design software, I then took the additional step of creating a mockup of a proposed solution. This view shows how that same screen could be revised to solve the problems highlighted on the previous page. It's not adding any new features, but rather taking the heuristic review and showing the client some suggestions on how the gathered data could be implemented. The client can easily compare the “before” and “after” shots, draw their own conclusions (do we need it or not) and better evaluate the implementation effort vs. business payoff.

Or, as John put it:

Brilliant!!!! It has such a tangible feeling, and it makes it easy for [the client] to say "Yes, I want that. Give me that right now!", whereas all the words that we had spewn out in our other document, while trying to highlight some of the same areas, just didn't have the same punch. Yay visual communication!

Yay visual communciation indeed.

Related posts:

1. Developing Good Wireframes Ahead of Visual Design
2. Exactly What are Wireframes?
3. The Hand-Off Between Information Architecture and Visual Design

'Fixin' the Start Line!' by UHLMAN

Companies (and people) new to software development tend to think that projects start with development, as in writing the actual code, as in here’s my idea … when can I see it and btw, why am I paying you for time that you’re not coding. Most are not aware of the upfront work needed to get to the point of coding or, perhaps, even the value of it. After all, they gave you the idea so let’s see less talk and more coding.

What is some of that necessary work that’ll drive us towards development? The upfront work definitely includes requirements — the details that allow us to start writing the code. But even before the requirements are started, long before diving into the wireframes and user modeling, features list or user stories, projects need to begin with a business problem and a blue-sky idea on how to solve that problem. In short, the product concept.

Our business problem is X
In order to solve X, we need something that’ll let us do A, B and possibly C.

The essential element, then, of being able to start the requirements — the very first thing that kicks off a project — is to state the business problem. What is the problem that your team needs to solve.

Business Problem: We’re a high-end print shop but are losing a potential source of revenue by not allowing high-end printing via the web

If you can’t articulate the problem, how can you define a solution.

Product Concept: Develop web-based app that’ll allow graphic design community to upload and print production-ready files

All features and functionality will stem from and support the concept, which makes it a useful tool to assist in defining and containing scope, as in: does a proposed feature support the concept? It’s also a good touchpoint to see how solid the business vision actually is. If further discussions and requirements gathering changes the concept a multitude of times, anyone trying to estimate a budget or propose a timeline will see potential issues and can manage expectations accordingly. And if after all of this the concept is tested and still valid, the final result has been stated and regardless of whether the project is 6 weeks or 6 months, the project team now knows the end goal.

A product concept addresses the business problem, highlights the potential user base and proposes a high-level solution. Its importance cannot be overstated since it is the overarching idea of your software and defines the entire purpose of the product. Try it on your next project and see if it helps to smooth out some of the inevitable bumps of all software projects.

Related posts:

1. Thinking about starting a SaaS or eCommerce business?
2. You’re at the Software Development Finish Line! …. or are you?
3. We Don’t Need No Stinkin’ Requirements

At Pathfinder, we’ve been involving clients in creating business-driven scenarios to define a feature, i.e., what does ‘create accounts’ really mean. These scenarios walk through the different tasks of a feature and identify the expected behavior and outcome based on the user’s actions. Although they follow a specific format (context, events and outcomes), they are written in plain English that can be understood by all team members.

Given that something has already happened (e.g., user logged in) [context]
When the user does something (e.g., clicks on a button) [event]
Then this is what should happen [outcome]

Very straightforward. Very understandable. And once written, the client must review and sign-off on the scenarios before we begin to code.

The benefit of this process is that we’re not asking the client to do the impossible (write the nitty gritty details); we’ll take the first pass at bringing the 60,000 foot idea down to the nitty gritty. But, we are asking that the client read the scenarios and approve them as the definition for the feature ... or get back to us with improvements/additions and then approve the scenarios. Once approved, though, the scope of the feature is now defined and understood by both the business stakeholder and the development team.

Because writing scenarios is an iterative process and one that must involve the client directly, it does add a bit of up-front time to a project. However, the cost is worth it because the project’s features are fully defined and agreed-upon prior to coding, thereby reducing ambiguity to the developers and allowing the project manager to better manage scope creep. Plus, we now have our acceptance tests for what defines the feature as complete.

Even better, though, is that we’ve found involving the client in creating the details of a feature definition reduces, if not eliminates, the “oh that’s not what I was thinking of” comments come demo time.

Related posts:

1. Scenarios in Product and Project Management
2. It Starts with the User Story
3. User Centric Design – the Who, What, Why and How of a Feature

Some teams combine all the lists into one main Feature List, assign a priority and tackle them one by one until either (a) all the items are completed or (b) the CEO decrees the product must be launched. On small projects with a limited set of functionality this may not be a bad approach since the overall Feature List will never be ungainly. The downside is that what you produce may not be what the user necessarily wants to use.

A better approach is to come at the problem from the user’s point of view, namely: What is it that the user wants to do or needs to do with the software — the goals. And, how will they accomplish it — the activities. Once you've figured this part out, you'll then have a better starting point to not only come up with a list of features but also to justify the necessity of those features.

For example, we recently worked with the client to develop the user model for their new software, which will be a web-based version of an existing application. Since they knew their existing user base, we ran through an exercise to confirm the user groups (a.k.a. personas) and their goals and then identified the activities they needed to reach those goals. For our Claims Specialist, the primary goal is to manage individual claims for her company with a secondary goal to report specific data from those claims. The various activities she’ll do to achieve this goal are:

• create claims
• edit claim
• manage supporting documentation
• create alerts
• create diary events
• run reports

From this list of activities, we can now create a list of features that are actually needed by the end-users. But we’re not ignoring the other folks in the company (more formally known as stakeholders). The features requested by marketing and others will be reviewed and filtered through the personas to determine if it’s something that they need in the software.

Ideally features aren't added to software unless they’ll actually be used by an end-user; the real world is rarely ideal, though, which is why creating feature lists can sometimes be an art, rather than a science. However, coming at the project from the point of view of the user gives you a touchpoint by which you can measure the validity of adding (or removing) features.

Related posts:

1. User Centric Design – the Who, What, Why and How of a Feature
2. Software Development and the Construction Analogy
3. Software Development: Importance Doesn’t Always Equal Effort

So pervasive has design thinking become in the last five years that Stanford University has created an elective program it calls d.school — more formally known as the Hasso Plattner Institute of Design — that has proved wildly popular with budding entrepreneurs from all corners of the campus.

It is a time in the spotlight for a process that historically has been relegated to the end of the business planning line.

Those of us involved in design already know that design thinking is one of several tools we use to help our clients stay competitive. Nonetheless, it’s nice to see major publications picking up on not only what design thinking is, but the importance of joining it with business thinking. Read the full article for a review of how this partnership works to create new solutions.

Related posts:

1. Thinking about starting a SaaS or eCommerce business?
2. Design Documentation
3. Thinking like a designer isn’t always good

At the IDEA 2008 preconference workshop, Dave Bishop and Paul Gould from MAYA showed us another way to prioritize project tasks: a bullseye diagram. It’s still a ranking system, but done visually rather than numerically. The team first lists out all the project tasks. These are then placed in the bullseye based on where they fall in rank; the critical items are in the center and the less important items moving towards the outer rings. If this is done on a whiteboard with the tasks on Post-it-Notes, then information can be quickly be moved around in relation to new tasks that are added to the bullseye.

Once the tasks are prioritized and in the bullseye, you can organize, arrange and add structure. You can start to see relationships, which may indicate a different priority. You can start to see categories, which may affect iteration planning. You can begin to add structure. The outcome of this exercise is an easily understood diagram showing the project’s priorities. For teams that aren’t comfortable assigning a number to a task, this is a good alternative to try.

Related posts:

1. Use Case Diagrams
2. Use a Task Flow to Show “How do I ___?”
3. What are Task Flows?

• Why diagram? We diagram in order to depict the information space in such a manner that allows us to visually validate to the client that we understand their domain. So often as consultants, we’re thrown in to domains where we have no or very little prior knowledge and minimal time to come up to speed at the level we need to be at in order to understand the context of the problem. Diagrams are one artifact that we use to organize the information space and document the users’ mental model. They are an essential element in verifying that your direction and understanding are correct.
• Future proofing. Don’t just design for the here and now; don’t design a solution that locks you into one way of thinking; don’t create a solution that can easily be broken by another idea. As solution designers, we need to look at the larger picture and how the various pieces can fit into the whole, rather than at just one feature or one path. We need to allow for evolution so the solution can accommodate growth and expansion without extensive redesign. All of these are concepts we’ve heard before; but it's already good to get the reminder and hear them again.
• UCD - user centered design focuses specifically on making systems usable to people. It tames complexity. Having the user integrated into the design process brings a focus around which you can organize the solution and design a usable interface. The direct benefits are increased productivity, reduction in support costs, improved user satisfaction, etc. The usual suspects, but nonetheless important to bring up with your clients when you remind them why UCD is relevant.

For the remainder of the session, MAYA reviewed some diagrams they use in their IA practice, including some I hadn't seen before. I’ll have more on that later.

Related posts:

1. Bullseye Diagram
2. Use Case Diagrams
3. Use a Task Flow to Show “How do I ___?”

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.

Related posts:

1. Get in the Flow (Task Flow that is)
2. What are Task Flows?
3. User Task Flows Help Developers:

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.

Related posts:

1. More Articles Needed on How to Design Ajax Apps, not Just How to Program Them
2. Use Case Diagrams
3. Writemaps: A web based site map generating tool

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.

Related posts:

1. Use a Task Flow to Show “How do I ___?”
2. Site Maps — Still Needed for Web Apps?
3. What are Task Flows?

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.

Related posts:

1. Definition of a Feature (Given … When … Then)
2. User Centric Design – the Who, What, Why and How of a Feature
3. What makes a good requirement document for an agile project

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

Related posts:

1. DUX2007 – Simplicity
2. DUX2007 – Data Visualization
3. Agile Business, Microsoft and the Threat of Cloud Computing

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

Related posts:

1. Nice List of Data Visualization Tools
2. DUX2007 – Simplicity
3. DUX2007 – Ubiquitous Computing