Iteration is a natural and necessary part of the design process, but so many of us go about it the wrong way. Before we talk about the pitfalls of iteration, let's first discuss what iteration actually is and the benefits of doing it as part of a rapid prototyping and lean UX process.
Iteration, simply put, is about designing numerous versions. Rather than going straight into version 1.0, we prioritize gradual improvement over working to completion, taking breathers at each interval to evaluate progress. This progress is evaluated in various ways, but the main takeaway we should be looking to gain from each iteration is valuable feedback.
You can gain feedback from:
- Yourself, as a trained UX designer
- Your team, as those that understand the project goals
- Your users, whose advice will be more honest and useful
Product teams often neglect user feedback for various reasons:
- "It sucks"
- "We're not ready to launch"
- "We want users to love our first product"
But answer this honestly now: would you rather release your version 1.0 knowing users love your product, or release your version 1.0 having absolutely no idea?
Making the Case For Shipping
Shipping is the aspect of the iteration workflow that involves releasing something usable in order to get feedback from people other than yourself or your team (i.e. your actual users and future customers). Even though great UX designers will use project collaboration tools and design handoff tools like Sympli to discuss iterations, and live preview tools to test designs on real devices, users will be able to rate your product objectively and without bias.
It's not to say that every iteration needs to be a usable iteration, but you should nonetheless ship regularly and ensure that some iterations are gaining user feedback. This user feedback can be in the form of written feedback, or it can the recording of a user test.
What Constitutes as a Ship?
What constitutes as a shippable iteration depends on your current feedback goals, but the #1 requirement is that your mockup or prototype should perform well enough to use. If it's fundamentally broken, those deep flaws are going to undermine the entire feedback process.
You can totally ship a set of your ux design deliverables if your current goal is to test the user experience. Your product doesn't have to be developed yet, it doesn't have to be "real", but it does need to be pleasant enough that the user can evaluate all aspects of the design with ease. A little friction will indicate poor UX, but a fundamentally broken application won't allow for constructive feedback that can be used to drive the next iteration. All you'll end up with is a really upset user.
Where Can I Ship My Product?
If your business already has users or customers, then you have a test audience for beta testing. You can segment a subset of that audience, or you can choose to sail your ships to anyone you know. It's up to you. If you don't have an audience for your product, which is common for startups, don't worry, there are options. Product Hunt is one of those options, but there are other, more maturer websites like Betalist that have been around longer.
Product Hunt is a platform for sharing (or rather, hunting) products. It's basically a, "Hey, look what we made" platform. Product Hunt has a premium "Ship" tool that allows you to create "Upcoming" pages for your product. You can use this to collect subscribers (i.e. early adopters) and garner interest in your product before its created. You can then send out messages to those subscribers, granting early access to betas and asking for feedback.
You might think that asking for money for a product that barely exists is totally crazy, but really this is where a lean UX workflow stops being about just improving UX and starts being about creating a sustainable business. Early adoption is perhaps the greatest form of validation.
An Example Workflow
Here's what a design workflow looks like when iteration, rapid prototyping and shipping all work together to get valuable feedback quickly and regularly:
- Iteration 0.1.0 (team feedback)
- Iteration 0.1.1 (team feedback)
- Iteration 0.1.2 (team feedback)
- Iteration 0.1.3 (team feedback)
- Shippable iteration (wireframe, user feedback)
- Iteration 0.2.0 (team feedback)
- Iteration 0.2.1 (team feedback)
- Iteration 0.2.2 (team feedback)
- Shippable iteration (prototype, user feedback)
- Iteration 0.3.0 (team feedback)
- Iteration 0.3.1 (team feedback)
- Iteration 0.3.2 (team feedback)
- Iteration 0.3.3 (team feedback)
- Iteration 0.3.4 (team feedback)
- Shippable iteration (developed beta, user feedback)
- …et cetera
How to Get Sympli Screens in Front of an Audience
How you show your design to early adopters is up to you. You could do that via Dropbox, Google Box, whatever. Get creative and learn how to use Sympli Webhooks to automate the process. Webhooks allow you to establish automation for certain Sympli tasks when an action is taken, for example when a screen is uploaded to Sympli, place it in a certain Dropbox folder. Many mature applications these days allow incoming webhooks, but you can also use Zapier Webhooks to connect Sympli with other applications in exciting and productive ways.
And you have a developed beta, then you have the "real thing" to show users. Even better.
Conclusion
The importance of user testing can't be stressed enough these days. By integrating shipping into your iterative design process, you can gain insights not only into the UX of your product, but a deeper understanding of your business goals. Business goals should align with what customers want, and you might find that after shipping an iteration of your product, customers want something totally different that what you had originally thought.
It happens, and knowing this early-on in the design process ensures that your team isn't wasting too much time on features the user doesn't really care about.
