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