UX Agile

VersionOne Activity Stream

andy — Fri, 02 Oct 2009 14:45:27 +0000

I’ve been dabbling with a “river of news” or activity stream for many months at VersionOne, largely to satisfy my own desire to have a more global view of things happening in the system. We’ve decided to release this for use, as open source. It’s built on the Titanium Application Platform for multiple operating systems (win/mac/nix). The rendering tech is Safari and the application is implemented in Javascript (with JSDoc!).

It’s worth noting that this application was built by me, the UX guy, at VersionOne, not the development team.

That said, here’s what it does:

Presents an activity stream of recent changes in Stories, Defects, Tasks and Changesets (e.g. checkins)
A “My” view which presents your recent activity
Notifications with Growl (osx / win) of recent changes
Minimize to tray / doc

Thanks to VersionOne for supporting this 20% style project and to the LizardFeeder Mozilla project for inspiring it.

VersionOne Enterprise & Team users can install the beta application from Appcelerator hosting. Upon launch it will ask you to configure your VersionOne instance URL.

The application is open source, unsupported by VersionOne, and hosted at github.

A JetPack for your Information Radiator

andy — Tue, 18 Aug 2009 18:25:04 +0000

Information radiators are an essential component of the team room, supporting overall awareness by the team.

At V1, our most critical screen display is our continuous integration server display of build status, but there are other views: recent changes, the story board, our project dashboard, etc. that are handy to keep in plain view.

To this end, I’ve crafted a JetPack for Firefox called “Kiosk Tab Rotator”. Jetpack is the latest way to extend Firefox, from Mozilla Labs, and is a lot easier and more secure than traditional extension development.

Get JetPack and the Tab Rotator.

How/Why/Should you “Refactor User Experience”

andy — Tue, 30 Jun 2009 13:24:43 +0000

The UPA Conference was great — it was especially useful to see the wide range of experiences from the UX trade with agile methods. The diversity of scenarios is tremendous.

I originally considered submitting the topic of this post, refactoring UX, to the Agile 2009 conference, but decided that the notions I was working with were too far away from the strict definition. Refactoring code is producing identical results with better structure. The general notion I’m presenting here is that there are similar methods around UI design and flow that can achieve strong gains in user satisfaction and an improved platform for new features.

The workshop attendees responded to this notion and we talked about it for a while, producing the notes below:

The notes were crafted during a dialogue around the notion of “Justifying UI Refactoring to the Agile Team” although we agreed that we probably shouldn’t actually use the term refactoring. In an ideal scenario, UI reworking at large scale [Edit] would not be required, so premise #1:

1) Avoid it
* Vision - think ahead
* Expection setting
* Delay decisions to last responsible moment
* Parallel tracks

There can be a lot of user impact if you do need to change existing functionality. One approach to this is making gradual iterative changes towards the new design. This is both more user friendly and more aligned with the agile way.

2) Hinting
* Gradual changes based on vision
* Inconsistency between releases is ok
** Focus on UX at release level
* Get big design work done first, widgets later

And alternative to hinting, is a simultaneous beta or preview:
2a) Ship multiple versions to get feedback

Finally, if you have to make a big change, make it so obvious that there’s little chance of pro-active interference between the new UI and the old. We called this “Hitting the reset button” and it requires that the team consider UI as a feature and address it the normal flow of stories.

The dialogue was a productive initial socialization of the concepts and I firmly believe that there’s more for the UX discipline to contribute to how user experiences are best grown while being used.

Thanks to Thomas Lissajoux for some out-of-band dialogues on this topic and to the workshop participants. The UPA conference proceedings are due out shortly and should provide good fodder for more recounting.

Agile at UPA 2009

andy — Thu, 04 Jun 2009 16:22:30 +0000

I’m looking forward to attending the Usability Professional’s Association (UPA) conference next week. There’s a slew of agile focused events.

I’m participating in the Best Practices of UCD in AgileWorkshop on Monday, organized by Cindy Lu, Lynn Miller (DBLP, ‘05 podcast), and Thyra Rauch (I-D).

