Archive for the 'User Experience' Tag

I’ve been doing a fair amount of work around screen resolutions lately. There’s always the “users don’t scroll” issue (they do), but have you thought about the device they may be using: laptop or desktop? Probably not. And did you realize that it may affect the user experience, because they might not be using a mouse, but may be using a trackpad? Absolutely not.

Laptop vs. Desktop:

• Screen sizes of 1280 by 800, 1440 by 900, and 1366 by 768 are indications the end user is most likely using a laptop.
• The 1200 by 800 is very popular among MacBooks, and the Sony laptop I’m on right now is 1366 by 768.

And something you probably haven’t thought of: laptops have outsold desktops for years.

For some sites, the majority of users may be using a laptop.

Forget screen resolutions for laying out the page, think about the indications of device type. Over 34 percent of my blog’s audience is the middle of target laptop screen resolutions. A few other sites I work with have percentages that fall in the 40 to 45 percent range. These percentages alone may be a more important number than browser audience. Seriously, who cares about the box model and CSS issues, when the user can’t figure out how to use the scroll bar?

The Bottom Line
Figure out who your audience is. A website that is aimed at developers (a desktop audience) should be designed differently than a website aimed at sales people (a laptop audience). Consider who they are, and what their environment is. For example consumers are now mostly laptop users and expert users at work use desktops, you want to design for whichever of these two fits your audience.

A lot of laptops are on old technology.

A friend of mine has this laptop that’s four years old.

That might not seem that long, but…

(pause)

(pause)

(pause)

It takes ten minutes to boot-up.

Watching that laptop trying to crank through a Flash movie or a website that’s shipping 800k down the pipe for the homepage is a painful experience. There are millions of laptops and underpowered netbooks out there in the real world, many of them held by consumers that don’t want to migrate their files to a new computer, even if they can afford it.

So they stick with their old, trusty laptop until it dies.

Some of the web analysis reports I’ve seen have shown that 75 percent of the user base is still using Windows XP, which was discontinued two years ago.

That alone shows two points:

• There are a lot of people unwilling to upgrade.
• There are a lot of people on slow computers.

The Bottom Line
Bells and whistles might not be a good thing, when considering your audience. A website that works on a web designer’s souped up MacBook Pro might not be working on an end user’s laptop with 1GB of RAM.

Using a laptop means a different user experience.

That doesn’t mean that they are always using the laptop screen, but what it does mean is they are definately using the laptop as a web surfing device. This dramatically changes their user experience. Instead of sitting up in their chair, they are looking down at their laptop, typing and using a trackpad.

I had a long conversation with a game developer about the iPad, how people use it as a window because they are looking down. Laptops are much the same way. They have to be judged within their environment, whether it is a Starbucks, an airport, or a cubicle when the user is on the run.

Home users might be watching a television show or chatting with friends on Skype, but whatever they are doing, they could be performing multiple actions in an environment that’s not sitting at a desk. Four to seven different application windows may be open, and the browser window will not be expanded.

The margin of 700 pixels becomes 600 pixels. That email you are sending for marketing purposes might only be 300 pixels wide by 600 pixels high.

Another consideration: many popup windows and dialog boxes are designed to be 700 pixels high, which are unusable on netbooks that are 1024 pixels wide by 600 pixels high.

The Bottom Line
Designing for the top left corner of a page is more important than ever before. We might have to rethink always having that branding logo there.

Certain actions are difficult on a laptop.

Get on a laptop. Then try using it without a mouse.

Certain actions are assumed to work, like using the arrow keys to scroll through a web page. This is because browser designers have built their applications to work this way. But, there are other actions that are difficult at best and impossible at worst, most of them require holding a button on a mouse — re-size a window, scroll through an editing text area, and perform a multi-select action. These actions require two hands: using the trackpad to scroll while pressing the left trackpad button. Some laptops are missing things. A lot of laptops don’t have page up, page down keys, so the users have to use two keys to scroll down.

In fact, a study performed in 2002 found that not only was scrolling 23 percent faster using a mouse versus a trackpad, the error rate for hitting the target was three times higher with the trackpad.

