Design

The 7 pitfalls to avoid when doing Lean & agile UX

Lean & agile UX draws its sources from lean principles. The aim of this practice is to reduce waste and make it possible to create products. in a more rapid way and effective by promoting collaborative moments in an interdisciplinary team and by being in contact with users as much as possible.

Screen_Shot_2016-09-19_at_18.59.13.png


In theory, these objectives are achieved by working on the user experience of the product in parallel with developments. In practice, it is easy to fall into traps that compromise the effectiveness of this method! So here are the 7 most common pitfalls to avoid:


Pitfall #1: Involving the UX Designer too early or only at the beginning of development

If you start designing the product 4 weeks before the start of development, you risk having all the design of a complete product without having put it in the hands of users and thus forgetting the objective of the product. We are then drawn by the functionalities of the product rather than the user problem to be solved. So we are no longer agile at all.


If we start development without taking the time to meet our users and challenge our successes with them, we take the risk of launching useless functionalities. In addition, starting developments at the same time as the design does not allow for sufficient graphic elements. Functionalities are therefore added without integration and this does not make it possible to have a product that can be put into production every evening. So we are no longer agile either.


Screen_Shot_2016-09-19_at_18.58.01.png


Solution:

A good practice that you can put in place is to always have the design one week ahead of developments. The UX Designer will therefore start working 1 sprint before the start of the developments and the elements designed during a sprint will be integrated by the developers during the next sprint.


Pitfall #2: Not giving visibility to the Product Owner (PO) and Stakeholders (SH) on the days when the UX Designer works

In the agile method, the PO and the SH must transmit the direction of the project and the functionalities to be developed to the team. One of the ways to make this work easier for them is to give them visibility on the work done and to come. This allows the PO to make itself available for validation as well as to ensure that it has the necessary design at the right time to be able to move forward and therefore not to waste time.

 

A good practice is that the team always has at least 3 weeks of visibility on the work to come, which is compromised if the PO and stakeholders cannot project themselves into building the product with the UX Designer.

Solutions:

  • You can display a schedule of days worked that is visible to all members of the project team
  • You can also recall every morning when the UX designer works on the subjects on which he will make progress.


Pitfall #3: Minimize the brief

Starting to produce screens too quickly, without taking enough time to benchmark or get a good brief from the Product Owner (PO), can lead to a lot of back and forth that slows down the production chain.

Solution:

Before starting to create the models, take a moment as a team to study the competitors and align yourself with the image and style of the product (Atelier UI).


Pitfall #4: Only get validated once a day

Even with a good brief you can type on the side! Once absorbed in the production of screens, you sometimes forget to talk to the PO at an intermediate stage and realize the gap between the product design and the desired design after a lot of work!

Solutions:

  • A first solution is to set an exchange objective to validate the work in progress, for example one exchange per hour. Even if it means having the graphic elements validated one by one.
  • If despite this first solution there is still too much feedback, you can create one-hour sessions where the designer will work with the PO next to him to iterate more quickly on the various proposals.
  • In general, if you do well UX workshops, workshops during which the entire team creates the user paths and wireframes of the associated screens, before the creation of the models, there will be less exchange and uncertainty when it comes to validation at the model stage.

Pitfall #5: Do UX and UI workshops without developers

A lack of involvement of technical team members in UX can create misalignments in the vision of the product between developers, product owners, and UX designers.

Solution:

One solution is to systematically include members of the technical team in a collaborative design workshop, in a UI workshop or during user tests or interviews.


The benefits are numerous! This allows:

  • Less repetition in sprint reviews and in the workshop;
  • To have more feedback on the feasibility and complexity of a feature, which allows the PO to make the necessary decisions when creating the product and not only when planning the sprint;
  • And above all, to have richer ideas.


Pitfall #6: Only get validated by the PO and show the product to the stakeholder only once a week

Once the stakeholder is involved in the launch of the project and during the ceremony, you can forget to involve them in the key moments of interface design. However, it is the most visible part of the product and is likely to attract the most attention of HS and others outside of the production team! Especially since the latter can prove to be a source of interesting ideas.

Solution:

The lack of availability of HS may seem restrictive at first glance, but you can solve this by setting aside 15 minutes at the end of the workshop, for example, to share the progress and decisions taken before starting the production of models.


Pitfall #7: Put the UX Designer in a different office than the developers

Support for developers when they integrate design is often overlooked, although the added value of this approach is enormous in terms of familiarizing and engaging developers in the Lean UX approach and the challenge of product design.

Solutions:

  • One solution you can put in place is to have the UX designer work in the same open space, and even on the same desk as the developers on his team, so that even if he works on other topics, he can intervene and help them.
  • A standard that you can set yourself is to always have the models challenged by the developers before they are submitted for validation by the PO. What's easier if you just need to turn the screen for developers to take a look at it!


By avoiding these 7 pitfalls you will increase your development speed and avoid wasting the design or the functionalities developed.

 

To find out more about lean & agile UX and how BAM applies it: 6 steps to improve your lean UX

Designer UX/UI ?

Rejoins nos équipes