Here’s an excerpt from my position paper for the workshop on the critical issues of UX and Agile.

Three of the four founding premises of agile “Working software over comprehensive documentation”, “Customer collaboration over contract negotiation”, “Responding to change over following a plan” are, in principle, strong foundations on which to create highly usable software products. The drive to reach working, testable software enables rapid feedback. The focus on involving the customer plays to UX methodologies and a willingness to respond to change recognizes that even the best intuition is often not capable of producing the value of a few iterations.

On the other hand of the coin, the focus on individuals and interactions over processes and tools and openness to change presents huge challenges to the UX practitioner. The uncertainty of the actual features that will be accomplished and the inclination to avoid big upfront design favors immersion in the team room to the detriment of off-site research.

And another from my wisdom on how to deal with the challenges:

A mix of upfront design work at varying levels of fidelity, real time collaboration, and roadmap aligned user research is the approach that has worked for me. Additionally, making maximum use of the data streams already available, like support requests and web analytics, can help reduce the cost of applying actual user data to product planning and UI execution. Opportunistic re-use of customer engagements at conferences for usability testing is another way to maximize time out of the team room.

Of course, I also harp on striking the word “deliverables” from the UX vocabulary.

On the main agenda, we’ve got:

Wed: Coherent Agile User-Centered Design. From Desiree Sy (Autodesk, I-D profile)

“Building on previous talks describing successful adaptations of formative usability testing, contextual inquiry, and iterative prototyping for Agile, this talk delves further, describing a framework for creating multi-sprint designs and getting them implemented without violating the Agile taboo against “big design.”
Wed: Agile Success: A User Experience Case Study. From Melissa Federof (DBLP), Catherine Courage (Salesforce profile, DBLP, I-D), Craig Villamor (I-D, Twitter).
Wed: When User Experience (UX) met Agile: A case study. From Kuldeep Kelkar, Soojin Jeong, Michael Budwig (PayPal).

We hope that others can avoid the common pitfalls that we faced in our initial adjustment to agile and scrum.
Thu: Iterate, Scale and Simplify: Techniques for adapting user experience methods for Agile teams. From Carissa Demetris.

“How can the User Experience team keep up in this fast-paced, iterative world? “
Thu: Traits of Successful Agile UX Designers. From Lynn Miller.
Fri: Agile User Experience: Strategy and Design Research above and beyond Sprint 0. From Nancy Frishberg (I-D, SlideShare), Thomas Lissajoux (Systemes Agiles blog), Colleen Page (DBLP), Leo Frishberg (I-D).

“What strategies are successful in sustaining a healthy process for both UX and development?”

Keep an eye on this blog and the uxagile twitter stream next week for notes from the experience.

Are Personas & Prototyping Agile?

andy — Mon, 18 May 2009 17:13:50 +0000

Jurgen Appelo in the .nl has conducted a survey on agile practices. 341 people responded, solicited via Jurgen’s blog and twitter. Read more at blog posts 1, 2, & 3. Participants were asked about the agility of different software development practices as well as their importance and degree of application.

At VersionOne, we do a regular survey on agile practices, with a focus on outcomes. Jurgen’s work is interesting in that he inquired about some user-centered design practices. Here’s an excerpt from the nifty info-mixer tool.

I’ve excerpted key measures from the requirements and design sections.