Trackpads change user behavior. Many laptop users, like myself, are experts at hotkeys — so much so that when I’m using a laptop, I use the keyboard more than the mouse. Actions, such as tabbing through a web form, have to work well or it’s useless. Like most gestural interfaces, if you are depending on mouseovers to indicate status, laptop users are going to be missing out on a lot of feedback, because they are trying to perform an action as quickly as possible.

The Bottom Line
Ironically, many of the same concepts around Section 508 compliance also work well for designing for laptop users. Design it so it’s closer to a keyboard-driven application versus mouse-driven application.

Consider Fitts’ law when designing for interactions.

The size of the target, when using a trackpad, makes navigation on certain sites and, more importantly, performing precise actions, hard. To drag-and-drop in a precise manner is impossible using a trackpad. Try navigating Photoshop using one. I guarantee you’ll be be tearing your hair out in five minutes.

Scroll twice, and hit a target the size of a postage stamp to sign in for personalization — that’s the challenge on CNN.com.

Targets have to be sizable, and dragging the pointer long distances is worse using a trackpad than a mouse. For example, when using a trackpad to go from one end of my screen to another, I have to scroll two separate times from the top left to bottom right corner of my screen. The same works for any direction on the screen for my laptop.

The Bottom Line
Consider distance to take an action and what that action is (for example, a social sign in, which drives a lot of traffic), when designing the page.

From comScore:

The study found that 30.8 percent of smartphone users accessed social networking sites via their mobile browser in January 2010, up 8.3 points from 22.5 percent one year ago. Access to Facebook via mobile browser grew 112 percent in the past year, while Twitter experienced a 347-percent jump.

“Social networking remains one of the most popular and fastest-growing behaviors on both the PC-based Internet and the mobile Web,” said Mark Donovan, comScore senior vice president of mobile. “Social media is a natural sweet spot for mobile since mobile devices are at the center of how people communicate with their circle of friends, whether by phone, text, email, or, increasingly, accessing social networking sites via a mobile browser.”

All channels, all devices, baby.

• 30% of smartphone users accessed social networks via mobile browsers — this was up from 22.5% in 2009.
• Total social networking access via mobile browsers on all mobile phones rose to 11.1% — this was up from 6.5% in 2009. Most of this growth was in the uptick in smartphone usage.

How does MySpace survive if their mobile-centric audience uses their mobile site less?

All of the opinions below are mine and only mine.

On top of everything else happening in the social space (Google Buzz, everyone leaving MySpace, Facebook changes), this happens: Facebook Patents The Newsfeed. You can read the full copy of the patent here.

Now before we all have a “What the hell moment,” here are a few things to remember:

Some patents are virtually unenforceable.

Various companies have patented the shopping cart, the GIF image, the one-click purchase and the affiliate program. The one-click purchase made Jeff Bezos look like a fool for a while, especially after they went after Barnes and Noble.

If you haven’t noticed, none of the above are really enforced except for the GIF image patent, which there’s “sometimes” a $5,000 licensing fee. Unisys at one point threatened to go after every website that had a GIF image somewhere on the site.

That was popular.

A few patents, like the one-click purchase and the affiliate program, have given rise to protests and eventual defeat of a lot of the claims Amazon had over the business process. Most of those patents are violated every second of the day because they are ubiquitous and so mainstream there’s no way to enforce them.

Some patents are more for defense against large competitors.

While it doesn’t make sense for Facebook to sue everyone, I’m sure they’re thinking about what they can bring up against Google, MySpace and a few other large properties with a newsfeed.

Other places are probably thinking about how to re-architect their solutions now to avoid any patent infringement. That said, if you’re running a site that isn’t one of the top 1,000, I don’t think Facebook is going to be sending a lawyer your way anytime soon.

Some patents are for getting money out of people and for increasing market value.

One of the few points people forget about Google is that the concept of AdWords wasn’t invented by them. It was patented by GoTo.com. I’ll admit that Google does it much better than GoTo/Overture ever did, but it was enough of a threat that Google eventually settled with Yahoo!, who had purchased Overture.

The lawsuit against Google related to its AdWords service. In February 2002, Google introduced a service called AdWords Select that allowed marketers to bid for higher placement in marked sections – a tactic that had some similarities to Overture’s search-listing auctions.

Following Yahoo!’s acquisition of Overture, the lawsuit was settled with Google agreeing to issue 2.7 million shares of common stock to Yahoo! in exchange for a perpetual license.

