By Jim Berney on Sep 15, 2008
Jim Berney is a senior user experience designer working on Project Kenai. Jim's been designing both consumer and enterprise applications for over 20 years.
Friday, September 5th, the switch was thrown to make Project Kenai live. Given that over a year has gone by and lot's of hard work by all, it was an exciting moment.
Since one of the original goals for Project Kenai was to demonstrate web2.0 technologies, the project followed the Agile Development model. Coming from 8 years of supporting the Java ES middle-ware products where design/development cycles could span over a year, the quick pace of the Agile model was something new. Design cycles are weeks, not months, or even years. Instead of one huge delivery at the end, the site functionality and UI evolve. This allows a much longer alpha period where users can begin to engage with the site, and in the case of Kenai, create new projects and begin working with the features to provide feedback.
The Project Kenai team set aside the time to perform usability testing after key milestones to obtain additional feedback and to validate design. Two usability studies have been performed to date, one at the beginning of the private beta period and another just recently in July 2008 before the public beta began. Also, Project Kenai is using an interactive tool from uservoice.com to collect user feedback in real-time, allowing users to submit, vote, and comment on issues. Take a look at the preliminary results.
Assuming that user experience design is iterative, the Agile model fits nicely. Instead of spending a lot of time delivering a fully designed specification (that is never right the first go around), you spend shorter durations of time working on specific layout, component, or page design. In an Agile model, each new feature, component, or element of design is allocated into a design iteration (the zembly.com team refers to an iteration as a sprint). Each iteration is given a concise start and end date.
Deciding how to chunk your design into iterations requires some thought and planning. In some cases, a single iteration may not be enough time to complete the design features allocated for that iteration. For example,
let's say you're designing the Search feature and how search results
will be displayed. This effort may require multiple iterations both for
design and engineering. Some chunks may also require longer periods of
time than originally anticipated. Leaving slack time in each iteration to
support some amount of catch up from the previous iteration is a good
idea. If at all possible, use your bug tracking tool to capture and
repackage the unfinished work from each previous iteration. As you plan your iterations, assume design rework. Design is going to change, and that change will have ripple effects throughout your interface.
The Agile Model doesn't come without challenges. Since design is approached as a series of chunks, each containing a discrete set of features, an overall design road-map is important. Otherwise, your design will come across as piece meal and may not fit together well at the end. A style guide (brief specification) and set of design templates (e.g., using Illustrator or Visio) can help ensure your design stays on track. As decisions are made, the style guide and templates are updated accordingly. I
have found that using a wiki to post wireframes, design
rationale, and team discussions to be a quick and effective means of
communicating. The wiki, coupled with the wireframes and style guide
become the design specification for the project. Since each project created in Project Kenai is provisioned by default with a wiki, I was able to create a xDesign project, then use the wiki for specification.
Your design road-map must include the visual design for the project. Once you start to move a design from wireframe to implementation, some level of visual design is assumed. Thus, unless you plan on lot's of rework, effort should be spent in the beginning of the project to ensure that your visual design is adequate for the first phase of the project. This is not to say that visual design will not change, but that site-wide changes are major and will disrupt an Agile model. Each rev of your visual design should be planned and scheduled into the project delivery.
Another problem to guard against is "style creep", where you start off using one style for component design or layout, then as the design matures, the style creeps or morphs into something else, leaving your site with inconsistent look and behavior and requiring a lot of rework across the site.
Reusable components may seem a no brainer, but selecting, customizing, and implementing them isn't. Since Project Kenai was unlike any other web project at Sun, there wasn't a style guide or UI toolkit just sitting on the shelf waiting to be used. Everything had to be redefined. Sure, you can attempt to use third-party widgets and toolkits, but rarely do they just drop in to your design. Finding and implementing the right components is a critical dependency and must be scheduled. This was in stark contrast to the Java ES environment where there was an established style guide (Sun Web Application Guidelines) and toolkit (Woodstock).
Early on, the Kenai Project organized a UI team (referred to as a scrum in the Agile Methodology) that included interaction design,
product marketing, and engineering. This team meets at the beginning
of each design iteration to specify and design new features, pages, and
interaction for the upcoming design/development iteration. Wireframes are
produced that allow the team to visualize and refine the design. Once the design is approved, engineering begins implementation.
Over the past year xDesign has worked as an integral part of the Project Kenai team to lead the user experience design. This effort has included user research, conceptual and page level design wireframes, visual design concepts and production artifacts, usability testing, and much of the html/css markup embedded in the rails applications to implement each page. Design and change take time, but the Project Kenai team is dedicated to collecting and taking action on user feedback.
Now that Project Kenai is in public beta, the next few months will be spent refining the navigation, refining the layout of key pages, implementing usability enhancements, and enhancing the visual design. Watch the beta evolve with each new build!