The Big Agile Practices Survey (www.noop.nl)		AGILE		IMPORTANT	APPLIED	AGILE vs. IMPORTANT vs. APPLIED
Area	Practice	level of agility	agreement on agility	confidence in agility	level of importance	agreement on importance	confidence in importance	level of appliance	agreement on appliance	confidence in appliance	agile vs. important	agile vs. applied	important vs. applied
Construction	Configuration Management	25.2%	49.7%	73.9%	81.2%	62.4%	74.9%	67.9%	35.8%	82.9%	22.0%	28.6%	43.3%
Construction	Issue Tracking / Bug Tracking	27.4%	45.2%	84.4%	77.4%	54.9%	82.4%	79.8%	59.6%	89.4%	25.0%	23.8%	51.2%
Requirements	Use Cases	28.2%	43.6%	76.0%	52.2%	4.3%	61.3%	36.2%	27.7%	79.5%	38.0%	46.0%	42.0%
Process	Risk Management	29.5%	41.0%	75.1%	84.7%	69.5%	70.8%	57.3%	14.7%	81.1%	22.4%	36.1%	36.3%
Design	Design by Contract	32.2%	35.7%	67.1%	52.9%	5.9%	55.9%	25.3%	49.4%	74.2%	39.6%	53.4%	36.2%
Construction	Software Metrics / Code Metrics & Analysis	32.5%	35.1%	77.4%	57.1%	14.3%	73.9%	49.4%	1.2%	82.4%	37.7%	41.5%	46.1%
Requirements	Usage Scenarios	37.9%	24.2%	61.9%	60.8%	21.6%	56.9%	30.3%	39.4%	74.5%	38.5%	53.8%	34.7%
Construction	Code Reviews / Peer Reviews	42.3%	15.5%	84.4%	76.4%	52.7%	82.9%	59.1%	18.1%	85.9%	32.9%	41.6%	41.4%
Organization	Move People Around	42.6%	14.8%	67.8%	53.4%	6.8%	57.2%	40.8%	18.5%	72.2%	44.6%	50.9%	43.7%
Process	Root Cause Analysis / 5 Whys	42.6%	14.8%	62.2%	84.1%	68.2%	57.8%	46.0%	8.0%	74.1%	29.2%	48.3%	30.9%
Testing	System Testing	46.6%	6.9%	73.2%	93.9%	87.8%	73.2%	83.1%	66.2%	79.3%	26.3%	31.7%	44.6%
Requirements	Personas	47.3%	5.4%	59.5%	56.0%	12.0%	51.3%	32.6%	34.7%	71.0%	45.6%	57.3%	38.3%
Construction	Source Control / Version Control	48.0%	4.1%	85.9%	100.0%	100.0%	88.9%	100.0%	100.0%	91.0%	24.0%	24.0%	50.0%
Construction	Coding Style / Coding Guidelines / Coding Standard	49.0%	1.9%	78.9%	89.0%	77.9%	81.9%	86.6%	73.2%	82.4%	30.0%	31.2%	48.8%
Design	User Interface Prototyping	49.4%	1.1%	81.7%	85.8%	71.6%	76.1%	66.1%	32.2%	84.5%	31.8%	41.7%	40.2%
Testing	Integration Testing	53.4%	6.8%	81.6%	92.7%	85.3%	83.8%	88.2%	76.4%	89.9%	30.4%	32.6%	47.8%
Design	Domain Driven Design	53.9%	7.9%	71.4%	79.2%	58.5%	61.0%	46.4%	7.1%	78.9%	37.4%	53.8%	33.6%
Testing	Smoke Testing / Build Verification Test	54.5%	9.0%	74.9%	92.9%	85.8%	78.8%	78.6%	57.1%	86.0%	30.8%	38.0%	42.8%
Testing	Exploratory Testing	55.6%	11.3%	69.3%	86.3%	72.6%	65.4%	62.6%	25.2%	77.7%	34.7%	46.5%	38.1%
Process	Lead Time / Cycle Time	58.2%	16.5%	49.2%	70.9%	41.9%	46.5%	29.4%	41.2%	64.3%	43.7%	64.4%	29.2%
Process	Value Stream Mapping	60.4%	20.8%	54.6%	64.8%	29.5%	47.6%	24.2%	51.6%	67.0%	47.8%	68.1%	29.7%
Design	CRC Cards	63.0%	26.1%	64.8%	40.7%	18.6%	55.4%	22.8%	54.3%	76.1%	61.2%	70.1%	41.1%
Requirements	Product Vision / Vision Statement	69.0%	38.0%	71.8%	89.9%	79.8%	75.7%	58.3%	16.5%	81.5%	39.5%	55.4%	34.2%
Process	Kanban Board	70.5%	41.0%	65.9%	52.1%	4.2%	51.9%	20.9%	58.3%	75.1%	59.2%	74.8%	34.4%
Requirements	Minimum Marketable Features	71.1%	42.2%	73.0%	78.9%	57.9%	61.3%	40.7%	18.6%	77.1%	46.1%	65.2%	30.9%
Design	System Metaphor	73.6%	47.3%	60.6%	38.1%	23.9%	53.1%	19.0%	61.9%	69.0%	67.8%	77.3%	40.5%
Organization	Generalizing Specialists	74.8%	49.6%	70.6%	83.5%	66.9%	67.2%	64.5%	29.0%	76.7%	45.7%	55.2%	40.5%
Testing	Unit Testing	76.1%	52.3%	86.6%	98.2%	96.4%	92.2%	93.4%	86.7%	92.7%	39.0%	41.4%	47.6%
Requirements	Defer Decisions / Real Options	76.6%	53.2%	65.1%	89.9%	79.8%	58.1%	64.2%	28.4%	68.0%	43.3%	56.2%	37.2%
Organization	Small Team	77.5%	55.0%	88.9%	91.8%	83.6%	81.1%	85.0%	70.0%	88.9%	42.9%	46.3%	46.6%
Construction	Behavior Driven Development	78.0%	56.1%	66.3%	65.5%	31.0%	58.3%	35.1%	29.8%	75.9%	56.3%	71.5%	34.8%
Testing	Test Automation	78.6%	57.1%	86.0%	96.3%	92.5%	89.4%	85.4%	70.7%	91.6%	41.2%	46.6%	44.6%
Process	Release Planning	78.8%	57.6%	89.2%	95.5%	91.0%	83.8%	81.1%	62.1%	91.4%	41.7%	48.9%	42.8%
Requirements	Requirement Prioritization	82.4%	64.7%	84.8%	98.2%	96.5%	82.7%	94.4%	88.7%	83.3%	42.1%	44.0%	48.1%
Process	Limited Work in Progress / Fixed Batch Size	83.6%	67.1%	75.7%	83.8%	67.7%	70.3%	65.3%	30.6%	79.5%	49.9%	59.1%	40.7%
Construction	Refactoring	86.1%	72.3%	86.9%	98.9%	97.8%	89.4%	91.8%	83.5%	91.5%	43.6%	47.2%	46.4%
Organization	Cross-Functional Team	86.1%	72.2%	87.8%	94.4%	88.8%	79.4%	81.9%	63.8%	88.9%	45.8%	52.1%	43.7%
Testing	Storytesting / Acceptance Criteria / Acceptance Testing	86.1%	72.2%	84.4%	98.1%	96.1%	86.6%	78.7%	57.3%	91.6%	44.0%	53.7%	40.3%
Construction	Daily Builds / Automated Builds / Ten-Minute Builds	86.6%	73.2%	89.9%	97.8%	95.5%	89.9%	90.3%	80.5%	93.0%	44.4%	48.2%	46.3%
Organization	Colocated Team / Sitting Together / Common Workspace	87.7%	75.3%	90.0%	91.9%	83.9%	82.8%	77.8%	55.7%	92.8%	47.9%	54.9%	42.9%
Design	Architectural Spikes / Spike Solutions	89.0%	77.9%	80.8%	91.2%	82.4%	74.6%	77.7%	55.4%	86.4%	48.9%	55.6%	43.3%
Process	Big Visible Charts / Information Radiators	89.2%	78.4%	80.0%	89.9%	79.9%	75.1%	70.5%	41.0%	84.3%	49.6%	59.3%	40.3%
Organization	Scrum of Scrums	90.1%	80.2%	72.8%	64.2%	28.3%	58.9%	38.6%	22.9%	77.8%	63.0%	75.8%	37.2%
Process	Task Board	90.9%	81.8%	83.2%	84.2%	68.3%	75.1%	76.6%	53.2%	85.4%	53.4%	57.2%	46.2%
Construction	Test Driven Development	91.2%	82.4%	91.5%	93.7%	87.4%	87.4%	71.4%	42.7%	93.0%	48.8%	59.9%	38.8%
Organization	Sustainable Pace	91.4%	82.9%	84.4%	98.6%	97.3%	81.1%	76.7%	53.3%	83.3%	46.4%	57.4%	39.0%
Construction	Collective Code Ownership	91.5%	82.9%	82.4%	95.2%	90.5%	84.4%	85.3%	70.6%	85.4%	48.1%	53.1%	45.0%
Process	Retrospective / Reflection Workshop	91.7%	83.4%	84.9%	98.0%	96.1%	82.2%	84.7%	69.3%	88.1%	46.8%	53.5%	43.3%
Construction	Continuous Integration	92.0%	84.1%	88.4%	96.7%	93.4%	91.5%	86.5%	73.0%	93.0%	47.7%	52.8%	44.9%
Construction	Pair - Programming / Pairing	92.1%	84.3%	89.4%	75.2%	50.3%	76.9%	52.2%	4.5%	89.4%	58.5%	69.9%	38.5%
Design	Emergent Design / Evolutionary Design	92.5%	85.1%	81.7%	90.9%	81.7%	77.0%	77.7%	55.3%	84.0%	50.8%	57.4%	43.4%
Process	Definition of Done / Done Done	93.3%	86.6%	80.5%	99.4%	98.7%	83.2%	83.2%	66.5%	83.8%	47.0%	55.0%	41.9%
Requirements	Planning Poker	93.4%	86.8%	84.5%	71.7%	43.3%	68.3%	72.2%	44.4%	83.3%	60.9%	60.6%	50.3%
Organization	On-Site Customer / Product Owner	95.1%	90.1%	90.0%	94.7%	89.5%	84.4%	66.0%	32.1%	90.0%	50.2%	64.5%	35.7%
Process	Burn Down Charts / Burn Up Charts	95.1%	90.2%	88.1%	83.1%	66.2%	80.0%	80.0%	60.0%	89.2%	56.0%	57.5%	48.4%
Construction	Frequent Delivery / Frequent Releases	95.6%	91.3%	92.0%	98.3%	96.6%	89.9%	83.3%	66.7%	90.5%	48.7%	56.1%	42.5%
Requirements	Product Backlog	95.6%	91.3%	87.4%	98.2%	96.5%	83.0%	93.2%	86.3%	85.9%	48.7%	51.2%	47.5%
Requirements	User Stories / Executable Requirements	95.6%	91.2%	86.8%	95.3%	90.6%	80.9%	83.0%	66.1%	84.8%	50.2%	56.3%	43.9%
Process	Timeboxing / Fixed Sprints / Fixed Iteration Length	96.0%	92.0%	94.1%	92.5%	85.0%	86.5%	90.8%	81.5%	93.5%	51.7%	52.6%	49.1%
Organization	Scrum Master	96.3%	92.7%	91.1%	81.4%	62.8%	80.6%	80.5%	61.0%	88.3%	57.5%	57.9%	49.6%
Process	Sprint Review / Iteration Demo	96.3%	92.6%	88.1%	96.1%	92.2%	83.2%	84.9%	69.9%	89.7%	50.1%	55.7%	44.4%
Process	Story Points	96.9%	93.7%	85.9%	79.0%	58.0%	77.3%	73.7%	47.3%	90.3%	58.9%	61.6%	47.3%
Organization	Self - Organizing Team / Scrum Team	97.5%	94.9%	87.8%	94.0%	88.0%	83.3%	79.1%	58.3%	90.6%	51.7%	59.2%	42.6%
Process	Daily Stand-up Meeting / Daily Scrum	97.6%	95.3%	91.4%	95.6%	91.2%	85.9%	90.8%	81.6%	94.1%	51.0%	53.4%	47.6%
Process	Sprint Backlog	98.1%	96.2%	85.9%	90.6%	81.2%	80.5%	87.0%	74.1%	87.6%	53.8%	55.5%	48.2%
Process	Velocity	98.1%	96.3%	87.6%	87.9%	75.8%	80.5%	78.2%	56.4%	89.2%	55.1%	60.0%	45.1%
Process	Iteration Planning / Planning Game / Sprint Planning	98.8%	97.7%	93.0%	95.1%	90.2%	88.1%	92.9%	85.8%	91.4%	51.9%	53.0%	48.9%

