How to analyze a usability study

Posted by: Josh Walsh in User Experience.

Most of the value you gain from a usability testing session comes from the analysis after the session is complete. I have been involved in a few sessions recently where no formal analysis has been conducted. I believe this is a mistake.

Traditionally, the analysis portion of a usability session takes quite a long time. The end results is usually what I call a “Dead Document.”

“Dead Documents” are reports that have value, but negatively impact productivity. This is usually because it takes too long to create the document, or there isn’t enough time to consume it.

I have developed a quick and dirty system for analyzing the data. It requires only a few hours to create and only a few minutes to consume.

Continue →

Technical Stories in Agile Software Development

Posted by: Dave Goerlich in Agile.

I just read this interesting post on technical stories by Jack Milunsky.  In the article he addresses the question of “Should technical stories appear on the product backlog for a Scrum project?”  For billable client projects, a related question exists of “Are technical stores billable to the client?”

The answer to both of these questions is yes.  Technical stories represent efforts necessary to improve the infrastructure of a system.  While they do not add value to the system through the addition of new or refined functionality,  they do directly add value to the system in other ways.

Continue →

Who’s Attending Codemash 2010?

Posted by: Josh Walsh in Events.

The Codemash Conference is not just about great content, but it’s about great people.  Last year I met some great new friends and even did a fair amount of business with them.

I’ll be podcasting, blogging and networking all week.  If you are around, make sure to hunt me down.

Are you attending?

If you are attending, post in the comments so we can find each other this week.

Design Last Design

Posted by: Josh Walsh in Design.

Agility comes from your ability to rapidly gather feedback about the software you are building, and to react quickly. This is especially true during your initial build phase.

Interface First Design

I’ve always been a supporter of Interface First Design. To your customer, the interface is the product. The customers needs are all defined by the way they interact with your product. This is why we have always encouraged designing the interface before writing any code. This keeps developers from over-engineering features and ensures the customer gets what they expect from you.

However, I often find myself over-designing. I waste a lot of time designing things that will be deleted in future iterations.

Introducing Design Last Design (DLD)

Recently, I’ve been experimenting with what I call “Design Last Design.” Essentially this means we sketch out a user interface in the beginning, as we always have, but we don’t pretty it up. We build the whole application in greyscale with standard fonts, and boxes, but nothing pretty. Near the end of the project, we wrap it all up with graphic design. The interactions are all still designed up front, but the graphic design is laid on at the end. We don’t waste time on graphical details which are not yet important.

Continue →

Workflow – Minimally Marketable Features

Posted by: Dave Goerlich in Agile.

As I described in the overview of Our New Development Process, the MMF (Minimally Marketable Feature) workflow is the customer facing portion of our development process.  Our changes in this area have had the biggest impact upon our clients, and have met a positive response.  It has allowed us to isolate our clients from the implementation, and remain focused on the behavior of their application.

Our transition to a lean development process was the first exposure most of our clients had had to any type of agile environment.  Understandably many of them felt out of their element and truthfully we felt the same way.  What really made the transition successful for us and our clients was the trust that came from the good relationships we’ve maintained.  Being very transparent with our clients went far in cementing that trust.  We let them know that this was a major change for us too, that we were (and still are) learning and refining our process.  Since our clients are very much part of the project team, I openly solicited input from them on how we could improve the process.

Continue →

New Years Resolutions are for Lazy People

Posted by: Josh Walsh in Life.

New Years Resolutions are not agile.

With the new year upon us, it’s that time to make our resolutions. But, why do we wait to do this at the beginning of the year? If change is needed, make the change now.

I came to realize the problem with this a month ago (beginning of December). I’m a typical geek. I sit in front of my desk for about 12 hours a day, and most of my exercise comes from walking to the restroom down the hall. Needless to say, I’m not a perfect specimen of health. I’m not fat by any stretch, but I’m not in shape and I could eat healthier. So, like many I decided to do something about it this year and make “focusing on my health” my resolution for 2010.

Except for one small problem. I needed change NOW, not starting in a month. Waiting a month to start to change would make my problem worse. Suffice to say, I joined the gym that day and today (Jan 1), I’m already feeling much better.

Continue →