When contracting with suppliers to provide software, website or mobile app development services, the key to building a successful product doesn’t just depend on the quality of the supplier or its tools, but the methodology employed to get from concept to launch…. and beyond.
The most recognised software development methodologies are the traditional ‘waterfall’ and more flexible ‘agile’ processes. Waterfall contracts are ideal for situations where the product requirements are well-known and documented, and allow contractual certainty in terms of price and output. Agile contracts offer flexibility so that development can change direction during the life of the contract. Although there are contractual tools available to mitigate uncertainty, the increased flexibility does introduce challenges to fixing a price on deliverables.
In both of these methodologies, the product is built to the customer’s requirements before undergoing testing and ultimately launch.
Where Lean UX differs, is that the product is launched as soon as a ‘minimum viable product’ is ready, on the understanding that development will continue on an iterative basis post launch. The advantage of employing a Lean UX development methodology is that both customer and supplier will learn about the viability (or otherwise) of the product in real time, allowing future requirements to be adjusted, fast-tracked or scrapped based on informed decisions gained by genuine user behaviour and feedback.
This methodology is not new – your smartphone will be full of apps that are updated and refreshed every few months or even weeks (Facebook, Spotify, Google Maps). Such development is often carried out by in-house teams. However, when there is a need or desire to contract with a third party to provide such services, even more so than agile contracts, there can be uncertainty around what product the supplier is committing to build, and at what cost.
To counter the flexible, iterative nature of a Lean UX arrangement, the customer should adopt a two tiered approach to the contractual terms. Firstly, the supplier should be asked to sign up to ‘minimum’ or ‘core’ requirements, even if they are relatively generic (e.g. to deliver a fully functioning platform by ‘X’ date). The over-arching requirements could be on a time and materials basis but with a cap per iteration, or overall project cap. For more complex engagements, more sophisticated pricing methodologies used in agile contracts, such as ‘functionality points’ can be used.
Secondly, the customer should ensure that value is gained at each iteration, or a set milestone throughout the project. For example, after each iteration the supplier should provide in pre-agreed form the updated product description together with learning and knowledge gained via the user experience to date. The customer should ensure there is an obligation on the supplier to provide information such as a status report, lessons learnt, options/ideas for future improvement, and all relevant source code should the customer choose not to continue the development/partnership into future iterations.
Lean UX isn’t the future – it is already here. However, when contracting with Lean UX the very real and often necessary benefits of learning on the job should be balanced by taking care that the contract offers some certainty and value to the customer along the way.