That patent was probably one of the reasons why Yahoo purchased Overture. There are holding companies whose purpose is to hold patents. However, they are selective about who they sue because lawyers are expensive. It’s an ROI equation, and there’s no point going after someone without money, right?

GigaOM says:

Friendster, which was recently bought by a Malaysian company, made much of the fact that had obtained five U.S. social networking patents, at times using the patents to scare off the competition, at least in the press.

Scary.

Some patents are declared invalid.

The U.S. Patent Office grants a lot of patents. It doesn’t necessarily mean they will stand up in court. Gibson Guitars has been on a rampage, suing anyone that produces music simulation software like Guitar Hero. Read more here.

They have yet to win.

What would happen if Facebook went after MySpace in court, and the patent was declared invalid?

What if a single social network invented before Facebook had the same implementation, and Facebook was in violation of the intellectual property of that website? Would that company win $500 million like when Microsoft was sued over the browser plug-in?

GigaOM points out:

The patent is particularly valuable because news-feed style communication has become pervasive since it was launched on Facebook. However, it’s not clear that there aren’t precedents for the technology; for instance, the social network Multiply.com had a similar interface for keeping track of friends’ actions before Facebook launched its own.

Mutliply.com suing Facebook? That would be fun.

What next?

As big as a deal as this may seem, it isn’t until they do something with it. For now, it’s just another asset they have in the universe of Social Media.

That was a question that came across one of the mailing lists — “do I have to learn how to program to be a good user experience designer?” A job posting was listed where the requirements could have been along the lines of smoking crack, and for new designers, they wouldn’t know any better because they are just trying to make a buck.

But should they?

That’s a hard question to answer, especially with the ever changing landscape of the industry.

The answer: it really depends on where you live and what you are looking to do. Many employers are looking for jack of all trades, while others are looking for specialists. Some are willing to give up deep skill sets in one area versus knowledge in all areas, or are looking for people of unique skill sets to build teams around.

A UX Designer in San Francisco is going to have a much different working experience than one in Columbus, Ohio because they will be much different companies.

I’m lucky to have worked in both generalist and specialist environments, and to be honest, I like getting my hands dirty sometimes. That includes building prototypes, doing my own guerrilla usability testing, and even throwing in some design to make it high fidelity. Other user experience designers like to focus on specific areas, like user research. It just depends.

If you know something about code, you’re less likely to design something that can’t be built.

The plus — there’s nothing worse than designing a solution that you think makes it really easy for the user, and then the programmers come back to you and say, “Well, that’s nice, but it’s going to take two months and we have only a month.” It’s like designing a car: if you design an engine that’s too big for the frame, the engine design has to be reworked.

The minus — that said, if you get too heads down in the code, you are going to be less effective as a user experience designer. Or, worse, you could limit your imagination and design a solution that would be more effective if you knew less about what was under the hood.

Specialists get paid more, but have fewer opportunities.

The plus — Everyone loves a big paycheck, and specialists are always going to have deeper knowledge of a particular topic. If you’re good, being a specialist means that you’re sought after. I have a lot of experience in e-commerce systems, for example, and somehow manage to improve those user experiences that lead to improved revenue. That’s a skill worth having that will make you valuable just about anytime of the day.

The minus — If they think you are too much of a specialist, it becomes really hard to get a job (“I didn’t know you could do that”), and in a bad economy, the last thing you want to do is fence yourself in. Those that were working in the field during the early 2000′s remember the day when being a project manager or a psuedo-programmer was a good thing. There’s nothing worse than being “just” a user researcher when they are looking for an Interaction Designer with research experience.

Sometimes it’s just about setting expectations.

Pros — Even if you don’t call yourself a specialist, putting a wider net out there for jobs is better because there may be a position that requires several different skills (Knowledge of JQuery, CSS, XHTML and some light design on top of doing the usual User Experience tasks like wireframes). This could translate into where you build functioning prototypes that the developers can use to build the finished product, but during the interview process. That said, I just recently started learning SketchFlow, a wonderful product that’s part of the Microsoft Expression Suite. There’s no way I could have picked it up as fast as I did without some knowledge of other prototyping tools like Flash, Axure and Visio.

