Despite my belief, I continue to take on projects where the teams are rah-rah Agile, usually Scrum flavored Agile. So, why do I do that? For a few reasons, but I can assure you that none of them involve masochism. That’s just not my playground.

1. Unless you’re working in an agency, you really can’t escape Agile.
   Pretty much everyone developing software these days has moved their dev processes over to some kind of Agile. More often than not, it seems to be Agile-fall (which, if we want to be pedantic about it, isn’t really Agile at all). So, if you’re the sort of UX-er who finds agency life boring, or you just really love solving big human problems with technology, it’s time to accept that Agile is just going to be part of your life…if you want to keep working.
2. So many projects are a mess because they have no idea how to incorporate user experience practices into the mix.
   My love of solving big, hairy problems doesn’t stop with technology. I love solving  process problems, as well. So, when I see a team in need of some process unfucking, I’m all over it. I just can’t help myself. At the end of the day, I want to see project teams as happy as the user communities that they’re trying to help.
3. When expectations are properly managed, Agile gives designers the freedom to be wrong…a lot.
   In more traditional (old skool? waterfall?) software design processes, designers often feel pressure to “get it right” before they show anyone anything. That’s because there’s generally very little time built into schedules to fix anything that you’ve screwed up. Dev folks, if you’ve ever wondered why the designers you work with seem uptight, arrogant, or secretive…that’s why. They’re used to having to be heroes and delivering the good shit on their first try. Agile encourages making decisions quickly and seeing if they work. That means that we have plenty of opportunity to experiment, and to correct our failed experiments.

In case you hadn’t guessed yet, I’ve tackled yet another big project that’s firmly entrenched in Agile. And I have, as usual, many many many things I want to say about it — not all of them pissy. Assuming I manage to save some energy for writing, over the coming weeks I may be spewing a lot of random thoughts of Agile here.

(For anyone who’s wondering about my decision to end my time in Agencylandia…that’s a whole ‘nother story. But, look above and you’ll get a clue why I’ve decided that world isn’t for me.)

Anyway, something I’ve learned about myself recently:

Nothing makes me drop f-bombs like shitty design.

I’m sure there are people who know me who could have told you that about me, but I never realized it was such a trigger until recently. And by recently, I mean about ten minutes ago.

So what sparked my moment of self-realization? A combination of two things, actually.

First, a heuristic analysis I’m hip-deep in at work. It’s bad, folks. Really, really bad–broken interface metaphors, disappearing menus, vague messaging, specialized terminology, inconsistent visual treatments. You name the rule, I can pretty readily point you to a place where this dev team has broken it. (It’s in fact bad enough that it’s almost inspired another rant about Agile…which is something I haven’t done in quite awhile.)

And second, Facebook’s newest design. This sparked such ire in me that I proceeded to rant about it on Facebook. Littering the landscape with f-bombs and other colorful language. Why does my potty mouth stand out in this instance as notable to me? Because I’m friends with my mother, various relatives, and some teachers from as far back as fourth grade on Facebook. As such, that’s generally not a venue where I let the “fuck” flag fly.

So, congratulations Facebook. You’ve released such a shitty design that you made me cuss in front of my mother. I’m hope you’re fucking proud of yourselves. Fucking idiots.

My personal winner for Most Ridiculous Product of the Year for 2010 is…

Starbucks VIA Ready Brewer...a brewer for your instant fucking coffee. Brilliantly stupid.

It’s instant fucking coffee, you stupid fucks. Why the hell does anyone need an appliance for that? Seriously. And to have the nerve to call it a “brewer”? That’s only something that the money grubbing whores of Starbucks would try to have the balls to do.

I’d like to think that people aren’t as dumb as marketers assume they are. Maybe for X-mas this year, Santa will restore my faith in my fellow humans and make sure not to put this piece of ri-cock-ulousness under anyone’s tree.

My wild hair was around using video to communicate interaction, and doing it on the cheap. Meaning: I didn’t want to have to go buy anything to try to make my little experimental dream a reality. So, running through a quick inventory of tools at my disposal, I settled on trying a combination of Visio and iMovie (I know, I’m mixing computing platforms like a crazy person) to see if I could rough something out.

