Topic Archive: Methodology

What is UxD?

Charles Field, Friday, August 3, 2007 @ 9:59 am

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

• Digg
• Reddit
• del.icio.us

Comments (1)

user experience design

Agile UXD

Alice Toth, Thursday, May 31, 2007 @ 1:33 pm

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.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

user experience design

What are Task Flows?

Alice Toth, Tuesday, March 6, 2007 @ 9:38 pm

Task flows are a tool to help us think through the design before a feature is actually developed. They allow us to interject the user into the flow of the application and determine if the conceptual model agrees with the user model.

The Information Architect (IA) is generally the team member taking the lead on diagramming the user narrative. With the business requirements and user modeling taken into consideration, the IA determines the tasks needed for a specific feature and maps out how the user will accomplish the task within the application. The resulting diagram shows a series of actions the user must do in order to begin and end the task, which can be anything from uploading catalog data to generating reports to assigning rights and permissions to user accounts.

Starting with the initial flow, which is a high level concept flow for that feature, the necessary steps to initiate and complete the task are detailed and mapped out into the flow. From there, various iterations of the original diagram are created and expanded upon as more requirements become known. The end result maps out the different levels of complexity for that task once subtasks and parallel flows are identified and designed.

By placing the user into the process at this stage, the Information Architect and the team can determine up front whether or not the final task flows will meet the business requirements along with any system requirements and still make sense to the end user.

Updated: Attached is an example of a task flow. Click on the image to view it full size. For this particular project, we were displaying new functionality at the UI layer and the diagram was created to visually show all the different ways a user could arrive at this new feature. Not all flows are this complex.

• Digg
• Reddit
• del.icio.us

Comments (6)

user experience design

Scenarios – Recording a Day in the Life

Bob Moll, Monday, June 26, 2006 @ 5:31 pm

One of the simplest and most effective scenarios you can create for an application user (someone who uses an application as part of his or her daily work) is the Day in the Life scenario. It is effective at capturing both tasks and context for using the application.

A series of interview questions can be used to extract the Day in the Life. Some possible questions are:

1. When do you arrive at work?
2. What is the first thing you do?
3. What kind of interruptions do you have?
4. Do you multitask, or finish one thing at a time?
5. How frequently do you use the application during the day?
6. What tasks does the application help you perform?
7. How critical to your job are these tasks?
8. How does the application help you do your job?
9. What does the application not help you with?
10. How much time do you spend during the day using the application?
11. What work is left unfinished at the end of the day?
12. When do you leave?

You can add to this list and modify it as needed. Once you finish your interview, transform the responses into a narrative for an effective Day in the Life scenario.

• Digg
• Reddit
• del.icio.us

Comments (1)

user experience design

The Buck Stops Here

Elyse Sanchez, Tuesday, June 20, 2006 @ 6:58 pm

Sometimes, it seems that the role of User Experience Architect is 90% management and 10% actual design.

And there's lots to manage:  user requirements, development schedules, business requirements, stakeholder expectations, schedules, timelines, and overall expectations. It's been frequently observed that the UXD is the liaison among all project participants. Truly, all roads to a given project lead through the focus of the user.

As a consequence, we mediators often become bargainers. I'm sure all of us have had to negotiate our design to conform with the myriad demands of the community of project stakeholders. We've given up the fight for a slick, appealing rich interaction for the sake of an overstressed timeline; have gone for the low-hanging, quick design hits in lieu of a more holistic and integrated design approach whose benefits may be more of an investment than an immediate showcase.

But some design recommendations are non-negotiable. Budget be spent, timelines be extended--we fail to justify our worth (and collaborate in our lack of ready acceptance) if we compromise on some critical practices.

Here are some of mine--I'm sure all of you can add to the list.

1. Coherent navigation:  An astronomical percentage rate of abandonment is associated with poor navigation on a website. This directly, and concretely, correlates to lost revenue on an e-commerce site, and only inversely impacts response rates on lead generation sites (i.e., improve the nav, improve the response rate). With applications, though, where users are often captive users, the erosion of usability is less direct, but nonetheless actual. It's almost a karma thing: what goes around (or fails to), comes around (or fails to).

2. Knee-jerk rebellion. As designers, we shouldn't adopt the personas of sulky fifteen-year-olds. Conventions endure for a reason. Especially on sites and apps. They cut through clutter and noise, and allow users to focus in on the heart of their tasks. Sure, we could all make our buttons into links, and links into drop-downs, and display diagonal navigation, but that's design that serves the designer--not the users. An electric light switch is dowdy and plain, but I can rely on what it will look like and what it will do, from sea to shining sea.

Of course, if I'm in Vienna or Tokyo or Rio, that switch is likely to look very different (although it serves the same function), which leads me to. . .

3. Xenophobia and the Ugly American Compulsion. Face it, we're good at thinking we set the standards for the world, and the statistics regarding internet usage bear out--at least for now--US influence and dominance. But that's changing--quickly. China will soon ascend as the country with the largest percentage of the population online. But it's not a simple case of "majority rules." Cultural differences are sometimes subtle, sometimes glaring, but always meaningful. In designing a website or application nowadays, it's best to assume global, rather than local, standards. This filters down to the smallest IA aspects, such as forms: most of the world doesn't conform to the US convention of <city>, <state>, <ZIP>.

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