Cons — Some skills required for the roles are so divergent that what they are looking for is a unicorn i.e. that one person that knows all of the above, plus ActionScript 3.0, plus .NET. The people that know all of those technologies either are a) getting paid much more than just being a User Experience Designers, b) do all of them poorly or c) are full of shit. You can only be good at so much.

The real answer? Look at the market and act accordingly.

Do what you have to do, and where you want to drive your career to, to succeed. Talk to other designers in the area to get an idea what they are doing. And remember, it’s a changing landscape — that requires some flexibility.

Are your written materials easy to read? Sometimes people get so caught up in creating a certain image – or squeezing a lot of words into a limited space – that they completely lose sight of readability. Unless yours is a completely visual message, it’s important that people be able to read your words. Make sure your finished piece is formatted for maximum readability.

Make it Easy to Scan

People don’t want to wade through what appears to be a short novel. If the mere site of your written piece overwhelms the reader, you can bet he or she will quickly move on to something else.

• Recommendation: Put your headings and subheads in bold type, use bullet points, left justify your text (don’t center everything) and break things down into short, easy-to-manage paragraphs.

Avoid Giving Readers a Headache

Have you noticed that an increasing number of websites are composed of tiny little white letters set against a black background? Ugh! Instant eyestrain.

• Recommendation: For maximum readability of any written piece (not just websites) stick with dark type on a light background, and don’t use anything smaller than a 10-point font.

Think about Your Font Formats

Sometimes it works to use special formatting to call attention to particular words, but if you’re not careful you’ll end up making those important words difficult to read.

• Recommendation: Go easy on your use of ALL CAPS, italics, underlines, Initial Caps, and other special formats. These all work well on headlines and brief items, but should generally be avoided on longer passages.

Remember, if your letter, website, brochure, or other written piece isn’t formatted for maximum readability, there’s a good chance it won’t get read at all.

I’m working on a few projects with different developers, and whenever a new feature or item has to be added to the feature set, there’s always the, “well, we should be doing it this way because I think this site is cool.” That’s wonderful, because it exposes some great work that’s going on out there, but…

…after one of those sessions, I had dinner with friends, and they started talking about was an online shopping experience. The exact feature set the developer wanted to add, my friends basically said it over complicated the process, and made it hard to complete the purchase (I’m going to hide the name to protect the innocent, but it spelled close to Mike, and they sell, uh, shoes).

Note that my friends use technology all the time, but aren’t experts. They are, however, are consumers and are am important part of the new economy. They are typical users that make user experience experts a need. The one site example is cited a lot (well, Amazon does it), but in very few instances does one site make a competitive analysis across sites in the target audience.

So what do users really want?

User experience and development professionals aren’t the ones that should be suggesting all the bells and whistles, so here’s a list I’ve compiled in my head of what I thought users wanted.

Users want the message to be clear

So many websites try to be clever and cute with the tagline, mission statement and other information that they are never clear why the website is up. The best approach is to have a name that is clear and concise, or to create your own brand (Amazon, Google) so you’re name can show up in a dictionary.

For the rest of us struggling to find a website URL that fits our business model, the other approach is to make it clear on the home page what the website is about. Put plenty of hints (like better copy that the outsource website designer can write) so your users have no question about your service or site goals.

Is it an ecommerce site?

Do you provide services?

Are you trying to get people to sign up for something, so you can contact them?

Then state it! Make no bones about what the site is about.

Users want context to see if they fit

Once the user gets to the site and reads the message, they’ll get a better idea if the site or service is for them. Do you patronize a doctor when you have an eye problem? No. So those customers lost are a good thing, because that means that your resources won’t be tied up answering their questions.

How users evaluate a website after making sense of it:

• Is this a service I need?
• Do I see enough value in it (time, money) to use it?

That’s it. If you provide them with enough context to make those two decisions, you’re golden. In the end, users are a pretty simple bunch.

Users want consistency

One of the general rules about user interface design is that a consistently bad interface is better than an inconsistently good interface, because at least users know what to expect. That’s the theory of user interface patterns: use generally accepted methods of navigation (except when you know when to break them), and users will implicly recognize what you’re doing without knowing the science behind it.

That said, users don’t care about user interface patterns. They aren’t going to scream about your use of radio buttons versus tabs, they’re aren’t going to leave the site because you used a checkbox wrong. They will leave the site if the navigation moves around and appears in different places on the page, or get frustrated because they can’t find something.

