UXD - User eXperience Design

Busy. Busy. Busy.

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

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

iPhone and Air Travel

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

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

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

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

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

Technorati Tags: iPhone

Get in the Flow (Task Flow that is)

Call them what you like (task flows, work flows, process flows), flow diagrams are an important part of any software project. As a developer, you may be more familiar with sequence diagrams, a nifty way to visualize an exchange of messages between different processes and the order in which they occur.

Well another useful diagram is the end-to-end task flow. This handy dandy diagram shows all the steps necessary for a user to accomplish a task. Buy a pair of shoes? Select shoes, select size, add to cart, go through checkout process. Simple and easy.

And yet, what is it really telling you? Well, a flow diagram gives you an overview of the end-to-end process, the start to finish if you will. It lets you know what the user needs to do in order to start a task (select those really cool shoes) and what defines that the task is completed (display order confirmation). In between those two points are all the necessary steps to go from start to finish.

Initially, the in betweens are very high level (as evidenced by the above diagram). As more information becomes available, the flow is modified, added to, subtracted from and generally redrawn to show not only the user tasks, but also the system tasks (return error message, validate and continue), alternative routes (continue shopping, display upsell message) and decision points.

I've found flow diagrams to be very helpful because they let team members know how their stuff fits into the big picture. Let’s face it, on most projects the end-to-end flow is never developed lineally by one developer. Instead, it’s broken down into pieces and parts and assigned to various people. Seeing the end-to-end diagram up front gives you the overall picture of how an entire feature will play out and, more importantly, shows you how and where your piece fits into the whole. It'll get you thinking about potential points where code can be reused (sweet!) or better ways the data can be used at the presentation layer.

End-to-end diagrams let you see that what you're working on is no longer a lonely story in isolation, but rather something that’s part of a defined sequence that contains a beginning and middle and end. It ties what you're doing into the whole and brings a coherency to the process. This is especially valuable for large features that are spread out across teams and even iterations.

Technorati Tags: task flows, information architecture, diagrams

Personas and Football

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

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

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

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

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

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


Technorati Tags: personas, user experience, design

Powered by ScribeFire.

New is Cool

I passed by the Apple store this afternoon, and decided to check out the next generation of iPods.  I have an iPod mini.  It’s served me well for over two years now, although I am not, by any stretch of the imagination, a power user.  In fact I use it regularly for only one purpose—to get me through my workout.  Every so often I’ll take a road trip, and it comes with me then too, but not with much success, since I don’t have the necessary accoutrements to have it play through the car stereo.

When I first got the iPod—it was a gift—I was entranced by it.  I literally thought it was the most beautiful piece of technology in the world.  It was mainly the simplicity.  Smooth surface, unbroken by obtrusive buttons, or sharp edges.  I spent way too much time keeping it from acquiring the wear and tear that inevitably overcomes any new product. 

I was consequently disturbed by my initial reaction to the latest wizardry from Apple.  All I could think of was that I wanted one—that the new iPod Nano put my Mini to shame in the coolness department.  Now having time to think about my first strong reaction, I don’t rationally think that the Mini is objectively less hip/cool/sleek/ than the new Nano is.  In fact I think that if Apple had released them in the reverse order, with the model I now have coming out more recently, I would have felt that the Mini is aesthetically superior to the Nano.  Why is that?  What properties does a new product exhibit that makes it more irresistible than an older one?  How has Apple become so successful at making new seem so much better than not-so-new?

Apple and a few other companies (notably Adobe) have been outstanding at generating mass interest in the same product over and over again through minimal enhancements, but mainly by convincing us that newer is better.  I don’t know their strategies because I don’t attend their board meetings, but I do interact with their results.  It’s a tremendous advantage for such a large audience to believe that a certain product is ‘in’ simply because it says so.

Powered by ScribeFire.

Chaos and Order

The process of designing (guis/websites/apps what have you) can be very exciting, and ultimately, when a design goes well and achieves its purpose, it can be highly rewarding.  But it's also a challenge.  Every designer has their own set of struggles that they go through during the design process.

One of the things I struggle with most as a designer is the urge I have to make things consistent, or symmetrical.  I prefer order over chaos, I'll admit.  I constantly have to catch myself from spending too much physical and mental energy on removing what I see as chaos, and replacing it with structure, consistency, balance and symmetry.  It's not that these aren't worthy goals, but my experience is that sometimes those characteristics aren't the key, or even an important element on a particular interface screen or widget.  In fact, in many instances I have found that what I consider order is quite an undesirable solution, or at least, not what the doctor ordered.  
By instinct I look at my work through a designer’s lens.  It is a macro view.  I see the overall structure of the interface.  I slave over task flows and wireframes, structuring them and fine tuning them so they please my aesthetic and philosophical sensibilities.  I judge them by their adherence to my design rules-symmetry, balance, structure, consistency.  
But for the judges that matter, the users, the interface is simply a tool that they will use to accomplish a task (or set of tasks).  They will judge its success not by any theoretical characteristics, but by how well it allows them to accomplish those tasks.  They won’t look at the blue prints.  They’ll never get a look at the task flows generated in the design process, nor would they have any desire to.  
Internalizing this distinction--the difference between my view, and the user’s view--and embedding it into my design process is one of the challenges I face, and one of the determinants of a successful design.

Powered by ScribeFire.

Thinking like a designer isn't always good

When designing, I frequently find myself thinking like a designer.  I ask questions that a designer asks.  I attempt to find clever design solutions to issues I have uncovered while wearing my designer’s hat.  I rely on design principles to guide me through the process. 
Yet no matter how much experience I have designing, no matter how great a design I think I might have achieved, there will always be something missing if I don’t at some point stop thinking like a designer and start thinking like a user.
This is because if one is not thinking like a user, then no matter how well he or she thinks he has solved a problem, all design solutions are still just conjecture.  The designer has to step out of his designer shoes, where he has been using principals, and what he thinks is good judgment to solve problems, and simply be a user.  He must ask himself not weather the design works in some abstract sense, but weather he can easily do what he needs to do.  If he can answer that question in the affirmative then by definition the design works.  Of course it helps if one has a user base to test the design with, but that isn’t always an option.  And even when it is, it’s still best to incorporate user feedback as soon and as often as possible in the design process.  When the designer doubles as a user he accomplishes this quickly, frequently and relatively inexpensively.
Sometimes it’s hard to switch modes, so to speak—to go from designer to user on the fly.  For me the key principal is this:  to move into user mode, instead of asking myself questions that begin with ‘Would the user’, I begin questions to myself with ‘Can I’.  It’s also important to move quickly through interactions, and trust your first instinct as a user.  Your first moves (where you move your mouse, where you click) are generally what more typical of what a user would do, since you haven’t had time to consciously decide what to do (therefore using the knowledge you have as the designer). 

Design Doesn't Just Mean Color

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

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

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

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

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

Technorati Tags: SDLC, Application Design, Design Phase