Archives

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

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.

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.

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?

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.

photo credit: dave_7

A few years ago, a friend of mine asked me to help him estimating the conversion of a client/server application to the web. He came armed with a spreadsheet of features, I came armed with Ibuprofen and a red pen.

My usual approach to estimating involves breaking down the features into things that can be implemented by a pair of developers within a two week period. I give these a complexity factor of 1-5, then run them through an empirically derived formula to come up with an estimate in terms of person-iterations. (It’s actually a little more complicated than that, but this is the main effort). Getting the count and size of these mini-features right is the key aspect of this technique. His spreadsheet had almost 300 features listed, and so we settled in for a day of fun.

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:

Some interesting posts from around the blogosphere:

• The GWT Plugin for Grails has been stuck in version 1.4.x of GWT for forever. Michael Galping has published a two part (one and two) series at IBM Developerworks on integrating Grails and GWT 1.5.3. Extensive, well illustrated with full source code available for download.
• InfoQ has published an interesting conversation about Ajax and COMET versus HTML Web Sockets, i.e. hacky COMET versus real bi-directional communication mechanisms between the server and browser.
• UXDesign.com has a concise summary of an Alan Cooper Interview video from 2008. User Experience Design, baby!
• David Hamill has some provocative musing on the difference between usability and user experience design. Not sure I agree with everything he has to say, but it’s a question that comes up often and is worth thinking about.
• A bit older, but I just came across it: the original ScrumMaster, Jeff Sutherland, has an interesting article about ROI and incremental development. The conclusion? Incremental is better. But seriously, we don’t have enough rigorous thinking and writing about how good design and process reduces the cost of software in the long term (while perhaps increasing it in the short term).

These were some of the posts that I found valuable over the last week. Please share yours in the comments.

Rosenfeld Media contacted me after I published my review of Luke Wroblewski’s “Web Form Design: Filling in the Blanks.” They offered Agile Ajax readers 10% off “Web Form Design” or any other purchase at rosenfeldmedia.com. To redeem, simply enter the code PATHFINDER at checkout.

Usability and design guru Luke Wroblewski knows that web forms suck. More importantly, he knows why – and how to make them suck less.

For the past few years, the Yahoo! product design exec has been presenting his ongoing research into the humble HTML form at conferences and on his blog, Functioning Form. I attended Wroblewski’s presentation at An Event Apart Chicago 2007 and came away super-impressed. His persuasive mixture of case studies, existing research and newly commissioned usability studies helped shed light on the patterns and anti-patterns that determine whether users successfully complete your forms or give up in disgust.

All of Wroblewski’s preparation came to fruition earlier this year when he published “Web Form Design: Filling in the Blanks” (Rosenfeld Media). After finally taking the time to read the book cover to cover, I’m mad at myself for waiting so long.