Users want to be heard without having to shout

The 2 or so million Facebook users that complained about the new user interface were a vocal bunch, but they probably aren’t the most important group. When most people are unhappy about a service, they don’t join groups and send messages like that, because most people have don’t have that much free time. Sometimes the squeaky wheel is the wrong wheel.

They do the obvious thing — they leave the site. (Note MySpace’s leveling off of traffic — that’s the best example I’ve seen in a long time of a site not working for its users).

Happy users return. Sad users leave. Get it?

Users don’t want the shiny (unless it’s in context)

That e-commerce website I was talking about used a heavy amount of Javascript, Flash and other Web 2.0 technologies that translate into a richer experience. However, even on my megafast download of a pipe (I think I’m geting 20 down on a regular, sustained basis), the site is slow. Very slow.

Slow translates into lost sales.

Shiny is great, especially if it’s in context — YouTube and some of the music sites are great examples — but they are also barriers for users. They might not have the right plug in installed. They might be on a slow connection. They might have a computer that belongs in the Smithsonian Institution. More often than not, there’s a reason not to use heavy Javascript, Flash and SilverLight than to use it. The shiny is cool, but only when it makes sense.

Users want to be guided (without being guided)

One of the general rules about website usability tests is that you almost never listen to what users say, it’s always what they do. That said, I can’t tell you how many times I’ve been through a test where the user absolutely felt stupid using the service or product, mainly because the site wasn’t intuitive enough

Help text generally doesn’t work. Big long Flash introductions don’t work. Dancing flash people don’t work.

What does work are sites are are intuitive enough and forward thinking enough to provide a path for the user to go. The elements of user experience should be defined enough so the site acts the way the user thinks it should act i.e. the user shouldn’t have to learn it, especially for consumer facing sites. It’s about predictive user experience.

I just recently appeared on a panel talking about Agile development and User Experience, the benefits and the pitfalls. It was fun to have a discussion with people of other thought processes about agile and waterfall, but I’m a huge proponent of doing development and User Experience this way.

My first experience with Agile was April 2001, and I’ve run several projects with it since. That original project was as Product Manager for Escrow.com, and we ran iterations for almost a solid year (close to 20 iterations or sprints).

The result? A profitable company with a profitable product.

Three of the projects I worked on went by the wayside. There’s no accounting for issues with company culture. However, five others, including Escrow.com, launched successfully and have had varying degrees of business success. Agile doesn’t guarantee a breakthrough product, the hope is that it removes development process as a risk.

This first thing I’m going to do is define Agile development so we’re all on the same page.

Agile methodologies, or cultures, generally have the following:

• Short development cycles of two to four weeks and are usually called iterations or sprints depending if you’re using Scrum or Extreme Programming.
• Almost daily communication through short meetings, called standup meetings. They report what you are working on yesterday, today and tomorrow so any issues can be discovered early. The purpose of the meetings is to encourage further communication offline. Therefore, meetings are short. If you’re going over 15 minutes, it’s too long.
• Development progress that is measured through what’s called burndown and the product backlog.
• Clients, or product owners, that are intimately aware of progress and prioritize based on product needs. Everyone has a voice in what the product is.
• A process that is adapted to the team. They own the process so they get to use elements that work for them.
• This is key: people who are upfront about their responsibilities and don’t hide their roadblocks.

It’s also key to note that I used the word “generally,” because the process is defined by the teams that use it. So, some may only use elements of Agile and Scrum.

I’ve seen Agile work well for products that require constant improvements, but it’s hard to adapt it to a new development unless you have some time to adjust the process while people are learning. Short projects of less than a month make it hard to do a scrum-like process. I can’t imagine using Agile for a hardware-based product.

But for the web, where everything is changing, it’s great.

Here’s how to convince most User Experience teams that Agile can work:

You get direct access to the developers

One of the major complaints I have about most waterfall environments is that once you write the functional requirements and wireframes, you’re pretty much done. Developers push back, you miss 25 to 30 percent of the requirements because you just didn’t know or no one read your requirements, and there’s always the, “Well, that’s not what I meant” misunderstandings because there was a different interpretation of the wireframes.

I’ve run a Scrum-like process over the phone (I’m doing so for a current project), and the main purpose of the methodologies is to encourage more communication; with daily meetings and constant touching, you usually can walk over to the developer and ask to see the work.

