UX design and Agile: an awkward interface

Agile is a hot term in the industry. So are terms like object oriented and web 2.0. And like those other terms, agileis frequently misunderstood or misused. Or it becomes a hammer in search of nails.In this article, design to refers to methods employed when creating a User eXperience, or UX. Things like concept development, interaction design and visual design. Engineeringmeans standard activities like architecture, development, testing and continuous integration – things that make up the activity of turning a UX design into a real user interface that a person can touch, or click, or swipe.I started out thinking mostly about design, engineering and process, but ended up considering the relationships between different processes and risk. Risks like running over time and over budget, or ending up with a product that doesn’t really express the key nuances of the UX design.

Getting agile

Agile methodology, fundamentally, assumes the ability to encapsulate work into small tasks – the agility comes from the high degree of granularity and the ability to reassess progress and change direction after a smallish amount of time. Agile methodology further assumes that these tasks can be prioritized. And, generally, it assumes that teams can compartmentalize the work into sprints, usually one to three weeks in duration.

In practice, tasks are extracted from user stories and sized via the use of story points, a point being an arbitrary unit, a convention that describes the ability of the team to consume work. For example, an item might be assigned the value of 10 story points, or a team may decide that they can consume 150 story points per sprint (their velocity). Once identified, the tasks are prioritized, then placed in the backlog, the queue from which new work is assigned.

An important point: an agile team pulls a sprint’s worth of work from the backlog at the beginning of a sprint – but any work arriving after a sprint has started is prioritized, placed on the backlog, and considered at the beginning of the next sprint. In short, no new work is added to a sprint once the sprint has started. This allows a team to develop accurate metrics around their ability to do the work, reduces randomization of team members, and generally preserves sanity. Risk is mitigated by the ability to assess progress in short intervals, to make course corrections quickly, and to reprioritize tasks as required.

UX design: holistic by nature

The mention of design often conjures up a process that is more fluid, more nimble, than engineering. But that fluidity can actually prevent design from lending itself to agile methods: designing a UX is essentially an holistic process, where any change in an interaction model may need to be integrated across all parts of a user story, or even the larger context of an epic, or collection of user stories. A large number of tasks may be identified within an epic – but it may not be appropriate to transfer those tasks to the engineering team until the entire epic is completely designed and frozen.  This can apply to visual design as well, where changes in branding, style or design language can have impacts across many parts of a design.

Indeed, that condition might extend to an entire collection of epics, or an entire application, or an entire suite of applications. The risk here is that assessment of progress against scope and schedule may only be possible after large amounts of work have been completed.

Keeping the loops small

While still contained within the design process, changes can be resolved within the design team. Once handed off to the engineering team, however, surfaced changes frequently need to be fed back to the design team for resolution:

The larger the loop, the more expensive the change, and the bigger the risk. And the loops are unpredictable, adding even more risk.

Waterfall as an alternative

Another development methodology, “waterfall”, requires that work items transition from one group to the next through a gate of sorts, where the implication is that the work being transferred is “cooked”, or “frozen”, or complete, essentially freezing risk as well. This process is usually seen as traditional, old school, rigid, antithetical to the freedom and flexibility of the agile method.

All that’s true.

Hybridization

At the same time, there may be places where a gated handoff is beneficial in the sense that it keeps the loops smaller.  The holistic design process would lead to a frozen body of work that is passed through a waterfall-like gate to an engineering team using agile methods: a hybrid process.

The three-legged stool

Three parameters affect a project in general: scope, schedule and budget. Fixing more than one of these increases risk dramatically, yet by far the most common case is a project where budget and schedule are fixed, while scope remains bit fuzzy when work starts. Running on a fixed timeline with a fixed budget means a defined amount of person-hours is available; if scope increases, working hours in the schedule increase outside of budget, and margin falls. In an agile environment, scope changes are usually handled in the backlog prioritization, the assumption being that if scope increases sufficiently, some lower-priority tasks may not get completed. That’s a difficult concept to communicate to a client.

There’s no such thing as a free lunch

Everything in design, and in engineering, is a matter of compromise. The hybrid process described here assumes that UX design work reaches a predetermined complete state before the engineering process begins on that part of the design. This may mean that the design for the entire project should be completed first. It means that some design resources will need to be retained during the engineering phase, as changes will inevitably be required, to preserve the UX fidelity of the final product. It means the schedule for the project will probably be longer. In practice, however, the overall timeline usually suffers more from those large, unpredictable loops called out above. And in the end, correctly sizing a project, mitigating the risk and executing within project parameters are the factors that lead to success.

The 7-inch iPad

Tim Bray is predicting a 7″ iPad. I’m skeptical. As a former Kindle user and a current iPad user, I can understand the attraction of an option between the iPhone and the iPad: personally, I’ve often wished my iPad were a bit lighter. However I’d argue that, while reducing weight and reducing size are reasonable goals, I’d rather keep the size and reduce the weight – a paperback-sized reading device serves me as a reading device, period: smaller than an iPad, there is little advantage over my iPhone when it comes to producing anything like email.
And a singly-purposed reading device isn’t enough.

Beast of Burden

As a frequent traveler, I’m always looking for solutions that reduce my carry-on weight, or the number of devices I travel with, or the ease with which I can get through airport security. I don’t think I can support the one-device model until I can get a phone-sized device that has some sort of expandable display (see Earth: The Final Conflict, or the 2005 Philips Readius prototype that went from cool roll-away to meh fold-away) – the phone in my pocket is used far too frequently, too casually, to imagine giving it up for an iPad in my pack. So the first device, the phone, is a given.

Can I get away with only two devices? For a long time I’ve lived that model, phone and laptop. Yearning for first-class room to open my laptop in the air, seeking outlets in the airports like some digital mosquito, accepting that I’m going to run out of power on long flights (DigEPlayer, anyone?) In transit, the iPad has generally solved those problems, and the laptop stays in my carry-on for 95% of the time on business trips. For personal trips, I’ve started leaving the laptop at home. I read on flights, manage email when appropriate, read documents, watch movies, play games. I never worry about space or battery or a separate tub in the security line. I’m down to three or even two devices. Using a 7″ device, I would likely be schlepping my iPad along for games/photo editing/newsreading/email/web browsing/other. So now I take three devices on personal trips, four devices on business trips? Not likely.

Precision-Targeted or MIRVs

As a developer, I appreciate the limited form factors targeted by iOS. I can fine-tune my app to either or both displays, and realize maximum quality of user experience. Granted, a Retina-displayed iPad may throw a resolution curve into the mix, but I can deal with that just as I adapted to the iPhone 4. But supporting essentially two devices is viscerally different from three, or more. The cost, time/effort-wise, of addressing 3+ devices means I’ll start considering ways to cut corners: compromises in the UX, common elements that are “good enough”. I encounter the issues, and compromises, faced by web developers and browser/display compatibility. I run across the fragmentation issues faced by the Android community (the same issues faced, and never really addressed, by the Java community more than 10 years ago). While I think WebKit is an excellent tool under the right circumstances, it is not a universal hammer, but I’m starting to see it being proposed often as such, to mitigate platform porting and time to market. In those cases the UX almost invariably ends up being prioritized below production efficiency.

And therein lies the rub: is the experience more important, or is the ease/speed with which I can develop/market an app? If I have to compromise on the experience to get a paperback-sized device, will I love what I will, ultimately, see as a user? And the target for UX should be users loving the experience, something about which Apple has been pretty clear.

I’ll Take Light

Just to make things interesting: rumors of a thinner, lighter iPad.