.webp)
If designers want to work agilely and still design great, user-centered products, they need to stop designing faster and learn how to start designing less. You need to shift from a mindset where we design everything all at once and move toward a mindset of designing the smallest possible thing that can deliver value to our users.
By releasing smaller things more frequently, we have more chances to get feedback on our ideas and execution.
If something is going to be a massive failure, sometimes you can find out very early by shipping or releasing a small version of it. Imagine all the features you wouldn’t have created at all if you’d known how they would perform!
Imagine all the value you could deliver to users if you weren’t busy building enormous versions of things that nobody wants. Delivering small features early gives you information that can help your team make a decision about whether the rest of the feature is worthwhile.
By breaking things down into shippable chunks, you can deliver value early and often and get feedback on our ideas before sinking tons of resources into them. It’s hard and time-consuming, we know, but that’s actually the best approach to effective product design.
How do you design small?
Follow us closely as we take you through the standard approach to designing in bits.
- Understand the Goal
- Experiment with One
- Start without Code
- Don’t Deliver to Everybody at Once
- Accept Some Imperfection
- Commit to Iterating
Let’s begin with,
- Understand the Goal.
The most important part of releasing in bits or small designs is understanding the core goals of the feature or product you are creating. If the goal is too broad or not thoroughly understood, it’ll lead to a situation where features upon features are added based on an assumption that “The user might want it”.
By focusing on the specific value we want to offer per time, and then releasing at intervals to well-defined user groups, we have already gone the route of designing small, focused features or products that ultimately serve the purpose much better than having larger features that at the end of the day, do not serve the purpose.
- Experiment with One.
Take, for example, you’re designing a reporting dashboard for your job searching site. It can be tempting to ideate broadly and try to understand all the possible different reports that employers and job seekers will want and then design them all.
While it’s perfectly reasonable to spend a bit of time to understand which reports may be most useful, consider only fully designing and building one at a time, preferably prioritizing which you think will deliver the most value based on your research. Why would you make your users wait to see the most valuable report just because you haven’t finished designing the least valuable one? What if you’re wrong and people don’t need reports at all? By designing and releasing one report at a time, you’ll learn more quickly while hopefully delivering value to your users on a regular basis.
This obviously doesn’t just apply to reports. If you have multiple similar things that you’re planning on releasing, look at whether it’s possible to start with one and then add more later.
- Start without Code.
Often when we are asked to design a new feature or product, there are many different ways we could design it. We can spend a ridiculous amount of time in meetings debating the best way to implement something.
Ideally, we’d get to build many different versions of something and just see which one people like better, but this leads us to another problem: code is expensive. Prototypes and experiments, on the other hand, can be quite cheap.
Instead of jumping straight to designing fully realized features that will immediately be built by engineers, try designing experiments to learn the best way to build something. Try a concierge test or a Wizard of Oz experiment. Build a few interactive prototypes to test with users.
- Don’t Deliver to Everybody at Once.
One thing that makes designers hesitate about shipping an imperfect or unfinished design to people is not wanting to disappoint their users. After all, launching something that’s half-baked can end up reflecting very badly on the product and the company.
On the other hand, offering something that’s a work in progress to a small group of users who may have opted into early releases is an entirely different story. Testing out a new design on a few dozen or even a few hundred users can offer tremendous value to the team in the form of crucial insights and potential problems without risking disappointment for the whole user base.
Stop thinking that you have to launch every new feature with a press release and a marketing push. You’re still delivering value to users, even if you’re only delivering it to a few dozen beta testers or some internal folks who have volunteered to try things out. You’ll find that you’re a lot less concerned about failure if it’s done on a smaller stage, and you’re a lot less likely to fail if you’ve tested out your designs on smaller audiences first.
- Accept Some Imperfection.
With all that said, it’s important for teams to get over any fears of imperfection we may have. The truth is, none of our products will ever be perfect; moreover, in many cases, we don’t even know what perfect is. Obviously, we should not be shipping software that doesn’t work or is buggy or insecure to people. But we also don’t need to spend days or weeks obsessing over every pixel and every bit of polish if we’re not even sure that the feature is useful.
Think of all the hours spent grinding out gorgeous designs for products that nobody ever uses. Think of how much more useful it would have been to spend those hours testing ideas and finding a product that people actually want to use before putting the work into making everything perfect.
- Commit to Iterating.
Of course, if you embrace imperfection, your team should also be willing to iterate. Agility requires iteration, improvement, and refactoring. If you don’t go back to make improvements (or remove) imperfect features, then the purpose for which your product is designed in the first place is truncated. Instead of just continuously adding features you’re not even sure your users would like, focus on releasing in bits, getting feedback from users, and always be willing to iterate to improve features and ultimately the product.
To wrap it all up,
It’s one thing to have a big product vision, it’s another to follow an effective process to ensure reality is a success. Releasing in bits is basically about compounding value and continuously improving your product along the design process by releasing fragments of the product for testing. This is to ensure the final big product vision resonates perfectly with users. If you want to get more agile, your designer should definitely be one that will release your product in bits, get feedback, iterate more if needed, and then make improvements, all to ensure the end product is nothing but perfect.
Want to receive regular updates on Product design, Web design, UI/UX?
SUBSCRIBE to our newsletter Today!
.webp)