Walking through the results, I’ll start with use cases - strongly rejected by the survey participants. In the most extensive form, these are clearly not agile but I do appreciate aspects of the use case model. Primary and secondary actions and rigorous specification of the user audience are important drivers of a good design. These are also captured in usage scenarios which gets at least a sprinkling of support. Agilists are presumably focused on revealing these aspects through iterative design and the conversation that happens while building a system as well as in product management dialogues.

I was suprised to see how contentious personas and user inteface prototyping turned out to be. The 1% and 5% agreement for these factors shows an almost even split among respondents about the agility of these practices. Personas can be challenging to do well and are buttressed upon solid user research, something often missing from agile endeavors. On the other hand, user interface prototyping is almost guaranteed to produce a better end result assuming the prototype is regarded as a starting point for dialogue rather than absolute design directive.

I’ll be talking this over with fellow UX specialists at the Usability Professional’s Association 2009 Workshop on Best Practices of UCD in Agile. We’re working to make personas productive at VersionOne, but prototyping is core technique practiced continuously to good affect.

On the other hand, I’ll never push the use case model after the response I got from the rest of the product ownership team the first time I mentioned the word at V1!

Creating a Web App with jQuery UI

andy — Fri, 01 May 2009 18:56:47 +0000

Quiet times in blog land as we’ve been busy in green field development with a new feedback platform for the V1 product line. I’ve been writing more code than normal and was greatly facilitated by using jQuery and jQueryUI.