(You’re probably wondering why Visio. Two reasons: 1) I <3 Visio. And 2) most of my work products were created in Visio, so I wouldn’t have to spend time creating something new, I could leverage existing artifacts for my experiment. The point after all was to do something for no cost…and time is money, my friends.)

So, I grabbed some past project work, dumbed down the UI a bit, got rid of the branding elements, and began my first foray into anything resembling motion work since the last time I fired up Macromedia Director in 1999. The result, while rough, is promising enough for me to want to spend some time experimenting and refining enough to throw this into my personal UX toolbox.

You can watch the video below. I’ll warn you up front that it’s a little jumpy, a little too fast in places, and the text can be hard to read. But I’m ok with that for a first effort that I didn’t spend much time fussing over.

http://www.youtube.com/watch?v=GNhLyUdCkoU

Well, first off, it’s my work blog–the place where I yammer, rant, and occasionally pontificate on all things UX. Be warned, I have a mouth on me. You will undoubtedly run across some language here. If you’re easily offended, I ain’t the UX gal for you.

I hope it will also become the home of a little project I’ve got brewing in the back of my head. I’ll be testing out that concept soon, and with any luck, the UX Clinic will be throwing open the doors to patients in need in the coming weeks. But more on that after it’s had a chance to percolate in my brain a bit more.

All of the content that’s here now used to live elsewhere. As a consequence, you’ll probably see some strange formatting and encounter some broken links. For that, I offer my sincerest apologies, but really…there’s only so many hours in a day, and a girl can’t spend all of them in front of her laptop (even if she really, really wants to). I’ll be cleaning things up as I have time. Your patience is very much appreciated. (See what I did there? I’m not asking for your patience, I’m just expecting it. I’m so demanding…)

Before jumping into this post, I’ll say that I’ve now been involved in about seven projects that have attempted to employ an Agile development methodology. And I’ll also say that most of them have not been successful. These were projects with different groups, at several different companies, with different goals and different user audiences. So, yes, I have watched Agile fail time after time, in many contexts, and that certainly colors my views on it as a way to approach product design and development. (Hint: It’s probably just dandy for development, but it friggin’ blows for design.)

Recently, I was asked a question: Are Agile and IA at all compatible?

My answer:
Agile and IA are not really compatible, no. But that shouldn’t be surprising since Agile is a development methodology, not a design methodology. IA can be more compatible with Agile when you’re talking about software or applications. But when dealing with web sites, particularly sites that are mostly about content or marketing, they don’t really fit well together at all.

It can be made to work a little more easily when you’re adding onto an existing product, but if you’re starting from the ground up you can’t necessarily just build tiny pieces of something and hope you’ll be able to find a way to string them all together in a cohesive way later. You need some notion of what the greater picture is going to be, so you know what direction to shape things. That’s typically what an IA needs to be concerned with, but Agile is fundamentally opposed to that.

For it to have a hope of working at all, IA has to get in front in the Agile method. IA has to start first. You can’t fire the gun on your first sprint and expect IA or design to take off at the same time as dev. What ends up happening in that case is that the developers sit around waiting for IA and/or design to deliver something they can start working on.

Either you have to put IA (and design, to some extent) on its own track and start them well ahead of development, or you have to start your sprints with only IA activities and bring development on in later sprints. (Note: You can somewhat compensate for design lag by having a combo UI designer/developer, but finding a good one of those is *much* easier said than done. The same is not true for IA, because that’s a much more “big picture” discipline.)

We’re all very aware of my tendency for using, um, colorful analogies and my lack of shyness in littering the landscape around me with f-bombs. In the spirit of that, I offer you the first in what should be (at the very least) an interesting set of presentations showcasing my opinions on what’s wrong with how most people address (or don’t address) user experience.

“Think about it…does Starbucks really need to be worried about their website?”

The author went on to answer their own question with a big fat no, postulating that for a large corporation like Starbucks the website is really just “a bonus for a large existing customer base.”

First off, I’m not even sure what that’s supposed to mean. A bonus? What kind of bonus is a web site? A web site is a tool—marketing, transactional, or informational. Those things aren’t “bonus” items, they’re essentials.

