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.

Annealing design and technology

My grandfather left me his pocket watch, an 1896 Volta repeating chronograph. Under the crystal, the face and hands are exquisite – checking the time is a delightful experience. This watch has a crystal on the back as well, offering a look into the technology behind the experience, as gears turn and tiny hammers strike tiny chimes: the timepiece is both a beautiful design and an engineering marvel.
One of the things that most attracted me to frog design was the idea that, as an engineer and occasional artist, I’d be working for a design firm. I confess that I hadn’t fully formed an image of how that would work – mainly I just loved the idea, the people were incredibly smart and motivated, and they were clearly going a lot of cool directions all at once; my kind of place. Technology has become an increasing part of the process at frog, as solutions are more tightly integrated into systems, and clients want to see functional prototypes.

Technology as the naysayer

In design projects, there can be a tendency to bring technology into the mix later in the project, to validate the feasibility of the concepts being proposed. This usually means that the concepts have been refined quite a bit, and that significant resources have been allocated toward that refinement. It also means that technology is frequently placed in the position of saying things like “that’s a wonderful concept, but you won’t be able to actually do it. Sorry.” Whether web-based interactions that were simply beyond current states of the art, or visual transformations that might bring mobile hardware to its knees, or cloud-based features involving subtly convoluted security issues, there is an implied veto. And since people don’t generally appreciate their concepts being vetoed, members of the technology group might be a little less welcome on the next project, meaning that they might be invited to the table even later in the process than before.

Engineers really do love being able to say “yes, you can actually do that.”, or even proposing solutions that the design team may have assumed were out of reach, enabling the team to go big. frog embodies design, and that should be the driving force behind what we do. Form may follow function, and form may follow emotion; delight frequently follows seamless integration of form and function. This requires a stimulating, sometimes argumentative environment built with patience and trust and respect between all members of a team. I’ve had strategy people say things that I felt were completely, utterly off the mark. But they were patient with me, debated with a genuine desire to find truth, and they gave me the time I needed to realize that they were actually completely, utterly right.

“We need more ‘technology projects'”

As an innovation company that touts considerable technology prowess behind the design, leaders at frog are interested in ways of displaying that prowess. If a project is perceived as “technology-centric”, the technology group might take an increased role early on. The result may be something entirely feasible, but may not produce the desired level of UX sophistication or user delight (yes, we do use that term): technology people tend to be very clear on functionality, but may not visualize the sort of UX that grows out of the rigor our interaction analysts can bring to bear. The twin seductions of technology coolness and feasibility will influence, and may actually overwhelm, solid design. And regardless of how amazing a new feature might be, twelve clicks, six screens and three feats of mental gymnastics is asking too much of the average user.

“…and now for our next trick…”

There are teaching methodologies that suggest one should be reaching all members of a group, regardless of their preferred learning modality, and presenting to a client is a form of education. The synthesis of design and technology can unearth new possibilities when we deliver our work to the client. Some people learn visually, some by watching repeated examples, and some are kinesthetic; they need to touch and feel a concept. Dealing with technology-savvy or even technology-centric clients is similar in the sense that, in a given room, there will be some who gravitate toward a more traditional, storyboarded design approach, while some may prefer simply reading a specification in silence. The challenge lies in reaching everyone during a single presentation. Too design-focused, and we may get “it’s too conceptual for me – what do I do with this?” Too technical, and the designers in the room may perceive the presentation as mere documentation.

Indeed, when a client group tends toward the middle of that continuum between design and technology, it may be unclear whether frog is acting as a design company enhanced by technology or a technology company enhanced by design – and that’s okay: what matters is the alloy resulting from design and technology contributions: a new element. This is the area that is becoming more fascinating as we explore ways to reach all audiences, not merely supplying separate deliverables to satisfy different learning types, but by inventing new methods for reaching everyone through different aspects of a single concept.