Blog

Driving User Behavior in Unexpected Ways

In the Schiphol airport in Amsterdam, the urinals have flies in them.

human form interaction in airport urinal

Source: http://www.urinal.net/schiphol/

It’s not a real fly, of course, but an image of a fly etched into the porcelain.

human form interaction urinal

Source: http://www.urinal.net/schiphol/

According to data collected by Hoax-Slayer.com, the fly is placed in the “sweet spot” that reduces splashing from the urine stream. Men instinctively aim for the fly (for fun? to wash it down the drain? for target practice?) and it keeps the bathroom cleaner.

The fly in the urinal appears to be a clever way to drive user behavior in an indirect way. Is it more effective than a sign above the urinal that says, “Watch where you aim. Keep the floors clean.”? I don’t know. But it’s certainly a lot more interesting.

What are other ways interface designers can take advantage of natural human tendencies? What’s the web equivalent of the urinal fly?

Lean UX Design

balsamiq lean ux design mockup

A few weeks ago I attended a lecture by Jeff Gothelf about Lean UX, the process of integrating user experience design into an Agile development environment.

Traditionally, design (in a web or software context) is done in a waterfall process, meaning the steps happen sequentially. Figure out the requirements, then design the product, then implement the design, then test, then refine, then you’re done! This process has some valid strengths, as there’s little ambiguity and it gives everyone involved a very clear sequence of steps to follow to get from beginning to end.

However, waterfall and Agile don’t work well together at all. Agile is all about rapid development and frequent iteration. You quickly develop a version of the product so you can see how it works in the real world and revise it quickly. In a formal Agile environment, these iterations are structured to last 2 weeks (or sometimes 1, 3, or 4). It’s impossible to incorporate a traditional waterfall UX design process into Agile development, because the fast pace and frequent iterations of development can’t wait for UX design to be “finished” before they begin.

So how do you bring UX design into the agile environment? Jeff explained how he first failed and later succeeded in merging design and development in an Agile framework. At first he tried to maintain the waterfall mindset (design then development) with shorter timeframes to fit into the Agile “sprint.” This inevitably failed. Trying to compress months of work into a few days wasn’t the solution.

What ended up working was treating UX design as a part of the development process. Bring designers and developers together into paired units to work together in a collaborative iterative environment. Sketch out ideas as a group then refine the code and design independently based on what was created together. Focus not on deliverables (such as “final” design), but rather on creating anything that can be implemented, tested, critiqued, and refined.

Obviously, this is a significant change in work from the traditional method, and implementing it in any work environment will require commitment and buy-in from everyone involved (and those paying the bills, obviously). But as Jeff emphasized, the value of constant iteration and improvement is significant compared to the cost of doing all your design work up front and then assuming (hoping?) it’ll be exactly what was needed by the time the project is complete.

P.S. The lecture I attended was organized by the Boston PHP Meetup group. I’ve attended a few of their events and I’ve been consistently impressed by the group’s level of organization and the quality of the presenters. If you’re in or near Boston and like this type of thing, check out the group and attend some of their events. 

P.P.S. The image above is a sample from Balsamiq Mockups, a rapid wireframing tool. I haven’t used it professionally, but the demo is pretty awesome. 

Scrub “Can’t” From Your Vocabulary

Get Shit Done - Don't Say Can't

When faced with a new challenge, it’s easy to come up with reasons that you “can’t” do it. But GSD requires you put those reasons aside and figure out how to get it done.

Let’s say your project requires the use to a program you haven’t used before. Do you say you can’t use that program? Or do you figure it out and make it work? Odds are good you won’t need to be a power user right off the bat to accomplish what you need.

I moved to Los Angeles after college to pursue a career in filmmaking. To pay the bills I was happy to do pretty much anything. I did some work as a production assistant, volunteered on student films to gain experience, and looked for any opportunity to work, get experience, and make some money.

One day, my friend’s writing partner asked me if I’d done any editing. I had some experience editing the short films I’d directed, but nothing beyond that. But that counted, so I said yes, I had editing experience. I got a call the next day from a post-production house looking for editors. They asked if I was familiar with Final Cut Pro. I’d used it once or twice, but I was hardly an expert. They were pressed to find someone who could start working soon, so they said I could come in, try a project, and see how it worked out.

I immediately went to the nearest book store and bought Final Cut Pro for Dummies. I read it that night and went to work the next day. They sat me down in an editing bay, told me what I needed to do, and I got to work. I started slowly, and as I worked I got more comfortable with the system and my productivity increased. I used some of the tricks I’d seen in the book to make things look fancy, and by the end of the project they were very happy with the work I did. I continued doing freelance work for that company on and off for the next three years.

It didn’t matter that I wasn’t the strongest FCP user they could have found. What mattered was that I was willing to give it a shot and was confident that I could figure it out.

That’s not to say that you should blindly accept any opportunity regardless of skills and abilities. Once when I was job hunting I was asked about doing web design work that was clearly above my design skill. Sure, I’m familiar with Photoshop, but I knew I wasn’t the right person for the job in question.

In Los Angeles, I had enough familiarity with computer editing to know I could fake it until I made it. Accepting an opportunity that I was completely unprepared for would have been bad for the company hiring me, and it would have damaged my credibility. GSD requires that you know yourself, trust that you can figure things out, and aren’t afraid to try.

Work In Progress

under construction

If you’ve been here before, you may notice things look a little different. The theme I use for this site, Visual, recently got updated, and I’m in the process of tweaking the site to work with the theme changes.

There are some images that have to be reformatted and pages that require a little reworking. I should have everything taken care of over the next few days. In the meantime, if you come across something that seems broken, please let me know. Thanks!

Developing the Minimum Viable Product

Developing a product is a perpetual trade-off. There is always competition between the desire for greater functionality and the push to launch quickly. A critical part of the product management process is deciding what features get prioritized for launch and which get pushed to the back burner for a later date.

4ormat minimum viable productA recent article on Techcrunch caused a stir: Bootstrapped Startup Saves over $100K by Dropping IE. The founders of 4ormat.com decided they didn’t want to code their app for Internet Explorer, so IE users who try to sign up are pointed to download pages for Firefox, Chrome, and Safari.

I bring this up not to call attention to my own recent comments about IE, but rather to highlight the thinking that went into this decision for the business owners. This was very clearly a product decision in that it was defining the scope of their product’s features and the work required to build the application. But it was primarily a business decision. What was the cost (in time, money, and resources) to make everything IE compatible, and how did that measure up against other priorities? Continue Reading

Page 1 of 3123