Agile + UX: How to Make Friends a Quality User Interface and Agile Methodologies

The problem of creating a high-quality user interface ( UX-interface ) really exists. Specifically, it manifests itself when the development company uses flexible methodologies. Actually, the reason for this is a combination of two points:

• Iterative work of programmers. At Agile, developers prefer to create a project "in parts", in separate iterations. And in the same way "transfer" the resulting product to the customer.
• "Integrity" of the work of designers. UX designers prefer to think through and develop the whole concept. Accordingly, according to the readiness of the whole concept, they transfer it to the development. This approach forces designers to break out of the general rhythm, which causes problems with the distribution of working time.

Two ways are outlined: to leave designers alone or to try to involve them in Agile (besides trying not to cripple anyone). In the first case, you have to sacrifice the pace, in the second - the quality of the final product. Or is there a third way?

First, the big red car example

The initiator of the workflow is always the customer (in flexible methodologies, his name is Product Owner). It is he who flies to you and fervently talks about his ideas. Usually, in order to protect direct performers from such a "flight of pure fantasy", the analyst gets in his way. He reassures the enthusiast, they sit together for the specification and after a while give birth to the document. Which clearly, clearly and without unnecessary expression lists the requirements for the final product, by points.

If it’s very simplified, then the vision of the product at this stage is:



So far, everything is going according to plan. Requirements are transferred to the designer (interface designer), he gets acquainted with the specification and develops a layout. Compared with the original idea, it turns out even better - useful functions are added, the interface becomes more convenient (the designer attracts user experience, the same UX, user experience).

It turns out even better:



Now that the project has found specific features, it goes to the developers. And we see it in a completely different way:



A bunch of spare parts from which you need to build a project and, again, ship the product in parts to the customer. After all, we have scrum, iteration, sprints with demonstrations, right? Well, yes, we are so used to it.

But the end user is not particularly happy with this “iteration”: for him, the project that he is given into his hands after the first iteration of development is a “car without wheels”.

The customer, as the initiator of this big red car, is also embarrassed to show the unprepared (from his point of view) product to consumers.

And if the management by order of time tells the designer that he will develop the interface “in parts”, then the designer will not understand you at all. And rightly so.

The main problem is that the customer, designer and developer have a different vision of how the final result should look.

Agile + UX: Combining Interface Integrity, Iterative Development, and Market Validation of an Interface

Have you heard anything about Garrett’s Pie? Jesse James Garrett , a UX designer, divided user experience and user experience into several levels. The interaction takes place at the levels of strategy, requirements, structure, layout and coloring:



Conditional division into levels (from the basics to the details):

The strategy level  is just that part of the project when the customer comes to you with an idea.
The level of features  - when the functionality of specific elements of a project is invented.
Structure level  - when the hierarchy of the interface is thought out.
Layout level  - when the arrangement of specific elements is considered.
Coloring level  - when elements are visually drawn.
Implementation level  - when the interface goes into development.

For the strategy and features, we are responsible for the analytics, for the structure, layout and coloring - the designers, for the implementation - the developers. Everyone makes a product that goes one level higher, and from there - even higher.

It all starts with strategy (here the largest number of abstractions and assumptions). The higher we move up the “pie”, the more specifics are added to the project, and the more expensive any changes are.

And if the first demonstration to the customer occurs after the implementation level (as is done in the waterfall model), then the customer can say: “Guys! You did absolutely not what I wanted. ”

And you have to redo everything -since the top level has been reached. That is, analysts will connect again, then designers, then developers.

Therefore, the very demonstration of a “car without wheels” is, in fact, necessary for the customer to complain about the product as early as possible. Ultimately, it will cost him less.

That is, iteration is good at any of the levels. Now about how to build a "flexible design process."

Development and design ... in two streams?

When the project goes into development, we have difficulty:

What to do to specialists who were engaged in previous levels (analysts and designers)?

First, we organize the work of developers and everyone else (designers, analysts) in two parallel flows.

Everything is preceded by project planning (by analysts), followed by “Zero Iteration”, during which a general concept is developed (by designers), and elements are drawn for the first iteration of development. After which, during the first iteration, developers are engaged in ready-made materials from designers, and they make elements for the second iteration. Etc.

It turns out something like this:



Programmers and non-programmers (designers, analysts) will interact with each other as follows: while developers implement features of the current iteration, designers monitor whether everything implemented in the previous iteration corresponds to the concept. They also prepare design elements for the next stage.

Analysts - check whether all the features were implemented at the previous and current stages and that nothing was left out of the plan for the next. They also plan features in two stages ahead.

In this situation, this whole structure lives, develops and lives on.

There are certain subtleties with the formation of a backlog (a general list of features in Agile) and its maintenance, but there it all comes down to the same “parallelization” of it.

This is how the simplified matrix for testing the UX interface looks like (we gave the full matrix in this hub ):



As a result, we have three bold pluses:

• Designers are embroiled in agile development, while maintaining the same quality of the created interfaces.
• None of the experts is “idle” idle, even if there is only one project in the work.
• We get regular feedback from the customer and make corrections at the lower levels (it’s cheaper).

At the “zero” iteration, it is necessary to develop a model that would deliver to all participants in the process: from the customer to the designer. Both design and demonstrate it until the customer approves the layout completely. And then - confidently develop the project without deviating and not being distracted by “alterations”.