Agile + UX: how to make friends with high-quality user interface and flexible methodologies

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

• Iterative work programmers. In 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 and develop the concept as a whole. Accordingly, according to the readiness of the whole concept - they transfer it to development. This approach makes designers stand out from the general rhythm, which causes problems with the distribution of working time.

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

First an example with a big red car.

The initiator of the workflow is always the customer (in flexible methodologies his name is Product Owner). It is he who flies in to you and talks ardently about his ideas. Usually, in order to protect direct performers from such a “flight of pure fantasy”, an analyst stands in his way. He calms the enthusiast, they sit down together for the specification and after some time give birth to the document. In which the requirements for the final product are listed clearly, clearly and without undue expression, point by point.

If it is very simplified, then the vision of the product at this stage is as follows:



As long as everything goes according to plan. Requirements are transferred to the designer (interface designer), he gets acquainted with the specification and develops the layout. If you compare with the original idea, it turns out even better - useful functions are added, the interface becomes more convenient (the designer attracts the user experience, the same UX, user experience).

It turns out even better:



Now, when the project has acquired 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, in parts to ship the product to the customer. We have scrum, iteration, sprints with demonstrations, right? Well, yes, we are so used.

But the end user is not particularly happy with this “iteration”: for him, the project that he is given in his hands after the first iterations of development is “a machine 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 manual orderly tells the designer that he will develop the interface “piece by piece”, 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: How to combine interface integrity, iterative interface development and market validation

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



Conditional leveling (from fundamentals to detail):

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

Analysts are responsible for the strategy and features, designers are for the structure, layout and coloring, developers are for implementation. Each makes a product that goes up a level, and from there it goes even higher.

It all starts with a strategy (here is 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 level of implementation (as is done in the waterfall model), the customer can say: “Guys! You did absolutely nothing what I wanted. ”

And you have to redo everything - since you have reached the top level. 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 express complaints about the product as soon as possible. In the end, it will cost him less.

That is, iteration is good on any level. 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 should be done to specialists who were engaged in previous levels (analysts and designers)?

First, we organize the work of developers and all the rest (designers, analysts) in two parallel streams.

Everything is preceded by project planning (by analysts), followed by the “Zero iteration”, during which a general concept is developed (by designers), and the elements for the first iteration of the design are drawn. After that, during the first iteration, the developers deal with the finished materials from the designers, and they make the elements for the second iteration. And so on.

It turns out about the following scheme:



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

Analysts - check whether all features were implemented at the previous and current stage and that nothing was missed from the plan for the next. And also plan features for two stages ahead.

In this situation, the whole structure lives, develops and flourishes.

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

Here is the simplified matrix for checking the UX-interface (we gave the full matrix here in this habrapost ):



As a result, we have three fat plus points:

• Designers are drawn into flexible development, while maintaining the same quality of the created interfaces.
• None of the experts is “idle” without work, even if there is only one project at work.
• We receive regular feedback from the customer and make changes to the lower levels (so cheaper).

At the “zero” iteration, we need to develop such a layout that would deliver to all participants in the process: from the customer to the designer. And to design and demonstrate it until the customer approves the layout completely. And then - confidently develop the project, not deviating and not being distracted by the "rework".