Agile principles emphasize the use of relatively short development cycles, each of which achieves some tangible improvement to the software. Agile rapidly became the dominant approach to software development because using it means you catch bugs early, before you built too much on top of them, and because it gives you granular control over development direction. Yet, when it comes to UX, agile is underutilized. That’s because too many software development companies see UX as something separate from their main task.
In this post, we’ll explain why we think that UX is our main task as software developers, and show how agile development methodologies are the perfect fit for effective UX development. Finally, we’ll show how we use our Interval UX development method to rapidly create apps that we know users will respond well to.
First, let’s review the importance of UX.
Why UX?
User experience is not just front-end interaction design. That’s a surface-level reading of something that should go all the way down. Instead, UX is best thought of as a bucket that contains everything your users experience about your offering. Welcome emails? Onboarding flow? Dashboard functionality? If users experience it, it’s UX.
This stuff matters for two reasons: first, because UX is your whole product as far as your customers are concerned. They don’t care if your code is elegant and functional, or your API is cunning and effective. They care that the login flow is glitchy, every single time. Or that when they port data across from the one other tool they use to run their business, it gets messed up. Or that when they look at the dashboard they can’t make sense of it. You get the picture. UX is what users care about, because it's what they experience.
It’s also a key competitive battleground. In the short term, it’s how you lose customers. In the long term, it’s how you win industries and sectors. And building UX into your design from the ground up can deliver 1.7X revenue, with the effects more pronounced the larger your company is.
We can’t do UX design without UX data, so we’ve developed ways to collect information about:
- What does it feel like?
- How well does it perform?
- How easy is it to navigate around?
- Is it what I would expect?
- Is it novel?
- Was it fun to use?
- Did I enjoy it?
We’re looking to measure delight as well as satisfaction, enjoyment of the product for its own sake as well as efficacy at task fulfillment. That’s how we build products that users actually look forward to using.
What’s wrong with UX development?
Why isn’t everyone building fun products that are super-easy to use? Why do so many companies know so little about what their customers do with their products on a day-to-day basis, and even less about how their users feel about their tools?
The reason is that there’s something fundamentally wrong with mainstream UX design, precisely because it’s approached as UX design. It’s treated as a feature or a service, an extra that can be tacked on afterward. ‘We do UX design, because after we make the product, we ask a couple of users whether they like it better green or blue.’
That’s changing the paint job on the hood. UX design is figuring out whether users want a car at all.
Because traditional software design regards UX as an upstart discipline and an afterthought process, it relegates it to less-intensive, more old-fashioned approaches. Too many developers wireframe UX once, tick the box, walk away and never look back. In their mind, they start developing the product instead. To our mind, they stop developing the product — the one users actually interact with and care about — when they stop working on UX.
So what should developers be doing?
We think UX should be embedded as a cFore part of software development. Rather than designing UX upfront, then walking away and forgetting about it, we embed it in our agile process. We call this ‘continuous discovery.’ Are we on track for what we want to build? Is there something we can improve or enhance while we’re on this route? Constantly monitoring and adjusting for improved UX as we develop lets us drive big improvements in ROI without treating UX as some special add-on. We put it right in the middle of development instead. We call this ‘Interval UX.’
Interval UX: The concept
Interval UX is simple, like all impactful ideas. It’s what you get if you apply sprint methodology to UX and embed UX at the center of the design and development process.
We get a lot this way that we couldn’t get using the standard UX design and development process. These are the benefits that let us drive positive outcomes for clients more accurately and with higher ROI.
Interval UX in action
We recently created a social and news app for sports fans, with the brief to include the best features of both news and social apps. As with all our new development projects, we started with ‘the sky’s the limit’ — what’s the best product we can possibly build? Then we scale that ambitious start down until it fits into the client budget.
We’ll start the process with three engagement phases:
1: Pre-work
At the start of a new engagement or a new piece of work, we’ll provide design input and assets at a rapid pace facilitated by using agile methodology.
Examples:
- Product map
- Design sprint
2: Emergent
Solutions and concerns that arise through the process of continuous discovery during design and development.
Examples:
- UX review
- UI review
3: Phase ahead
Prior to a planned release, or as a result of new feature ideas arising from the iterative development and discovery process.
- Feature evaluation
- New product map
The Interval UX development cycle
We use a four-step development cycle.
Pre-plan
This is where we identify key features and functionality — the ‘can’t do withouts’ for the project.
We talked with the client about what they felt their app absolutely had to have — the features it couldn’t work without. In this case, that meant chats and groups, together with the ability to reach out to friends in a defined network. On the sports side, we needed a live sports viewer and live updates of sporting events.
We began work on the product, but rather than deciding on a UX/UI after a single, inadequate round of testing (or without doing any testing at all), we also begin iterative testing and redesign based on test results. This process continues to launch and beyond.
The example that follows is drawn from a recent client. We don’t use an identical process or release schedule for every project, so while we often use a very similar approach, this is for illustrative purposes. Each project has different needs and has to be approached differently.
For the example we’re talking about, here’s the initial design concept:
Bare-bones and functional, this leaves lots of room for future iterative improvement, rather than trying to get too ‘good’ too quickly before we really even know what that means.
We use three release points:
Friends and family release
This is the first group we release to. For obvious reasons, it’s small and may not be representative of end-users, but it’s some user feedback from people who didn’t build the tool. Its value to the process is surprising. We take this feedback and go back to design and development, completing the initial build cycle with some user data to work with.
Then we move to the next release point, which in our experience is often where the magic happens.
Small group product launch
We released this build on the App Store to solicit more data and survey feedback. We’re looking for baseline UX ‘box checks’ at every stage:
- Did we needlessly overcomplicate this?
- Are there features that we think are really cool, but actually they’re a bit overbaked and users don’t actually know what they’re for or can’t use them?
- Can users navigate the interface and find what they want?
Here’s our initial pre-release, following the friends and family release feedback:
We look for qualitative feedback too. Without this, you miss situations where people can find what they want, but they find it difficult and don’t like doing it. Without qualitative feedback a situation like that shows up in your data as positive results followed by sudden churn! When we finish this stage, we’re ready to launch an MVP.
MVP release
The full product was built and released on all the appropriate channels — in the case of the product we’re using for this example, at the time of writing it had just launched on the Play and App stores.
Here’s the MVP release:
The crucial thing to understand about this process is that by the time we launch an MVP, we’ve done two generations of user testing.
You can see the iterative effect of that when we put these builds side-by-side:
So when we test our MVP, we’re testing for ways to make it better, not to rescue our proud new product from catastrophe.
Takeaways:
- UX isn’t a feature, or an add-on. It’s right at the very core of your product.
- If waterfall and other largely-outmoded development methodologies aren’t right for technical development they’re not right for UX development either.
- Interval UX is a rapid, iterative and effective approach to putting UX at the heart of design and development.