Now, will a crappy web site prevent people from going to a store and buying their morning latte? Probably not. But, will a crappy web site prevent people from learning about why they might want to make Starbucks their morning latte of choice? Absolutely. Will it hinder the ability of Starbucks to spread their brand and offer their customers more ways to experience the company beyond just that morning latte? You bet your ass it will. Will it prevent Starbucks from adequately serving their existing customer base? Fuck yeah.

I’m not saying that small businesses shouldn’t be concerned about their web presence. They absolutely should. But large companies have to be (and in many cases are) just as concerned over their corporate web presence.

So why did this make me want to hit things? Because, I can’t even imagine how out of touch with the realities of digital marketing someone would have to be to assert anything different. I know that the author is just trying to get some small business owner to hand over a check for a web site, but come on!

In fact, corporate web presences need tender loving care for many of the same reasons that the author of that article lists for small businesses. Let’s talk advertising, and how quickly ad budgets can be eaten up. The example used above was $400 for a 2"x2" ad block in a local newspaper. So, yes, we can see pretty easily how that’s going to quickly impact the bottom line for most small business owners.

But, what happens when you start pushing those numbers out for a very large company with worldwide branding efforts? Now you’re not just dealing with local newspapers, but national print publications, multiple online media channels, radio spots, and television air time. Ever priced a 30-second spot on NBC during Saturday Night Live on the weekend before a presidential election? Starbucks could tell you a few things about that.

Notice I didn’t just say that the corporate web site needed extra-special tender loving care. I said web presence. Because it’s not just about a single web site. It’s about many sites, not all of them under the control of that one large company. We now have places like YouTube, Facebook, Twitter, and GetSatisfaction to contend with as avenues where customers are expecting interaction with their companies of choice. Its a big, bad, ever-changing digital world out there and large companies generally have the hardest time adapting and managing those changes. If you think that all of that can happen (in a smart way) without any attention to planning or strategic thinking, you’re dead wrong.

And why did it make me laugh so hard I nearly pissed myself? Well, if you ever happen to be in Seattle, feel free to hit me up for beer and stories. I’ll buy the first round.

You drive the business goals for the products we work on. You champion the funding—sometimes, you’re the source of funding. You are probably a Subject Matter Expert in the industry/problem area that the product is targeting, and you got to that place by having done the job of the target user at some point in the past. You know everything there is to know about the product you want built—market segmentation, product placement, use cases, user types…probably right down to how the interface should work, what the color scheme should be, and what font you want to see in the labels.

You are your own worst enemy.

We have lots of different titles for you: product owner, business driver, product director, product planner, sometimes just “business” or “product”, Asshole in the Corner Office, S/He Who Looks for Trouble, Out of Touch Pri…ok, I’ll stop now.

Does any of the following sound familiar?

• When asked what, if any, research you are basing user assumptions on (a typical question for any creative brief at the outset of a project), you reply with “I know these things because I did this job for years and I know what the fuck I’m doing.”
• In a redesign situation, when asked about any known user pain points in the existing product, you say “Well, you have to get rid of Feature X because it’s broken and causes bugs so no one uses it anyway.”
• In a product integration project, when demo-ing existing functionality you frequently say, “We worked really hard on this and everyone likes it, so I can’t imagine it could be any better or done in a different way, but I guess if you have a suggestion…”
• In response to being asked to answer questions giving insight to the background of your project, you ask “Is this just busy work?”
• When talking about user or system administration needs, you respond “Well, the people who do that know what they’re doing because they’re IT guys, so admin stuff doesn’t matter…it doesn’t have to be easy to understand, just cram those screens full of stuff.”
• While talking about use cases, “I’ve already come up with all of the use cases, so no one else needs to spend time on that. I’ll just send you an e-mail.”
• When meeting with designers for the first time, “I’ve already mocked up the app in Excel, so I’ll send that to you to pretty up.”

If your face is getting warm and turning pink after reading that, it’s with good reason. If you’re getting a little angry right now, that’s fine with me, too.

Why? Because it’s hard to feel sorry for someone who, when given every opportunity to succeed by having (very expensive) user experience analysis and design resources available to them, is determined to forge ahead in a bullheaded attempt to have everything their own way.

