It’s often a topic sits in the mind long enough to become something to write about. This is again one of those times. Conversations reigniting agile (the project management methodology) have often found itself in direct opposition to UX (governance, research, etc) once again. And this isn’t wrong. The two don’t get along in part due to a misappropriation of what agility means. If we see “agility” in a context apart from “Agile Management”, we might be better able to understand why some design-focused folks seem to run their own path. But, also why there’s hope to get many of us on one accord - embracing a perception of the experience and expectations of the consumed thing such that we communicate a clear and necessary message.

On Design and Agility

Design is communication. An effort to remove unwanted friction in the hopes of allowing some valuable quantity to come thru for someone’s benefit. Bad design is easily recognized as such because it adds friction - physically, mentally, financially, psychologically, etc. Good design doesn’t even seem like it’s good because done too well, it speaks to subconscious perceptions more than conscious awareness. Good design considers what it amplifies, and seems to also have ripples indirectly benefiting other parts. Design communicates. And what it communicates is regarded as “experience.”

Agility can be a sign of good design. For process and product development teams, good design speaks to value for several parties:

• for the team there’s clarity of task and purpose
• for the team there’s ease to communicating with one another and key stakeholders
• for stakeholders agility reduces the burden of risk
• for the developed product or process, agility might also offer a lens of understanding that not every context could be delivered, but was hopefully considered

Establishing agility within an organization often starts with developing some kind of shared language, and then turning that shared language into a vision. The vision captures the capabilities of the team on their best days, and the realization of some kind of goal by the consumer and/or stakeholder. This vision, when committed to, empowers a type of doctrine or discipline towards that end state. Agreement to each step taken to get there strengthens this relationship to agility. While disagreements don’t necessarily mean you won’t get there, maturity in agility allows disagreements to focus doctrines and disciplines, often building on top of the shared language.

Spoken like this, an “agile” approach within software development teams might sound like it spurs the best ways forward. However, it often doesn’t. Don’t get me wrong, delivery happens. However, agility is a bit harder to come by. If it were a matter of just building stuff, then maybe yea. But, we often find ourselves looking at the experience of delivered products not from a “delivery” perspective, but from the “experiential” one.

On Experience and Expectations

User experience (UX) is a practice which enables teams to realize their adherence to the expectations of those consuming or using a product or service. This practice also gives stakeholders (the business who sponsored the product, in addition to the audience assessing its risk) a means to determine and test their hypothesis and their investments versus those same expectations. Often, folks contort or confuse UX alongside its similarity-named user interface design (user interaction design or UI), but these are not the same, even if some of the expectations are shared. Or, to say these more directly.

• UI = user’s interfaces (aspects of a system/platform a person interacts with to change system state)
• UX = user’s experiences (the governance towards, and the analytics supporting, what the person using a system or platform defines as their experience as good, bad, or otherwise)

UX includes UI, but good UX doesn’t mean good UI

Practices and methods for interfaces (UI) includes what a platform is capable of, and thru its design, what it will not support. In the delivery of a product or process using this guidance, a product will behave according to expectation, and even “fall away from conscious record” while it is being used. The interface will feel intuitive. This is a part of what agile teams are able to deliver at the baseline of any product or process. Agility while building interfaces allows the team to address ways of interacting which might not have been originally part of any specification.

Analysis and guidance for experiences (UX) includes the expectations (and manipulations) of those using a platform, regardless of how it was designed. Those expectations aren’t just about interacting with the platform, but the value it creates or diminishes because of it. A system might use familiar buttons, text prompts, and layouts, but if the content is difficult to read, or information prompts happen within unexpected moments during some workflow, then the system will be regarded as having a negative experience. Much about human factors engineering has been written, tested, and validated towards patterns which lead to positive or negative experiences. Physical and non-physical factors are accounted for. Agility enables teams to pivot quickly to analyze and maybe understand the experiences, but designing affordances takes a different approach and requires more than just “throw it out there.”

Move Fast and Shape Things

Design and Agile are two different and not always complimentary methods of communicating. Both draw on individuals and teams having “agility” as a characteristic, but pull on “value” differently. When we move fast as designers, we are hopefully taking the lessons and responsibilities of what’s needed, and making clear only that which is essential. On the other hand, when we are shaping things, we are deliberately taking the posture of the audience who will experience the thing. We aren’t just considering their view as our own, but also what it means to be a conscious reminder of “something valuable.”

Now, can a team develop the agility to “shape” more than “deliver?” Yes. We think so. It’s part of the coaching and methods shared through this effort in fact. Yet, this is hard. Change doesn’t happen quickly, nor does it happen willingly. Design-focused folks need to “show, share, and (then) tell” more than they are used to. Their language has to be “what’s in it for (the stakeholders),” not just “we do this because it is the way (design is done).” Agility for design teaches an ear towards those consuming a product or service, while openly acknowledging the constraints of the product, market, stakeholder, or methods. It doesn’t tolerate all things, but vocalizes when unnecessary friction adds unwanted risk. Agility goes ahead of delivery, clearing the road for the hopeful reception of a product/process which meets or exceeds expectations.

Design has to move fast in this era. Especially when that design is software-focused. However, being “agile” shouldn’t mean bending design to the doctrines and disciplines of the methodology’s current state. It should mean being capable of communicating the value of the audience’s perspective, and shaping that which enables that perspective to be applied to the very reason the product or process exists. It means design can have agility because experience and expectations aren’t things to be shaped, but things to be learned, heard, and honored. Design’s agility, in this view, is always humane.