Using jQueryUI’s inline modal, we support a seamless transition from non-logged-in state to logged-in even in the midst of write operations. For instance, you can, as an un-registered user, click to vote on an idea and then register, confirm, and return to the original window to commit your vote. This is an experience that a lot of sites get wrong… try favoriting on slideshare w/o being logged in, FAIL.

We’re using lots of base jQuery ajax functions as well as jQueryUI dialog, buttons, and skin elements.

The button system is pretty slick, supporting a number of states: primary, secondary, disabled, active, hover. This blog post is actually a better reference than the official docs.

jQueryUI’s theming system, called ThemeRoller allows configuration of the colors, corners, patterns, etc as well as generating several versions of standard icon canvases for a variety of options in icon coloring. Be sure to save the permalink for your themeroller config!

On the pure jQuery side, we appreciated Live Event Listeners which attach not just to the current DOM, but for all DOM that’s created — simplifying the process of adding interactive elements with script.

With a browser matrix including IE6 to Firefox and Webkit, jQuery was indispensable. We did design our IE6 support to be jettisonable in some hopeful future, accepting some visual downgrades and separating out exception rules for IE6 issues to a separate style sheet.

Nate Koechly at Yahoo describes extensively the challenges of modern UI engineering. Thanks to the jQuery folks for the getting us to a level where we could aim for superior experience. Hat tip to the Apache Lucene project, and specifically Lucene.net, for capable full text search.