You know all, therefore you listen to no one. You’ve seen all, therefore no one else’s experiences matter.

I do not discount the validity of the experience of the SME as product owner. I like having that kind of resource available to me if I have a quick question about a potential user behavior…after I’ve had to opportunity to do a little user research of my own, thanks. I like having someone I can run some high-level use cases by to make sure I’m on the right path. I like having someone to check taskflows against before I get too far down that path. And I like being able to corner you, pin you down, and take you through a cog walk on paper before I spend hours refining interface and interaction elements to take in front of your users. (Or maybe I just like cornering you and pinning you down.)

I know you’re invested in your products’ success. I know many of you think of your products as your babies. I know you probably think you’re doing the right thing by being dictatorial micro-managers when it comes to feature set and the user experience.

I also know that you are often the greatest obstacle to your own success.

Here’s a little secret: Everyone on the product team—analysts, designers, developers, project managers…*everyone*–is invested in the success of the product.

Also, you’re not the only one at the table who knows what the fuck you’re doing.

You can work with us, or you can position yourself against us. But I promise that working with the team will net you better results than holding yourself above the team.

"So now the Lord has put a lying spirit in the mouths of all these prophets of yours. The Lord has decreed disaster for you." – 1 Kings 22:23 (NIV)

One of the first things I ask of any potential client with an internal development team, or a team of developers that they’ve contracted elsewhere, is for a description of their development process. If instead of the asked for description, I get proper names (or worse, acronyms) thrown at me, I shudder a little. If at any point I hear the word ‘religion’, as in "Methodology X is practically a religion around here," I throw up a little in my mouth.

What I’ve noticed over the past couple of years is that the people most likely to utter that sickening phrase are those using one of the many, many, many flavors of Agile.

[sidenote: Have you ever sat down and counted the number of development methodologies and processes that have shoved themselves under the Agile umbrella? A brief perusal of my bookshelf and old bookmarks yielded ten:

• Adaptive Software Development (ASD)
• Agile Modeling
• Agile Unified Process (AUP)
• Evolutionary Project Management (Evo)
• Extreme Programming (XP)
• Feature-Driven Development (FDD)
• Lean Development
• OpenUP
• Rational Unified Process (RUP)
• Scrum

…and I'm sure there are more that I've never taken the time to read up on.]

I realize that Agile is all the rage these days, but give me a break. If you’re referring to your software development methodology as a religion, allow me to gently suggest that you consider professional help…and I don’t necessarily mean the sort of professional help that you would get from a consultant, I mean professional help of the psychiatric variety.

Software development is not religion. Your development processes are not dogmatic guidelines to which you should cling for dear life. No one will die if you fail to worship at the RUP altar of IBM. No one is going to hell if you decide to make a plan, or do a little requirements gathering , or even sketch a UI before your developers start coding. And I promise, the nuns aren’t going to rap you across the knuckles with a ruler if you create a little documentation along the way.

(However, your software project could very well go straight to hell, or purgatory at the very least, if you insist on not doing some of those things. Keep in mind that Agile works best when applied in very specific contexts: 1) A team comprised of generalists instead of specialists, 2) Small, contained pieces of functionality, and 3) Individual pieces of software that will not need to be integrated with other software, or into the framework of a larger whole)

More often than not, it is ambitious project managers, or R&D wonks, who happened to read a book on Agile (or just stumbled across 37signals) while waiting for a delayed flight on their most recent useless business trip, that are preaching the gospel that is rapid application development. They exalt the virtues of user stories and scrums. They can often be found muttering to themselves something that sounds an awful lot like…

    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan

…and they are coming after you with a fervor that would make a Southern Baptist minister at a summer revival look apathetic.

You don’t have to get dunked in the river. You don’t have to drink the Kool-Aid. You don’t have to sacrifice reasonable planning and design to the false prophets of project management. You don’t have to adopt a literal interpretation of the scripture that will have you chanting "stories, tasks, iterations" or pushing functionality into a release that your framework isn’t ready to handle just because a "user" (read as: customer) says they want it.

Sometimes it’s ok to say no, even to the people that are paying you.