Lean UX case study
“If you cannot fail, you cannot learn.”
— Eric Ries
I like the quote; partly because when I read it I felt all validated because I tweeted something similar once and mostly because its true. I also now realise that anybody who happened to read that tweet probably thought I was shamelessly ripping it off (I hadn’t read the book at that point), but I digress…
I was motivated to write this blog post after a recent telephone conversation where I was asked how I brought UX design to agile development teams. This threw me for a moment because, in my head, I just got on with it. Some teams could be a little resistant at first because *they* want to “just get on with it” – but once they realise that you don’t intend to hold them up, it’s possible to be accepted. The best I could come up with at the time was that it was vital to be involved early.
I stand by that statement, but the question deserved a proper answer. So, I decided to blog a case study using a project that I’m involved with. I have included a few ‘lessons learned’ and notes at the end. And… sorry for the long post!
As this is in-progress, I do have to be a little bit careful and ‘change names to protect the innocent’. The overall problem is common to the entire scientific world, however, so I don’t think anybody could argue IP over the problem statements. It’s probably also worth noting that this project is part of a fairly heavy-weight desktop application.
A common language…
As with any project kick-off, it’s good if everybody can use the same words to talk about the same things…
This is ‘method’ as in science project; the part of the experiment that describes the ‘collection of steps performed in order to maximise the chances of producing consistently repeatable results’. In this case we are talking about settings that control scientific hardware (mass spectrometers and liquid chromatography equipment) and the processing settings that will be applied to the acquired data.
Our target persona; generally somebody who is very experienced with the equipment and the domain.
A repeated experiment. An example would be analysing fruit for pesticide contamination. The client would analyse hundreds or thousands of fruit samples during the course of a week. The ‘Method’ is used for each sample so that results are comparable. The person doing routine work is generally somebody who has little overall knowledge of the equipment; they just need a summary of results.
It’s all about telling stories…
This particular project was one that I kicked off based on the lack of a targeted solution within an existing product. The problem statement is a simple one; “we can’t make methods”.
“I plan to investigate a solution that would allow Method Developers to produce Methods to be used for targeted routine analysis. The solution must allow for rapid optimisation and testing of instrument and processing settings as part of a single unbroken and iterative workflow.”
(I edited that a little to take out the competition reference)
Given that problem, this has the potential to be a pretty big project – so a bit of early validation would be very important.
So far, what I had was an idea that there was an opportunity. Nothing (apart from hearing a few grumblings) to validate my thoughts. I need to get a little bit of time from a couple of people in our labs and see if this was worth even going past the elevator pitch
So, I got that little bit of time. I arranged two sessions. Each time just observing while the scientist worked through a scenario similar to the one in the statement – I also took one of my team along. Each time there were a lot boulders in the road and in some cases it simply was not possible for them to proceed. So far, the opportunity was still there.
As this stage, I still didn’t want to commit any more people that I needed to. To that end, I got the two folks mentioned previously into a room with a nice blank wall and covered it in post-its based on my observations and their corrections. By then end of two hours I had a pretty good idea of an initial direction – and that we didn’t currently support what they needed.
It’s always important to agree how the progress and ideas will be available to anybody who is interested – and particularly so when the team is distributed. So, I set up the (company visible) project blog and a couple of us bounced ideas around to see if there were any fantastic new thoughts or developments. Unfortunately, nothing particular ground breaking could be thought of other than, as usual, trello and pictures of the physical project/kanban boards.
I put together a very short presentation for my boss (and his boss) to pitch for an internal project. This was just a re-hash of the pitch and a statement of what we were missing.
So, time to get a team together. I was given the name of somebody who could act as a product owner, a lead developer, somebody from evaluation, myself and three subject matter experts. I also involved a couple of experts in the US and one of my team there. (see lesson learned reference)
Since we had now had a few folks who worked in slightly different areas; the next step I chose was to look at how closely their workflows might align, or if we needed to consider a split point right away and look at separate solutions for the different target groups. I didn’t have subject matter experts to cover every market but I did have a reasonable representation. More interviews and card sorting exercises came into play at this point.
Get things really started…
So far, I was coordinating a planning effort to get a starting point with the SME’s. The development lead had been kept informed, but we were now at the point where we had something to start working on… and something to start learning from.
A short series of vision communication meetings were arranged to get everybody up-to-date across sites; this involved the vision/elevator pitch, the problem statement, target persona and a communication plan. We also talked briefly about some of the terminology we would use. (see lessons learned reference)
The first few iterations…
Over the next few gatherings, we translated those early workflow plans into a first go at the IA and this meant that the developers working on infrastructure could generate their stories and start to build a flexible architecture. On the user-facing side our sprints were focussed on stories that were driving sketches which we validated with the stakeholders and developers. I waited until were putting together early Axure prototypes before ‘using up’ the best internal candidates for usability testing (see lessons learned).
Also, throwing in ad-hoc guerrilla usability tests for anything that did not need any in-depth understanding helped things along – as ever, this style of usability testing at this wary stage (if correctly targeted) can be a fantastic way of providing constant adjustment!
A quick note about not design first…
One of the challenges here was to have the development team working along-side and not a sprint behind. Sometimes that was tough – particularly at stages when more fidelity was required in the designs. As these points, I would re-focus what the scope of interaction was. As the design became a reality, the focus was more on testing and feedback – but still in the same cycle. Designing together also gave the developers a chance to say what was possible and to provide estimates.
As we started to get to something that was the front end developers could work with in more concrete terms, the sprints could drive controls and interactions that could be put into the (now quite advanced) framework. Also, we started to cut images from the prototypes and wireframes to host in the framework so that could be exercised during usability testing. This also made it more and more ‘real’.
Finally, we now had bandwidth to produce alternative designs for areas that were causing possible problems for the flow to goal and test them out.
Live wire framing is fantastic! Over the course of the early stages (and still!) getting together to either sketch or use balsamic to bring something to life while either pairing with a stakeholder or as a group (depending on availability) really starts to get the solutions to gel. I found, as ever, paper is great for involvement and getting a ‘big picture’. The Balsamiq sessions also worked well – but keep the updates small as groups can be prone to ‘letting the designer get on with it’ while they start discussing some tangential point. (managing this might warrant a separate post)
And even more iterations…
By now the prototype was just being scavenged for images that could be used as placeholders while the development sprints took care of bringing things to life. The design was now focussed on the interactions and micro interactions, validating with testing and getting to the details. During the sprints, designers pairing with development was a great way to provide constant adjustment and keep the vision in-mind.
As I mentioned at the start of the article, this project is still running. I won’t say it’s all gone perfectly – it hasn’t – but that means I/we got some great learning opportunities (always learning!) and I (hope) it’s a good example of a fairly large, cross-continent project being run in this way.
I should have pushed for a larger kick-off team and then directed some of them into ‘satellite’ mode; not having a larger pool of knowledge to draw on from the SME’s meant more rework of the initial prototypes than should have been necessary.
For every group session and even scrum meeting, I should have made sure that the that the vision and target persona were present and visible. Normally, it’s there and stuck to a board (and on a project blog), but the cross-site nature of this meeting meant that it was not always immediately present. I did remind people frequently – but often when we had gone off-track. If that information had been there, it may have helped the focus and allowed for simpler updates to that vision when needed.
The very first prototype sprints did not include development effort estimates for every story/feature we generated. I realise that this was due to thinking that so many things would change it was not worth it- with hindsight I would ask for those estimates.
I struggled with trello as a cross-site communication tool. It was the best thing I had at the time, but I think this would warrant more investigation.
I relied on existing internal glossaries for terminology. With hindsight I would produce a group-sourced glossary for the project – and check how it aligned with the corporate standards later.
I was holding multiple stand-ups; one for the local team and one for the US (which was a sit down with just me). This meant that I was the information transfer mechanism (apart from the boards and shared assets of course). This changed as we adjusted responsibilities for a better split, but in retrospect I should have run it like others and just included the video.
… and a few notes…
It would have been perfect (as ever!) if we could have had access to real end-users during those early iterations. Unfortunately in the business that we are in it can be difficult to get very early sketch prototypes in front of users. This had to wait until the Axure prototypes were a little more mature.
It’s worth remembering that often there are normally a stack of re-usable assets from previous projects. In this case I cut and paste all sorts of items so that there could be something in-place so that the story would flow.
Having developers involved right from the start allows for an early feasibility sanity check. Having a lot of previous development experience also helps when talking through possibilities but these are the folks that will have to build it!
Some of the developers were nervous working without full up-front designs – pairing here worked wonders. I can’t stress enough how great it is to pair up and work right next to the developers bringing things to life. This way everybody gets to learn something.