UXD - User eXperience Design

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

Social Networking from Cradle to Grave

According to a pair of articles on BusinessWeek.com, the social networking site Facebook.com attracted 11.5 million individual visitors over the age of 35 in June, more than double the number a year before. The growth of this segment is remarkable, given that the site was not open to all until late September 2006, and the increasing “graying” of Facebook is predicted to change the site’s character and content.

 

What is UxD?

A couple of weeks ago a sales presentation was being prepared in our New York office; it was primarily focussed on the problem at hand, but the presenter wanted to include a single slide as a cue to talk about  User Experience Design [UxD]. He emailed me and a couple of the principles asking for a description in a single frame.

I wrote something, designed two slides because I could not shoehorn it into one, various documents were thrown into the air, then we were all consumed by other work as the train moved on.

Now I am rethinking it. UxD is a fairly complex set of activities to describe, and there is no shortage of areas claimed by related disciplines. All of them are occurring in an area of rapid market development that happens to be highly valued by the societies we are in. Which is a recipe to attract passionate debate driven by financial rewards.

So is there a good way to describe it, or state it's value to a potential client in a single powerpoint slide? Assuming that no fly-ins, starbursts or windowshade rolls may be used in place of meaning, we will start with those old standbys - words:
________________________________________

Concise version:
User Experience Designers create structures for understanding and manipulating information, designing consistent contexts which encourage cumulative learning. In doing so they raise the bar from "being able to do something" to "being able to do something easily".

Their solutions go beyond code to model the most efficient and pleasing conceptual space that can be created within the constraints of time, budget & resources.
________________________________________

Verbose version:
User Experience Designers are typically employed on applications or sites with large amounts of features, complexity or information.

They create structures for understanding and manipulating information or parameters, designing consistent contexts which encourage cumulative learning.

They raise the bar from "being able to do something" to "being able to do something easily". As a starting point they conduct research to find:
_Who are the users?
_What are their goals?
_In what context will they use the product?

Then they use any modeling technique available to propose solutions that go beyond code to model the most most efficient and pleasing conceptual space that can be created within the constraints of time, budget & resources.
________________________________________

And this is just a starting point for discussion, and the slide itself is TBD. The concise version is hardly meant to be all encompassing, but it focuses on Pathfinders particular business goals. These are concentrated in application work, either in or out of a browser, and our communications tend to be directed toward fairly tech savvy folks. Interested in your comments.

Charles