To Customize or to Reuse

Sholom Sandalow, Thursday, May 25, 2006 @ 4:07 pm

Design patterns, Templates, Stock designs--whatever they're called, they present an opportunity and a challenge for designers.  All interface designers will run across this same question sooner or later.  When to customize and when to reuse a preexisting design. 
The answer to this question depends on what you consider to be the primary goal of the project.  Is it to build something unique and special--something that wows people because no one has seen it before?  Or is it to build an effective and on budget solution to a business problem? 
If it's the former, then as a designer you're primary goal is to create a work of art.  Go ahead and take the time to come up with something mind-boggling.  There's no limit to what can be done, and there's no reason to feel that a healthy dose of experimentation--both on the designer and the user's part--won't be beneficial.
However, if it is the later, you need to be aware that you are working under certain constraints.  Therefore the more you can reuse, the better.  There's plenty (and I mean plenty) of existing intelligence on interface design.  It's your responsibility to use that existing knowledge.  Incorporate it into your project.  Make use of the patterns that have been proven effective.  Make use of the processes that have been shown to be efficient.  In short, don't reinvent the wheel.  Use the collective knowledge that the web is offering you.
And you can start here:
Yahoo Design Patterns
HCI Patterns
User Interface Design Patterns

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

The Design of Non-Everyday Things

Bob Moll, Wednesday, April 12, 2006 @ 6:29 pm

Often as User Experience Architects, we are asked to bring the design process into new domains and complicated products that may have not been previously exposed to such a process. How can we, as professionals, achieve success in new and challenging environments? The answer is nothing new: Stick to the fundamentals. Don Norman listed them in his timeless classic, The Design of Everyday Things. As "Things" become more complex and more niche oriented, the principles still apply. Let's review a few of them.

First, keep the structure of tasks simple. A task may have many steps, and involve complicated data, but the structure can still be simple. Second, make things visible. If the user can't see it (or hear it or touch it), they probably can't use it. Third, design good error recovery mechanisms. The user should not be allowed to box themselves into a black hole they can't get out of. Finally, create and leverage standards. Think about the amazing complexities in road travel that are possible with a few simple standards of lights and signs.

Applying the fundamentals is the key to success in complex projects. Getting good with these timeless principles will make the complex manageable, and even fun.

• Digg
• Reddit
• del.icio.us

Comments (0)

user experience design

CHI2 Town Panel

Charles Field, Sunday, April 9, 2006 @ 12:56 pm

On April 5 I was invited by Brian Maggi to speak with Mark FelcanSmith [Allstate] Frank Gruger [Motorola] & Jason Kunesh [Orbitz], at the Depaul Center at 1 East Jackson. Frank & Brian recorded the event for a podcast - I think elaborate mixing & sweetening is occurring as you read this.

Pre-talk dinner at the Exchequer loosened tongues & elicited shared histories with several of us having journeyed to the West Coast and/or back, and this became one of the first topics of the panel in terms of the opportunities available both here & there. My comments centered on the differences in the kinds of business endeavors which predicated a much more conservative environment here.

I find far less frivolous business ventures here - no pets.com or flash in the pan outfits like Friendster. What Chicago has is brick & mortar businesses who tend to be in a discovery phase with User Experience Design & HCI concerns; this means that there is vast opportunity. The logical corollary is a requirement for significant education; the panel agreed that IT departments were very much the gatekeepers here, and tended to be suspicious of anyone from outside their world-view. Luckily for us, there are many supportive currents in the media, both tech & general, that are helping open these doors.

Brian moderated, goaded & cajoled with great skill, keeping the conversation flowing. The structure of the event was simple Q & A, but as the panelists had many years of experience between them, stories & opinions were anything but lacking.

Adam Steele - in a moment of brilliant academic scheduling - brought his DePaul class. There were a couple of questions regarding what to show in an interview - I think the first one was whether you should show a book. YES, definitely was the resounding answer.

But what kind of book? The answer from the panel was unanimous - all of us wanted to see evidence of process. I recall it was Mark FelcanSmith who said show how you got there. I reinforced his comment by saying that I would rather see the process steps of three examples - problem statements, concept, iterations, solutions, results - than 15 unconnected finished pieces.

If you actually make it to an interview, then it gives both of you something worthwhile to talk about. How you developed an idea leas to methodology discussions of how you approach the stages of a process & how you deal with collaborative environments. UXD or HCI work is a team event - particularly as a junior, you are not likely to be handed a problem and told to come back with a solution in two days.

There will be Business Analysts, Developers, Senior designers & Clients working together to solve what is usually a complex series of problems. Work needs to be produced in a way that allows for comment, technical realities or epiphanies or creative market approaches. So the ability to work in stages is crucial.

Many other questions were asked & answered - I will link in the podcast when it appears. Thanks to Brian & the other panelists for an enjoyable evening & freely sharing their stories.

• Digg
• Reddit
• del.icio.us

Comments (1)

user experience design