This is a guest post from veteran Agile UX coach Anders Ramsay who’ll be visiting Crisp in March.
In a traditional UX practice, there tends to be a strong focus on whole product design. In other words, we want to integrate all the features of a product into a unified and coherent experience, before we can consider the design work to be done.
Big Design Up-Front is like growing a tree in a “wireframe nursery” before planting it in the real world of working software.
But if you are taking this approach in designing the user experience, and you’re also part of an Agile team, then that might be a major reason why you’re struggling to integrate your UX practice into an Agile model.
Why is that? Well, trying to do a whole-product design will of course take a lot of time, meaning you’re delaying the point when developers become actively involved. And by actively, I mean either directly participating in the design or building some part of the product. While there are many aspects to integrating Agile and UX that are challenging, the design of this first release continues to be a particularly stubborn obstacle. It means that, while the developers on your team may be Agile, you’re still stuck in a Big Design Up-Front world.
One common attempt at shortening the time of up-front design work is the practice of designing an “MVP,” or a Minimum Viable Product. Now, I am a huge proponent of MVPs. But the problem with MVPs is that most teams seem to focus on the M and P and sort of ignore the whole “Viable” thing. In other words, MVP design becomes a somewhat absurd exercise in creating a supposed minimal product with a supposed minimal feature set, when in the end you’re actually just designing the, um, product. The only real difference is that you’re calling what you’re doing an “MVP.”
But what if you want to work in a way that really integrates with how (Agile) developers work? One place to start is to take a more organic approach to the product design. As Chris Pine, author of the seminal book Learn to Program, writes: “A program is not built; it is grown.”
While a traditional UX design commonly is presented as a fully formed product, this is not how software actually is made, especially in Agile circles. Instead you build one feature end-to-end and then you deploy it. (Yes, this is a broad generalization, and I skipped a lot of stuff like testing and integration.) The deployment part is very important because it allows for all kinds of insights that do not reveal themselves in a local environment.
So if you’re a UX designer, here’s the deal: if you want to work effectively on an Agile team, you need to work in a way that is compatible with how software actually is made generally and with how Agile developers work specifically.
One very powerful way to do that is to shift your approach away from designing the whole product to instead designing just one or maybe two features, and then shepherding that design through to deployment. By doing so, you have moved development work to be much earlier in the project lifecycle. The working software that has shipped can now serve as the seed out of which remaining features can grow.
With a One-Feature Release, we quickly ship a seed version of the whole product, out of which additional features can grow.
If you’re a traditional UX designer, this idea might sound a bit odd, and maybe even a little scary. How can you design a product with just a couple features in it?
Let’s look at an example.
Let’s say you are working on a Personal Shopper app for a major department store chain. A major business goal of the product is to offer assistance to customers in the context of wherever they find themselves in the store. For example, maybe they want to do a price check. Or maybe they want to find products related to an item they are looking at. And, of course, a top goal of the app is to increase product sales.
As usual, the client has a laundry list of desired features. Here are a few:
- A-Z Product directory: Search/browse a list of all products in the store, and get a location and description of the product.
- Contact customer service: Eg via chat, phone, mail. Also, show me where customer service stations are located in the store.
- Flash discounts: maybe something in the store is 50% off for the next hour.
- Items related to this item: Scan an item and get a list of related items and where they are located in the store.
- Is item in stock? If a shelf is empty, scan the a barcode on the shelf and find out when an item will be back in stock.
- List of current discounts, coupons: List everything currently on sale in the store (same as is already available in physical leaflets) and include barcodes for use during checkout. Make some discounts exclusive to the app?
- Price Match: Send a link to a better deal found elsewhere and ask us to match it.
- Purchase from your phone: Pay for a product from your phone.
- Related products: Scan or enter a product name and get a list of related products in the store.
- Store amenities: restrooms, cafeteria, parking, etc.
- Show trending purchases: eg what are current top sellers.
- Store check-in: When I arrive in the store, allow me to check in and get a summary of current discounts, cafeteria menu specials, etc.
- Validate parking from the app: Only certain stores have parking.
In a traditional model, we’d set out to design a whole product experience with all these features nicely integrated. But how might we instead select only one or two of these features and thereby bring development work much further upstream in the project lifecycle?
There are many possible strategies we might take, and many possible feature candidates for a first release, but one effective strategy is what I call the “Discrete Feature Strategy.” With this strategy, we look for features that require a minimum of integration with other features. Among those features, we then look for features with the highest marginal value (ie highest perceived business value + lowest estimated cost to build.)
Before you do your detailed exploration, you might consider doing what I call a vision sketch. This is a high level depiction of what you and/or the main stakeholders imagine that the “finished” product might look like, but without trying to figure all the details. (You might consider an activity such as Product Box or Design Studio to do this.)
When you are ready to do detailed exploration, if you have a long list of features, consider dividing into cross-functional pairs (eg a tech/non-tech pair) and then have each pair do a timeboxed exploration of each feature as a possible release candidate. As a pair, you can use the above strategy or simply explore what each feature might look like as a stand-alone product. Then, each pair presents back their proposed candidates to the team. You might use a tool like dot-voting to uncover which candidate is trending, and then ultimately leave it to the Product Owner to make the final call.
It’s very possible that there is no one clear perfect candidate. However, making a choice and starting to build is just as important as making the right choice.
Here’s my One-Feature Release candidate: In-Store Discounts…
Here’s an example of a One-Feature Release Candidate, where we get a much bigger Personal Shopper app underway quickly by shipping just a list of discounts as a small but complete offering.
The first release of the Personal Shopper app would simply be a list of current discounts in the store. To sweeten the deal, one could make some of the discounts exclusively in-store, which would incentivize store visitors to download the app. And signs with info about the app could be posted around the department store: “Install now to get exclusive in-store discounts!”
With this model, we have achieved a number of important wins.
First, our work is much more closely integrated with the work of developers, since design and implementation are more closely intertwined in terms of time, meaning that there will likely be a closer working relationship between designers and developers.
Second, the amount of design documents we need to create is significantly reduced. In terms of wireframes, for example, you might get away with the just the above mockups.
Third, we now have a product that is live and has real users very early in our product lifecycle, which of course is invaluable on many different levels.
Fourth, we have now have an established collaboration model between design and development that we can continue to use as we organically grow the product with more features.
As you may have noticed, what we did here wasn’t that fancy in terms of process. In fact, once an initial release of a product has shipped, doing single feature releases might be how you normally work.
But the big shift is doing that from the very beginning, and the challenge is more one of mindset than of process, of changing the questions you ask yourself and your team. Instead of asking “What should the product design be?” ask “What is the smallest piece we can ship quickly that will still be valuable?
If you’re struggling with your Agile UX integration, I’d definitely recommend giving this approach a try. It might be a bit weird at first, but once you’ve got the hang of it, I’m guessing you’ll find it to be incredibly powerful.
Anders will teach how to apply Agile thinking toward being a more effective communicator and collaborator in his upcoming 2 day workshop at Crisp on March 18-19. Read more and get your seat now!
3 responses on “Guest blog by Anders Ramsay – Finding Agile UX Nirvana with the One-Feature Release”