The UX Process & The Non-Prescriptive Agile Approach

In a previous article I detailed the process of creating and enhancing component-oriented user journeys through an UML inspired approach.

But relying solely on how to better view the design of a system is not enough in order to actually build it. In the end UML is just a tool to help us design better software by using a standardised system of technical symbols, right? So we need a process in place to build the actual thing. And nowadays, the process needed to build the system needs to be Agile.

Historically, as UML helped Rational Software back in the mid 90s it had to be used by a process framework that could help the development process.

That’s exactly what happened when IBM acquired Rational. They created the Rational Unified Process (RUP), a process framework that is adaptable and tailored to the development teams’ needs. RUP uses UML diagrams to represent the steps needed to develop a system.

IBM applied a specific implementation of the Unified Process and many companies today are still adapting the Unified Process, just by using different neologisms.The Unified Process helps companies select the elements of the process that are most appropriate for an individual project.

One particular type of implementation involves the Agile methodology. And that through the former Agile Unified Process that evolved into the Disciplined Agile Delivery. This method describes a simple, easy to understand approach to developing applications using agile techniques and concepts and it was initially created in 2012. But how easy is it to be applied in the real world?

For me, the strategy of not offering a prescriptive solution, makes Agile methods very fragile and error prone. It leaves a lot of room for interpretation, based on each individual’s Agile development experience.

Disciplined Agile Delivery opposes the idea that one framework such as SAFe (Scaled Agile) is best used for all scaling situations. And in a best case scenario I would totally agree that a framework should provide guidance to select a strategy according to different situations (ex. small vs large teams, co-located vs geographically distributed etc). But applying a process framework that not everybody is fully comfortable with and/or is experienced enough to understand the possible shortcomings, is fallible.

And when in comes to UX design and how it can be applied in an Agile world, a Scaled Agile Framework is the best option to support it’s role in the full cycle.

Why? Because through a prescriptive solution, all members of the team have the same understanding of what needs to be done and by whom.

As Agile is just a set of principles that guide software development, many people apply it in contradictory ways if they lack clear direction.

And one can imagine what happens when you extend unclear methods and apply them to a young UX design process.

There is clearly a tension between designers and development teams over the quality of the deliverables needed. UX designers need to be involved earlier in the product ideation process and create thorough task models and user journeys that would help development.

But business and development sometimes see UX as just skinning the app according to the business needs that they based their requirements on.

So this conflict of quality expectations that is enhanced by a poor prioritisation of UX in the overall development process makes UX designers be seen as just a second-class team that needs to provide pixel-perfect designs when requested.

Implementing a good UX design practice in an Agile environment should rely on fast and incremental prototyping followed by quick implementation and a clear definition of done. But fast prototyping is possible only if the designer works in a structured manner, by effectively organising design components for ease of reuse and adaptation to new features.

By organising the design assets into a living styleguide, the UX designer can work much closer to the development team to bring consistency across the application by preventing the implementation of different versions of the components than the ones specified and signed-off.

By maintaining a component library and a visual language framework, the UX team can reduce the burden on individual designers working in an Agile team. And a large repository with already tested design components is always helpful, allowing UX to focus on working alongside developers to design solutions for the current sprint’s tasks.

Otherwise, by always trying to be ahead of the current sprint, they will not be able to control the quality of the actual delivery and end up with a poor user experience although on paper it looked good.

If you liked this, click the ♥ below. Follow me and UX Design Today for more articles on UX Design & Agile practices.