Topic: user experience design

Your SDLC or Your Product – You Decide

Michael Walkden, Wednesday, December 9, 2009 @ 10:33 pm

…or the telephone game

photo credit: tallkev

Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.

The problem stems from the fact that when organizations reach a sufficiently large size they must focus on consistency of delivery and efficiently using people’s time. For large organizations this is part of the mix that makes up their competitive advantage. However, the sheer size and number of moving parts required to enable clocklike consistent delivery leads to the most knowledgeable people about the customer never directly speak to the people responsible for building the product. Or translated into a traditional SDLC, the definition/high level design team isn’t communicating with the build team. In my experience they are usually two different groups of people. I’ll give you an example:

A while back, I was leading a software development team creating a product to be used by all 170,000 of my customer’s employees on a daily basis. They happened to have a team of user experience designers and wanted to take on the “big picture” part of the design themselves. This company could afford the best and the brightest talent - and was able to attract them. Individually the folks on this team were talented and knew their craft well. I actually learned a lot just from my brief time with them. However, once we got the design in hand it was obvious that the usability team’s artifacts weren’t going to work for the project. They didn’t meet the end user’s needs nor were they implementable within the time we had available for the project. The client’s design team literately spent months of time showing users lo-fi prototypes, running focus groups, and understanding usage statistics from similar applications. But, the simplicity the end users craved didn’t match the complexity of the business rules required. Upon further investigation the customer’s design team never was given a business level view of the problem to be solved. We tried to merge the business requirements with good usability, but ultimately the franken-design didn’t work. We had to throw out the big picture design and use them as ”guidelines” instead. Clearly it was a waste of talent and a haphazard way to build a product.

In hindsight the design team should have been presented the complex business rules so that their design could incorporate them from the beginning. However, the customer’s SDLC only allowed the design team to be engaged in the definition/high design phase of the project. Once we got to the design phase they were hard to find. By the time we got into the build phase the development team was simply a distraction from other work for these designers. A better model would have kept the designers on the project as each piece is built. I’m not suggesting full dedication to the team – 40 hours a week. That would be nice, but that’s not likely possible in most organizations. I’m suggesting a small time commitment over a long period of time.

Most of the time projects are actually building products. If you are building a product, but focusing SDLC metrics and efficiency, keep in mind that your phases are likely making walls around teams and causing ineffective communication between them. As Matt from 37Signals points out, “Inefficiencies are what make you special.”

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Developing Good Wireframes Ahead of Visual Design

Vena Chitturi, Thursday, August 20, 2009 @ 1:39 pm

In the design process, the wireframes focus on the structure/layout of elements on the screen, and the interaction that the screens will provide. The visual design focuses on aspects of design such as colors, graphics, branding and mood.

Design encompasses both of these, and both are equally important. But by first addressing the software's information design & interaction needs, wireframes help you make sure the user experience makes sense, including that the workflows are natural and intuitive for users, and that the interactions are easy and clear. Without these, a site may not be very usable. Developing good skeletal wireframes before fleshing out the visual design is important for several reasons.

Focuses the Conversation
Visual designs tend to elicit more of an emotional response than wireframes. Hence, putting a fleshed out visual design in front of a client can divert attention from the structure and interaction of the page, and tilt the conversation more towards the color and graphic choices. Skeletal wireframes help you and your client focus the conversation on the business goals and the needs of the user. Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Thinking About Displaying Data in a Pie Chart? Think Again.

Matt Nolker, Monday, August 3, 2009 @ 8:15 am

From John Graham-Cumming, an excellent point about pie charts: they fail to convey information as well as bar or line charts. Why? Apparently, people aren't able to perceive changes in area nearly as well as they perceive changes in length. It's easy to see in this example from Wikipedia. Something to consider next time you're designing that executive dashboard.

Related Services: User Experience Design, Flex, Flash and Air, Custom Software Development

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Design Documentation

Alice Toth, Thursday, July 30, 2009 @ 5:31 am

photo credit: theD40kid

A few years ago, I worked on a team that was trying to move the business side away from the waterfall method into more of an agile approach so there wouldn’t be such a disconnect between design and development. Since there was no blueprint on how design could be done in an agile fashion, resistance was very high. One of the major sticking points, however, was in documenting requirements. The business side controlled the process which meant no one could see or review the requirements until they were released by the analyst. In a world view of us vs. them, collaboration was not very high on their list.

Collaboration, however, is high on the list for agile development. So, how to resolve this conundrum and begin to merge the two teams. Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

User Experience Design

Reducing Costs: The Power of Sketches

Sasha Dzeletovic, Friday, July 10, 2009 @ 2:47 pm

