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.

Share/Bookmark

I was starting up one of the Adobe apps the other day when this somewhat troublesome message was displayed:

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

Share/Bookmark

Wireframes are the bare-bones schematic of the presentation layer for an application or web site. They are the visual interpretation of the user and business needs for any given feature. At a basic level, they show the page layout and placement of various elements on the page. At a more detailed level, they identify user interactions and the expected behavior.

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

Share/Bookmark

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

Share/Bookmark

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.

Share/Bookmark

“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.

Share/Bookmark

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

Share/Bookmark

Heuristic reviews are a great tool for finding usability issues in any existing interface, from web-based to desktop. It’s a quick and relatively inexpensive way to uncover, document and prioritize usability problems.

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.

Share/Bookmark

‘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.

Share/Bookmark

At some point in their career, most everyone in software development has encountered the client who paints a very eloquent picture about their fantabulous idea that’s going to revolutionize the [insert industry vertical here]. However, as time goes on you realize the client’s staying at the 60,000 foot level, and while that may make for great conversation, it’s less than ideal for actually developing something. The trick, then, is to get them to climb down into the trenches and define the details before you have to start writing the code.

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.

Share/Bookmark