Spoolcast on Beyond Deliverables / Prototyping

andy — Sat, 21 Mar 2009 11:57:10 +0000

These days, there isn’t a more accomplished user experience consultancy than User Interface Engineer. It’s lead, Jared Spool, does a great podcast series called the Spoolcast.

A recent podcast with James Box and Richard Rutter visits some of the notions I expressed in the post “UX Design Artifacts: Conversation Anchors not Deliverables“. The interviewee’s do mention agile eventually and it’s a likely contributor to their rejection of throw it over the wall design work.

But the essence of their point is less dogmatic. Particularly for highly interactive experiences, realizing the critical functionality so that it can be experienced across time makes tangible aspects which are very hard to predict reliably. I’m just through a situation where we didn’t do a strong prototype of a very ajaxy experience and, thankfully, my intuition and design sense seem to have pulled it off this time. In another, more incubative effort, I’m going waaay far down the prototyping stage to really discover the value proposition and interaction sublteties.

Go get the Spoolcast in your iTunes… Jared’s got a wicked sense of humor in addition to boot!

The Generalizing (User Experience) Specialist

andy — Thu, 12 Mar 2009 16:56:46 +0000

Agile brings a focus on the team as a unit and a lack of willingness to block, or plan for dependencies, around specialists. The term “generalizing specialists” describes the goal for agile team members to become less diversified in the key skills of producing quality software.