If there’s an issue of the design not working the way you want it to, you can negotiate with the developer to build it in a way that achieves everyone’s goals.

While you don’t get to do as much research, what you do get is to see your work in action sooner

Waiting three months until you see your work turned into real software or website development? This is the process for you. The rub is that most of the time, you’ll get to do two weeks to a month of research at the very most before developing wireframes, or user stories, and that’s okay. Unless you’re inventing the new iPhone, why would you want to do that?

Usually you develop a lot of areas with stubs (i.e. “We’ll do that later, but just put a page there.”) and concentrate on the big functionality. Your initial stab at what to build is called sprint or iteration zero, and in most environments you’ll stay one iteration ahead of the developers. This gives you a little time to move and adapt; and, in some ways, it doesn’t allow you to over think a feature.

From Agile Product Design:

User experience people working on Agile teams become masters of development time travel, nimbly moving back and forth through past, present and future development work.

You’ll see your work as they build it, and you’ll also spot issues in days instead of weeks.

Agile doesn’t mean no requirements. It means requirements that work for the team.

Since the team decides how to build the process, that means the requirements can take whatever form the team wants them to take. If you can’t do wireframes or HTML mock-ups that fast (I can), then this process will be a tough learning curve. However, one of the panelists had a great idea: go to another website that has approximate functionality and copy it, beacause how many times do we need to redesign a lost password process?

I’m a big proponent of the whiteboard or throwing the wireframes up on the wall in printed format; talking through a feature instead of looking at it in a PDF is a much more effective way of communication.

To mitigate direction issues, what I did was develop a really high level style guide to make sure we had a holistic view of the system, then did not annotate wireframes. The developers knew just the form or text elements; and if they had a question about functionality, either they asked about it in the stand up meeting or contacted me separately. Occasionally, I was diving into the code myself to write error messaging, which was okay.

Sometimes, it’s not what you communicate but what you don’t have to communicate that makes all the difference in the world.

If there was particular communication that we felt wasn’t needed, we would cut it out of the process. Who  reads all the requirements, anyway? Usually just the User Experience folks do, while arguing with the developers. That’s an important distinction. If management is forcing something down on the team, Agile isn’t going to work. It’s not about the tools; it’s about the people using them.

If your initial pass doesn’t work, it’s not stuck in the final product.

While there’s not a lot of time for formal testing, there’s plenty of time for guerrilla usability testing. That means you have to bring in or find some test subjects to throw against your ideas. This does not mean you should write formal reports, (there’s not enough time for that) but it does mean you should do enough testing to make sure your product is going in the right direction. You won’t spot every issue, like rocks and sand: you’ll catch the rocks and have to worry about the sand later.

It allows you to fail quicker. If there’s something you spot that’s really, really off-base, you can propose to fix it in the next iteration.

The other members of the team may agree. I’ve pulled features in previous environments without serious implications, and all we lost was a week’s worth of work or less.

Smart Agile teams also pair user experience designers with quality assurance analysts to write test plans for test-driven development. Developers would recieve test cases even before they started development so they knew what they were aiming it. This is great, because QA is one of the best groups of people to do usability testing on. They spot potential issues even before the developers do.

On a few projects that I’ve been on, we saw a 50 percent drop in defects reported and had fewer reworked features.

That’s huge.

You can see progress almost immediately.

One of the biggest frustrations of working in software development is waiting for something to be built. Agile takes away some of that frustration because instead of developers waiting until the last three weeks of a three month project to show results, developers can agree upon delivered features after the first iteration.

This creates a sort of washing machine effect to gathering requirements  and software development. You keep moving toward a common goal of building the final product. Instead of seeing huge leaps of functionality with possible huge leaps in missing the target, tasks are built in bite-sized chunks so you have a better idea of meeting your goal. You also get an idea of whether or not your estimates for building the product are on base, and what you have to adjust before.

It’s about making it to the finish line, one inch at a time.

The 80-hour workweeks are gone… sort of.

One of the rules we had at Escrow.com is that no one worked over 45 hours a week; and if they did, I kicked them out of the office. Two similar projects that I worked on had the same approach.

This was very important from a few standpoints:

• Developers and User Experience designers without a life are angry people.
• Tired developers are ineffective.
• Estimates only are effective if there’s a decent control mechanism.

