As the user experience (UX) lead (and often sole UX practitioner) in a small team of software developers I’ve often had to adopt a pragmatic approach to incorporating a UX workflow into our project work. This has involved keeping clear of trendy methodologies and buzzwords, instead focusing on the key outcomes of creating the best possible user experience for the end-users of our products. To do this we follow a user-centred design process wherever possible, undertaking research with our target user groups, designing interfaces that allow them to achieve their goals and testing our designs with “real” users in the form of one-to-one usability testing.
Recently I’ve been reading more about the Lean UX model and noticing how it complements some of the more ad-hoc approaches we’ve been using. Lean UX is gaining popularity amongst software development companies, and in particular the start-up community, for its outcomes-focused approach, rather than being concerned with the production of design documentation (e.g. specifications documents, wireframes, user flows, site maps etc.). Lean UX concentrates more on testing ideas/assumptions quickly and iteratively, and is often carried out within the context of an Agile software development process. In real terms this may translate as creating interactive prototypes (e.g. with HTML/CSS/jQuery) of key functionalities and testing these with users in what is referred to in a “build, measure, learn” cycle.
Whilst there are some similarities in our approach with Lean (particularly in terms of the kinds of documentation we produce), there are some areas in which adopting a full Lean approach might be problematic. For instance the suggested scale of testing (e.g. weekly or maybe even daily) is not practical for us. Our end-users will have limited time, be geographically dispersed and there is often little budget to compensate them for their input. Our digital resources are often aimed at specialist audiences so informal “corridor” testing with non-specialist users, or worse, technical specialists, may well be counter-productive.
Concentrating on the creation of prototypes rather than traditional lower-fidelity deliverables such as wireframes may increase an overhead on overstretched teams–even a prototype with limited functionality will take time to produce. In terms of communicating early ideas a wireframe or sketch may still be the most appropriate tool and will take less time to create and be more “disposable”.
Some projects have long gestation periods and testing small items of functionality at different points along the timeline gives rise to a potential problem of losing sight of the overall consistency of the product’s interface. One way of avoiding this is to develop UX pattern libraries (e.g. commonly-used user interface solutions) or higher-level design principles that ensure that similar problems aren’t unnecessarily solved from scratch and consistency is maintained.
The ways I think Lean could prove to be particularly useful for our projects are as follows:
- Project teams using user research outputs such as user stories or personas to help decide on the prioritisation of functionality and design.
- Lean’s encouragement of collaborative design sessions may help to remove some friction in the design process, e.g. by encouraging designers, developers and subject specialists to consider problems together rather than in isolation.
- Building up a comprehensive library of reusable design patterns and common design principles relevant to all projects; something we’ve already begun to do.
- Considering ways in which usability testing might be included throughout the design process to gather on-going feedback, rather than at distinct points–and ways in which this might be handled logistically and financially (e.g. by including budget for usability testing in project proposals).