The very word sketching doesn't invoke a lot of respect, especially when mentioned in the context of software development. After all, User Experience Design people come up with wireframes, diagrams and designs, not sketches.

Sketches are considered a throwaway byproduct of the design process. What I would like to point out is the value of sketches and why they should be given an official slot in development process.

Since Pathfinder does Agile, understanding the value of user based testing comes naturally - "Release early, release often", right? How quickly can you release a sketch in order to get that ever so valued feedback? That's the key to reducing cost through sketching. By reducing cost you can make a better product within a given budget.

To really get the best of this "quick release testing", there are several things that need to be understood upfront:

1. A sketch should be done with pencil and paper or equivalent. There is no quicker medium for visually explaining an idea.

2. Making a sketch should take seconds. otherwise it's not a sketch.

3. Everybody can make a sketch. You don't have to be a visual designer. Don't try to make it into an art piece because that's a misguided effort. Leave details for when you figure out the basic idea. The point is that at least you understand what you've sketched.

4. A sketch is not a wireframe. They both have  different purposes: sketches should be used to explore and "test" ideas cheaply, wireframes should be used to explain IA.

5. Paper will take anything. When sketching, one has a rare opportunity to think without boundaries. Don't take technology, standards or any other consideration into account when sketching, nothing but  user end goals. You would be surprised how apparently challenging interfaces can be produced efficiently if developers get to understand them really well.  A good sketch is the beginning of that process.

6. Without fail, sketches generate discussion because of their associative power. Make more sketches and you will have more discussion. The more aspects you discuss, the more unknowns you will discover. The more unknowns you cover, the less money & time you will spend trying to wedge a square peg in a round hole.

It's an interesting exercise to organize sketches chronologically and see the progress of an idea. A lot can be learned about what you didn't know at the beginning and you might consider from the start the next time.

My hope is that in the near future visual interfaces will have to be bound less to existing standards for ease of production.  This would create a need for visual interfaces not yet seen which makes them exploration for which plain old sketches are the best tool.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

The Importance of User Experience – Do You Understand It in Your Bones?

Bernhard Kappe, Monday, June 29, 2009 @ 6:51 am

Business Week had an article earlier this week on Cloud Computing that made a complete hash of the subject. However, there was one paragraph that was right on the money:

Apple and Google understand in their bones that simplicity and ease of use are essential to broad adoption of products and services. That lesson doesn't come so naturally to Microsoft and IBM.

That's why we integrate user experience design into the agile development process, and that's why we advise our clients to release the simplest software they can early, so they can learn from real user feedback and continue to make improvements based on that learning.

It's like John Gruber writes over at Daring Fireball:

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
—John Gall

If there’s a formula to Apple’s success over the past 10 years, that’s it. Start with something simple and build it, grow it, improve it, steadily over time. Evolve it.

Do you understand that in your bones?

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Integrating Design and Agile Development

Bernhard Kappe, Monday, June 22, 2009 @ 5:04 pm

If you liked my colleague Alice Toth's presentation on Agile Requirements, you'll like her talk on integrating design and agile development:

AGILE AND ME a story with just enough documentation.

A typical waterfall project produces pages and page of end-to-end requirements for the entire project as it is envisioned (but not necessarily as it will be built). The people compiling these requirements are, of course, part of an assembly with only the most cursory involvement with others outside their department. After all 9,238 lbs. of paper are heaved over the wall with a hearty “good luck!” and a cheery wave, the silos are once again in place and silence is golden.

While agile was taking hold of development, design was still stuck in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements? Here's how we do it at Pathfinder:

Like what you see? Check out more of Pathfinder's presentations, whitepapers and articles here.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Tech Terms that Drive Business People Crazy

Paul Dittmann, Monday, April 6, 2009 @ 5:55 am

Most designers and developers today are familiar with the concept of Personas for describing the users of a system.  In fact, you can use the same concept for how you talk to business people - the consumers of your services.  Put yourself in their shoes, and your services will be better received.

One of the things that drives business people crazy when talking to tech people are the terms they use.  Here are a few to avoid, and what might work instead:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Web 2.0 context menus vs. Web 1.0 link lists: Style over usability?

Brian Dillard, Monday, October 20, 2008 @ 1:59 pm

As Ajax spreads new UI conventions to the masses, it's important to apply a critical eye to the usability of those conventions. Several big-name sites have launched extensive redesigns in the last few months, from Twitter and FriendFeed to Flickr and Facebook. Certain trends are solidifying, especially the use of context menus that are hidden until a user mouses over an item, then displayed as a series of icons, text or both.

