Tag: Agile

Explaining UX to developers

Posted on by David in User Experience

Development with none or minimal inclusion of UX does not function very well. UX practitioners can provide valuable information developers cannot be without. However, developers often see UX as something that doesn’t fit into their processes and consider it an addition that slows them down.

Developer’s Agile

A great explanation I heard of extreme programming (an agile method) and waterfall was the use of a ship and a cannon located on land. In the waterfall method, you are trying to build the most amazing cannon and eventually fire one perfect shot to sink the ship. Unfortunately, with waterfall, the projects often run out of money so the creation of the cannon cannot be completed, or once completed, the targeted ship may have moved. Instead, agile development methods focus on building a small cannon quickly, shooting one shot, and seeing where it lands. Then, they make some adjustments and shoot again. This iterative approach can then continue until the project runs out of money. In other words, developers want to build in smaller increments out of fear of running out of resources.

UX and Agile

Many developers only see UX as a necessary evil. In their minds, if UX is not included in their projects, they run the risk of building a cannon no one can operate. Therefore, developers may want to include UX towards the end so that the controls of the cannon are built accurately. However, they have made a fatal error in assuming that their commander had the right intelligence of where the ship is located. I.e. they believe the business partner knows what needs to be built.

The UX research team can act as scouts. By including the scouts, the team might find out the ship they are planning on sinking actually is not a hostile ship, and help them realize they should be firing towards another ship. In addition, as the developers are building each iteration of their cannon, the hostile ship will move around, and the scouts will help ensure that they are consistently aiming at the right place.

Another part the developers are missing in this project view is that they assume the commander’s decision to build a cannon is the best way to fend off this ship. The UX design team (with help from the researchers) might realize it would be better to build torpedoes to sink the ship instead of a cannon. I.e. the UX team identifies the main pain point to solve, and helps the business partner decide on the best product to build.

Conclusion

The UX team provides a lot of value to the development team, especially upfront. Our goal is to make sure we are building the right thing and building it right. Even if we might slow down the process slightly, it is important to include us early in the project.

© David Juhlin and www.davidjuhlin.com, 2017

Agile user experience challenges

Posted on by David in Business, User Experience, UX Strategy

Bringing user experience into an agile development process can be challenging, and at this point there is still no cookie cutter formula for implementing it successfully. It is very tempting to believe this formula exists, especially when attending a conference and some presenters speak about how they successfully incorporated UX into the agile process. The reality of integrating user experience in to an agile development process is challenging and it is not done overnight. In this post, there are a few thoughts to consider.