The main benefit was getting a true gauge of process. How many have been on projects where the developers worked slowly until the last month, then crammed a bunch of hours in to the get to the finish line? How good was that product, really?

Doing estimates well is essential to Scrum and Agile, because then you can accurately decide what’s important and what’s not.

At BidRx, only after we attached Scrum did we get an accurate assessment of what was possible from a User Experience and Development standpoint in a sprint.

That means that developers and user experience designers have to have a good idea of what they can produce within the framework of a normal workweek. Being wrong the first couple of sprints is fine, as long as you can get closer each time. Remember, it’s about attaching iterations to the process as well as the product.

Your voice is heard, period.

One of the greatest things about Agile development is that everyone has a voice. That means that if there’s something you don’t like in the process or the application you are building, you can express your opinion instead of being on the other side of the wall from the developers.

There’s always a user advocate in the process of building the product.

The conculsion

Agile isn’t for everyone; however, when it does work, it works well. It does require a different mindset, and there are flaws to overcome.

Random Thoughts mentions the following downfalls:

• Loss of the holistic view of the system
• No time to prototype everything before development starts
• Lack of extensive requirements
• More development teams working simultaneously, same UX resources
• Fast delivery means less time for testing and iteration
• Loss of time for user research projects and general research and development
• A need to track UX worth and work before a project is completed

I only agree with the two that are in bold. That said, we have to try something different, because waterfall isn’t working.

Some other links:

• Scrum Club
  
• Agile UX

Blog posts:

• 10 key principles of Agile Software Development
• Twelve emerging best practices for adding UX work to Agile development
• Jacob Nielsen Speaks (Because he’s selling something)
• The missing piece: how interaction design can add to Agile

Designing Better Libraries has a great article about the value of User Experience in tough economic times.

The takeaways:

• First, while it may be necessary to scale back on an ambitious UX plan during a recession, there’s no reason not to expand efforts to enhance the personalization of services; this may be the best time to connect with customers.
• Bad customer experiences actually end up costing the organization more because they waste time and require extra work to make up for foul-ups and problems.
• User experiences and the design of them is a low-tech proposition.

Heads up to Putting People First for finding the article.

I think one of the hardest parts of explaining the User Experience process is how it fits within into the complete software development life cycle, especially in a consulting environment.

Clients want to know how to limit costs, developers want to know when they’re going to get in documentation, and your boss wants to know what you can bill for (remember, wireframes are deliverables). Some of the process is very new for developers that have been working in software for a while. Or, as one CTO said to me, “You know, you guys changed the process on me.” And he had worked in an agency environment. And I had just recently worked with a couple of agencies that know they needed to start paying attention to it, but didn’t know where to start.

This is a document I developed at my previous company to explain the User Experience process not only to clients, but internally within the consultancy, and it helped greatly show that we were following some kind of process (Well, I tried to, but you know how that goes on some projects).

I included where sales came in, to further illustrate the point that User Experience extends even into the sales process because a good Information Architect or Creative Director can sell the concept, and a final review with the developers, to fix issues that came up. A lot of consulting engagements lend themselves to a waterfall process because of fixed costs, so that’s what this is modelled around.

What’s the process you follow at your company?

Airplanes pretty much fly themselves today — other than making sure things are working correctly, pilots don’t have much to do when something bad happens.

Example: today’s US Air 1549 flight that crashed into the Hudson River. The Miracle on the Hudson, they’re calling it. I don’t think it’s so much a miracle — it’s a job well done.

Airbus and Boeing spend millions of dollars in analysis to make sure the user experience of their airplanes is easy to use, and can be used in just about scenario, including this one: a bird strike causing an engine failure.

The user experience from allowing the pilot to land the plane in water to getting every single passenger off the plane before it sank is meticulously planned and tested, over and over again. It’s not just a miracle that they survived: it’s intense planning and testing that allowed for this to happen, like a movie script.

Most of our jobs don’t have a life or death aspect to it, but sometimes user experience is life or death. Think about this: there hasn’t been a major airline crash in the U.S. in seven years. That’s amazing, if you think about it. Good user experience plans for user mistakes and eliminates risk. This is the perfect example.

Congratulations to the pilots and the engineers at Airbus for a job well done.

Too bad for Boing Boing — bad timing.