First up we have Flickr, whose homepage redesign emphasizes the social networking aspects of the service. A Recent Activity feed, modeled on Facebook's iconic News Feed, showcases favorites and comments from your contacts. The default view for each item displays its age. When the user hovers, though, the same real estate becomes home to two icons. One allows you to add your own comment; the other "mutes" activity related to that photo and removes it from your feed. Neither option is represented by an industry-standard icon, and no tooltip is provided. Even the status bar shows only an inscrutable URL: a hash sign.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Four blatant iPhone usability blunders (and one constant annoyance)

Brian Dillard, Thursday, September 4, 2008 @ 12:14 pm

I've been an iPhone 3G owner for about six weeks now - six weeks of love, loathing, cool apps and connectivity problems. Rather than complain about poor network coverage, though, I'd like to delve into some of the vexing usability problems that hamper the phone's user experience.

No ability to disable autocorrect completely

Like pretty much every autocorrect feature ever built, the iPhone's does more harm than good. It always thinks it knows best. If you don't watch it like a hawk, it will render everything you type completely nonsensical. Proper nouns, abbreviations, profanity - all get turned into gibberish by this well-meaning but deeply flawed function. And god forbid you try to use the classic email e.e. cummings mode in which uppercase letters don't exist. The iPhone literally will not let you output the word "iPhone" without throwing in that capital "P." It's maddening.

If the purpose of autocorrect is to allow you to type quickly without having to monitor your output, it fails miserably. On the iPhone, if you want what you type to show up verbatim on the screen, you have to pause at the end of each word to ensure that the OS is not about to substitute its own wisdom for your actual intent. I would honestly rather type on a 1999-era StarTAC numeric keypad.

None of this would be as galling if there were a setting to turn this feature off. But there isn't. Elaborate, unwieldy workarounds have been suggested - all because Apple users know that the folks in Cupertino often paternalistically ignore their users. Microsoft's OS and apps may suck, but you can usually customize the hell out of them. Not so Apple's.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (9)

Software Development

“Ajax overhaul, Part 4: Retrofit existing sites with jQuery and Ajax forms” now live at IBM developerWorks

Brian Dillard, Monday, August 4, 2008 @ 1:16 pm

Last week, IBM developerWorks published the fourth installment in my jQuery/UxD tutorial series. Ajax overhaul, Part 4: Retrofit existing sites with jQuery and Ajax forms shows how to turn a multi-page checkout process into a single-screen interface using two jQuery plugins: jQuery Form and jQuery UI Tabs. As with previous installments, I tried to show not only how to use open-source JavaScript libraries, but why. Ajax integrates into existing webapps best when it's used to improve their user experience design rather than just thrown in for its own sake. In the example application I constructed for this series, Ajax was used to simplify the shopping process rather than complicate it needlessly. As always, I focused on progressive enhancement so that the overhauled interface didn't leave any users behind. This is the final installment of this series, at least for now. I hope to publish on additional topics at developerWorks soon.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Google Calendar: Finally, a search box that makes sense

Brian Dillard, Monday, July 28, 2008 @ 4:31 pm

I've been complaining for months about a usability problem with Google Calendar's default search behavior, so I figure I should document that it's finally been fixed. Ever since gCal introduced the concept of public calendars, hitting "enter" in the global search box has kicked off a trawl through the public-calendar database. Instead of searching MY OWN calendar for, say, my Aunt Donna's birthday, gCal instead searches public calendars of, like, sports schedules and Kazakhstanian bank holidays. Smart.

Now, though, that behavior seems to have been flipped. "Search My Calendars" is now the default action, while "Search Public Calendars" has become the secondary action. Bravo!

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Fresh paint or new drywall? The cost of changing IA or design mid-project

Brian Dillard, Monday, June 16, 2008 @ 4:53 pm

We software engineers - and our clients - tend to think of visual design as a coat of paint. The arrangement of elements on a screen seems like a purely decorative concern, something that can be applied to the bare walls of an otherwise functional application at the very end of the development process. Anybody who's ever spent much time coding at the view layer knows differently. If effective visual design planning doesn't occur early in a project, there's often a hidden cost. Reskinning an application is more like installing new drywall than applying fresh paint.

The PR wizards who launched the web standards movement have propagated the idea that if you just mark up your content and code semantically, then it's a trivial concern to alter its appearance. This is true up to a point, but most sites have a large number of person-hours invested in their stylesheets, images and other purely "decorative" assets. Because browser vendors haven't consistently implemented existing web standards, even the most well-meaning programmers must litter their code with hacks, filters and nested containers to achieve visual fidelity. The hooks for achieving a given look-and-feel often penetrate deep into the view-layer code. Altering that look-and-feel often requires changes to those hooks, which adds risk to a project and almost always breaks lots of tests.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development