A recent heated thread on the Agile-Usability discussion list resulted in the suggestion that UX specialists work to increase the development team’s acumen in user experience design. While limited, this is something that is typically useful for a UX practicioner in any type of team.

I’ve had success using Jakob Nielsen’s usability heuristics as concise guidelines that help design dialogues and can seep into the skulls of coders. Here’s a slight re-casting of the wording for this purpose:

Keep the user informed of system status
Match the real world
Keep the user in control
Be consistent internally & externally
Prevent user error
Enable recognition, don’t require recall
Provide shortcuts for flexibility and efficiency
Keep the design minimal
Enable recovery from error (barring #5)
Provide help

While splitting specialists across development teams is an anti-pattern in Agile, it’s also the case that solid UX work involves time outside the team room. By frequently referencing these principles in design processes, teams I’ve worked with have learned to avoid the situation where I return and request rework for #9, #9, #9…

So paste that top 10 list into your favorite word processor and print it for your team wall.

UX Design Artifacts: Conversation Anchors not Deliverables

andy — Fri, 16 Jan 2009 15:59:19 +0000

The focus of the user experience profession, and notably the information architecture and interaction design specialties, on deliverables is a key source of conflict with agile methodologies. The agile principle of “the last responsible moment” (more) for decisions result in one of the most common dialogues about UX in agile being agilists rejecting the “throw it over the wall” notion inherent in the word “deliverables”. Contrastingly, in waterfall development the quality and depth of the design artifacts, typically implemented in pixels, are essential to overall success.

Traditional design deliverables like wireframes, site maps, and interaction flows are highly useful in agile and a great venue for a UX professional to apply their expertise. Yet, they serve the conversation not the traditional specification role.

Design artifacts contribute early on by helping:

Unpack user stories, revealing corner cases
Make consistency issues with the new story and existing technology more apparent
Communicate the story to developers and improve estimation
Expose user experience goals (and non-goals) to both product owners and developers

Further down the process, design artifacts can serve as models for design and reference points to discuss trade-offs across alternatives. In my experience ramping up VersionOne, as often as not, my designs do not end up being the exact experience we ship due to implementation costs or other collaborative revisions.

Style Guide Primer for Agile Teams

andy — Fri, 12 Dec 2008 19:35:22 +0000

There’s been a remarkable amount of dialogue lately on user experience design and agile recently. I’ve struggled to do the dialogue justice, but in the meantime I’ve taken one of the key points to heart: we should be focused on adapting traditional methods to a more agile cycle. To that end, here’s a missive both for the agile community and specifically my co-workers.

Style Guide Benefits

Developing a style guide can be highly useful practice in iterative development. Successful integration of a style guide into your development methodology has both end-user and team benefits.

User Outcomes	Team Outcomes
Increased learnability Increased memorability Increased overall user efficiency Opportunity for improved aesthetics and user satisfaction	Visibility beyond the current story (e.g. avoid story blinders) Reduced ambiguity in everyday user interface design Flexibility for UI design work with the option to lead or follow core implementation and still have a strong impact Promotes smart code re-use & refactoring

Examples

Copy Oriented

Know Your UX Acronyms:

ED :: experience design
IA :: information architecture
ID :: interaction design …
ROI :: return on investment
UI :: user interface
UX :: user experience

(via B&A)

The boxes and arrows house style guide is a sort of Funk & Wagnall’s / Manual of Style and describes the typographic style, tone, and even common abbreviations.

Beyond text, however, style guides should reach into interaction design: layout, spacing, visual design, and grouping constructs that are common across the application.

For Operating Systems: Human Interface Guidelines (HIG)

Thought on Test Driven Development
Readers who check out the MSFT Vista HIG might have noted the similarity of some of the criteria expressed on specific elements to the tests one might write to insure a interface is ready to be deemed “working software”. Style guides can promote re-use of this criteria development work across implementations, essentially providing a base set for inheritance by custom types. As you would expect, violating these expectations while re-using the visual and interaction styles is a red flag for a potential user experience issue.

At the most grandiose scale, a style guide can grow into a HIG. The early deployment of a HIG in Apple’s inital MacOS days was likely a key driver of Apple’s initial usability advantages over Windows. Despite the degree to which early Microsoft and Apple shared similar window, icon, menu, and pointer (WIMP) conventions, apple had a “Human Interface Guidelines” (HIG). This led to easier transfer of learning from one application to another for Apple users.

Microsoft has long caught up with extensive guidelines. Subtle aspects like making the labels of radio button and checkboxes clickable shape the way user’s expect the web to work.

Here’s an example from the Vista HIG expressing the Progressive Disclosure pattern and providing common graphical treatments to craft the affordance.

from the Vista Human Interface Guidelines

Web Application Style Guides

One of the best examples of a web application style guide, garnered from web search and the IXDA archives, is 2004 Oracle Browser Look and Feel (BLAF) Guidelines. The B&A communication style is included, but the BLAF also incorporates visual & page design as well as common interaction design concerns. This is split into sections for:

Overarching concerns: color palette, mental model for save, and typographical conventions at the CSS level
Components: Page elements or widgets and accompanying styles, ex. date picker & table styles.
Templates: Page templates and complex components like messaging and search UIs
Flow: Conventions around multi-step process design approaching a pattern library but including application specific conventions, example: Step by Step flows

This example spans Information Architecture concerns with guidance for information about navigation and current locations along with basic page wireframes. A key objective for this aspect of a style guide is to establish common names for the locations & widgetry. This provides an opportunity to make calls on where user and developer speak need to diverge. Much of the challenge of designing an effective user mental model can be accomplished by smart decisions in mapping internal to external terminology, but user mental models are truly a separate domain of UX work.

Further evolutions from a specific page flow wireframe yield page design elements to define common grouping, alignment, and chunking methods ideally down to the precise CSS implementation. On the interaction design side, the BLAF covers pattern implementations for master-detail views along with more local elements like pagination.

Agile Iteration and the Style Guide

While building a document of this complexity upfront is decidely un-agile, codifying conventions as they develop insures a top notch user experience, facilitates efficient implementation, and provides the key design criteria when it comes time to do UI refactoring. In some cases, doing some of this work upfront to generally shape an Epic or first release can help insure that UIs gel across story implementations.

At a bare minimum, looking for emerging UI conventions as initial work plays out and codifying them, if only in code, is critical to insuring incremental doesn’t mean inconsistent. As an application develops, the leader vs follower status of the style guide can vary.

Web Innovation, AJAX, and Patterns

As a UX specialist that does more web applications than anything else, it’s very exciting to see the interface design creativity of the commons and worldwide uptake of the web. Interactions on the web are not subject to the limitations (or supported by the bootstraps) of Windows Forms or the SWING UI toolkit. This has lead to a wider range of experimentation, subject to some notable but decreasing technical limitations.

It’s pretty easy to commit cardinal sins in web user interfaces, like using custom Flash scrollbars. Adherence to the core Microsoft HIG is the base level of concern, as that interaction has shaped the greatest number of users. Popular web-sites augment the user learning from the operating system (and often exceed it). Deviating from a conventions established by the combination of the OS and popular websites should be done with care and precision.

The YPatterns library, AjaxPatterns.org, and Tidwell’s interaction patterns all provide some guidance on established practice for deploying modern client side technology to user interface challenges. For a more visual experience, check out Messina’s Flickr design pattern collection.

Starting from patterns can help bootstrap your adoption of style guides, guide your architecture to useful levels of UI granularity, and provide a clear workflow — from pattern to lower level interaction and visual design.