In the last two posts I described two of the ways that I have seen Agile development and UX mix: Sprint Ahead, and a Two Streams model. Two streams is arguably a form of sprint ahead, but one in which the design and development sprints are not locked in their time periods. However you structure User Experience in the development process, though, it does have to come first, it has to help define what development is going to make. Even if you have a separate research department, even if the UXers are completely embedded and blending with developers, UX guides what is made and will be developed and visually designed by interpreting research.
That creates the problem of how to transition what UX specifies to development. It is in the handover that the friction appears. What can the development team handle in the time allotted? And what happens when a hypothesis gets disproven after a sprint?
Handing over: Simple / Better / Delightful
It can be sketches and conversations. Annotated comps. Discussions sitting together. Prototypes. But somehow the concept has to go from UX to developer, even when the work is done in the same sprint by a blended team. In a recent experience, the UX work I did would feed into development cycles, but because of ever-changing circumstances, decisions about what could be put in production could change from sprint to sprint, even while the finished designs were all ready and waiting.
The team soon settled on a handover structure that dealt with this: I would design a Simple / Better / Delightful solution, and introduce them with a thorough background from testing, research, and stakeholder input.
- The Simple alternative would be the minimum to reach the product goal, usually a very concentrated intervention on the existing product
- Better would be close to state-of-the-art, perhaps also requiring changes to other areas to create a smoother flow with this new feature
- Delightful would be all about creating a unified flow with nice micro-interactions, that would involve significant investment in smarter interactions and perhaps dropping previous product decisions.
While this sounds like designing everything in triplicate, it actually usually meant that I would start with Better, tone it down for Simple, and scale it up with what could almost be called flights of fancy for Delightful. Because of the way Agile design decomposes the work into small issues, this was all very manageable–I wasn’t designing a complete flow all the time, but features in context.
By exploring the solution space this way deeply, come decision making time the decision-maker, like the UX designer or Product Manager, can be very flexible to only go with what they have resources for to put in production. They can show the stakeholders variations together with their cost, and get buy-in for informed decisions.
And Then Everything Changes
As described previously in Sprint Ahead, for some substantial pieces of work I was lucky enough to get budget to do real concept research before the actual design sprints, allowing the design team to test some serious assumptions of what users wanted. This can be seen as expensive, but for major e-commerce it is still cheaper than producing a bad flow that users can’t understand. You do want to avoid getting to a place where you have designed the whole product as a testable prototype before design actually starts: that’s simply about not wasting money. Focus on testing only assumptions, pieces of the flow you have real doubts about. My personal heuristic on top of that is to test to disprove, and do so by testing wild concepts: conversations with users about inappropriate or magical interfaces have often guided me to the heart of their needs.
Currently in our modern Agile world, the Lean methodology is helping speed up product delivery and cut costs by doing all testing and research almost during development: little piece-meal cycles of adding and subtracting features. One thing I’ve never read is how you go from MVP to some sort of MVP+ to maybe a full-featured delightful product: the shops I see trying to get to MVP with whatever permutation of Lean they call Lean basically just keep going with the same process to get to delightful, and I am really not sure that is appropriate; it doesn’t feel like you ever really pay off the design debt incurred from only always adding little pieces together.
However, if you do insist, you will get to the point where you prove or disprove some major assumption about how your product is going to work. A recent case was making a product for which we had a tough time getting to the right specific users until we had something concrete to show, and we had to work mostly with proxies: people who knew the space and possible users really well. Any meeting could (and often did!) yield completely new fundamental insights about the user’s conceptual model. While we were building. This meant not only incurring a huge design debt, but having to pay it on the spot.
Design is unable to keep the development pipeline full, or keep it from outright mutiny, if you have to scrap everything every 3 weeks, no matter how you have structured the cooperation with sprint ahead or two streams or blending all together. It is too wasteful, and angering. Once I realized the team could end up in this situation, my mitigation (I first typed in “solution”, and it is so not) was to defer fundamental design decisions as far as possible, or opt for the most flexible solutions at all time even if they were a little more complex than what seemed self-evident, using my experience to intuit what decision could be fundamental.
An example would be in the Information Architecture: first we thought we would have four major areas of activity, so the suggestion arose to organize them as tabs. I held off strongly because tabs really do not scale on a screen very well if areas are added and could not be secure yet that users would never need to see information from both areas at the same time. I instead opted for collapsible pods that could be added vertically. A few months later we were up to 6 areas of activity, with a seventh on the horizon, and where there was significant difference in the amount of activity in each area. Tabs would indeed have been inappropriate.
In all honesty, the way I managed this designing for possible futures was by mentally, and in sketches, constantly preparing what v2.0 and v3.0 of this product might look like based on what I could extrapolate from what I knew when making v1.0. Also, every time I added something, I had to ask myself, what if this is not true later on, and have an alternative ready. I have to say that working initially on this product as a web app in a responsive design was very helpful, since responsive design done mobile first has to be so constrained in what constructs are used anyway.
In the end the process felt less like putting features together into coherent flows, but more a sculpting by chiseling away hazy possible digital futures down to a product in current reality. There were days it felt like a high-wire act, and I had to do emotional management to make sure I saw every new requirement as a fun challenge instead of a blow to the work already done. I do regret I was only around to take the product to a Beta, I really want to see what the first contact with reality, the first real tests would take it to.
Ask The UXer 