Diana DeMarco Brown’s article “Five Agile UX Myths” posted in Journal of Usability Studies (http://uxpajournal.org/five-agile-ux-myths/) highlights many important points. In my opinion, the most important point was how there are multiple ways to do agile UX and just because the “one sprint ahead” works for one organization, it may not work for others. I think the best thing to do is to gain inspiration from other organizations, and then try different approaches to find out which way works best for your unique situation. To make the transition successful it can be good to be prepared for different issues and problems that may arise. Here are my top 3 things to keep in mind:

  1. UX sprints works fundamentally different than development sprints
  2. Upfront work is important for both UX and developers
  3. User research can still be done even if you move at the speed of light

UX sprints work differently

Sophia Voychehovski, brings up an important point in her UX week 2013 presentation (https://www.youtube.com/watch?v=bbPTbN4Q_pw). Her point is that development teams normally split their work into sprints according to functionality (see picture to left), while UX sprints usually cut across functionalities as the fidelity of the design improves with each iteration (picture to the right).

Image showing how development sprints are split into features while UX sprints are split into fidelity level

The reason for this mismatch is that design is approached holistically to make sure the different elements fit with one another across different areas of the design. If the design process is forced to work in development sprints, inconsistencies and suboptimal interactions can occur between different parts of the system. This could cause inconsistency, if one feature might be optimized for the first function, and later on as the next functionality is built, some parts need to be reused (to maintain consistency). However, to support both functionalities the feature may need to be tweaked a bit. Now that tweak has to be in the backlog (on a “to-do” list) of changes for the first functionality. As the process goes on, the backlog will grow even more.

One way to overcome this issue is to allow designers enough time in the beginning of the project to get a holistic view of the system (can be low fidelity). Once they have the overview of the system they can be much more effective working in the developer sprints and most likely decrease the backlog.

Upfront work is important

Many agile projects don’t want any upfront work since that is the “waterfall method” (which is the devil himself). Once the project starts the team has some planning time to create an overview of the project and the product they are creating. The UX project also needs this planning time, the difference is that the UX project often needs a longer planning and exploratory phase than the development team. Unfortunately, most of the time everything has to happen according to the development team’s timeline, so the UX team is super rushed and may not have enough time to prepare and do proper user research.

With incremental improvements of an old system this issue may not be as severe. If only minor tweaks are required, the UX designers already have a holistic view and can therefore jump right in to the development sprints with ease. So, the primary factor for determining the magnitude of this issue is how drastically the system will change.

One client I worked with was both the main UX person in the project as well as the project manager. His general approach was to create a high level design and discuss it with his development counterpart, before a project kicks off. This ensured that they both got a clear estimate of the development possibilities and the effort required for the project. Once they were done with this general planning, they took it back to management for approval of the project. As they presented the project they were able to provide more accurate estimates. (It can be hard to work in this method if you have internal billing, because if the project is not approved no one will pay for the upfront work).

As the project kicks off, he did not disclose to the rest of the team he had already created an overview of the design. Instead, they only discussed use cases and potential issues. He purposely stayed away from discussing solutions, since he did not want the engineers to start focusing on technologies and lock themselves into narrow thinking. After they all seemed to agree about use cases, issues, and features to include, he revealed the design and asked what changes would need to be made to deliver what they discussed. After the team made tweaks, they all had a high level overview of the system. As they started to work in their sprint, everyone understood how the different parts would come together and be presented to the end users in a cohesive way. This method also helps facilitate discussion between developers and UX professionals and enables the developers to provide good interaction ideas and be a valuable asset in the UX process.

Another company handled the upfront work in a completely different way. They included the developers in the upfront UX work. This company worked in tight teams so during the research and design phase, the developers worked alongside the UX lead and became her assistant. This allowed the developers to help develop test scripts, design concepts, etc. and once it was completed they set off to start implementing the new solution. This way of working has many benefits. For example, the developers have a better understanding of the users, they need less clarification regarding the design, and they will have an easier time communicating if any changes are needed.

User research can still be done

Some UX designers who are working in sprints may feel as if they don’t have time for everything. They need to develop designs for the next sprint at the same time as they are answering questions and making sure the current sprint’s design is implemented correctly. Unfortunately, since they don’t have enough time, they sometimes have to sacrifice the inclusion of the user (interviews, usability tests, surveys, etc.).

The best way to solve this issue would be to split up the workload and have one UX designer and one UX researcher. The researcher can set up all research, conduct the research and debrief the designer (or the whole team) in the end. If in-person research is conducted, the key thing to keep in mind is that the researcher will need to plan and schedule participants before they know exactly what the state of the design artifact will be available.

Another solution is to rely heavily on online tools and conduct all research online. Some benefits of online research include rapid turnaround time for participant recruitment, and many of the tools provide good analysis capabilities. If online tools are the solution, make sure to still include a final test, which is conducted in-person. It is important to conduct the final in-person test because many of the panels consist of professional test takers, who tend to be more computer-savvy and overly positive toward system/product, which could skew your research.

Final words

Independent of how you are planning to implement agile UX in the workplace, expect the need to iterate on the process since it will not be perfect from the start. It is also important to try different methods and critically evaluate what worked and what did not work, and how you can improve the process of becoming more agile.

© David Juhlin and www.davidjuhlin.com, 2016