The Urban Legend of a Universal Product Design Process

18.07.2017 | 7 min read

Managing a product design process may sound simple, but don’t be fooled. There are many ways to manage a project and observe the progress in the design process.

I’ll try to cover the most popular approaches to the product design process within an App Development community and Startups. Before I dig into the details of product design process, let me state a simple fact you should have in mind: Design balances on the verge of technical constraints, user needs, and business goals. Once you know that, everything I talk about in this post will be much clearer to you. If you’re a knowledge junkie and want to find out more, check out Digital Product Design ebook for some extra reading.

Now, let’s get down to the business and see how design works in organizations and products.

Blossoming in Agile

The Agile Manifesto brought a lot of changes in Product development. The shift from a get-it-all-done-at-once approach to a more let’s-ship-it-and-improve-it approach has added a certain leeway into design. We have now switched from keeping our fingers crossed that everything goes right to knowledge-based decision making.

Even though you can put an enormous amount of effort into preparations – market and user research – being right is not always a certain. Learning is a step-by-step process, where at each step you have an opportunity to discover something new or cross out something that no longer applies.

And that’s what release cycles give you. Time. Time to retest your assumptions, make sure that you haven’t missed anything or can’t do something even a little bit better. Agile requires a set of iterations to make sure that your Client has a competitive advantage.

But how much design can you pack into a two-week sprint?
Well, a lot.

At its base, every Agile approach is a contract between the development team, the Project (Product) Owner (Manager) and the business. If you need more time for research, you can negotiate putting it a sprint prior to the development. If you need separate time for improvements, you can negotiate starting a dual-track Scrum.

Agile isn’t moving tickets in Jira. It’s about building great things from smaller pieces.

Even though there are plenty of approaches in Agile (with Scrum and Kanban being the most prominent ones), the method itself doesn’t mean much without an effort made by the entire team. A push for releasing better increments – with clear requirements and necessary research to back it up, is something that you and your team can strive for together.

Design blossoms in environments with great communications and constant contact between the business and developers. And it’s also what Agile has been built on. The constant need for building and releasing increments forces you to create great things that can be developed in a specific timeframe.

When to use it: if you are already working in Agile. Try to negotiate including more user feedback, push for more time for a better design. Talk more with developers about what they need and how you can work together better. Talk to your stakeholders and try to include their thought into what you are designing. Great design isn’t a standalone process, it’s a team’s effort.

When not use it: if your company and your team aren’t ready for it. Agile is mostly a mindset – a need for doing things quickly and smoothly. It requires a lot of trust between the business and team members. And it sometimes may take time.

Experimenting in Lean

The Lean Startup book by Eric Ries has been out for a couple of years now. Lean heavily relies on three principles:

  • Build
  • Measure
  • Learn

Lean gives designers a lot of freedom when it comes to delivering the final design. You can spend time researching in Learn, designing in Build and using either remote or in-lab testing in Measure.

The principle of Lean is a constant need of validating. You create hypotheses, build and test them and make sure that you got them right. Driving a business by learning is an approach that allows you to avoid guessing whether what you got was correct – it gives you actual data to back up your assumptions.

In Lean, there are plenty of ways that the Designer can use to try to shape the product. They can use User Research to test a hypothesis before they make it into the product or to test whether a solution is working. They can run A/B tests or design alternative versions to check if something can be improved. They can also run Generative or Market research to get a further understanding of the target audience. The possibilities are endless and mostly rely on the ability to form a working hypothesis.

A business that heavily relies on testing and measuring actually shortens the gap between your designs and the market.

In case the early adopters don’t engage enough with the current version of a feature – you can always reshape it, optimize it and release it within a short cycle. In case the new engagement ever drops, you can always repeat the process.

You can also use the Lean principles to reduce waste – hours you would otherwise spend building something that has little to no market value. It doesn’t only increase the chances of you not doing pointless work, it also increases the overall chance of success of the entire product.

When to use it: when you are a startup that heavily relies on data and is willing to try going Lean. When you want to build something small and then improve it as you go.

When not to use it: the techniques contained in the book are fairly new. There is no optimal way of running a Lean Startup. If you are not willing to optimize your own process, Lean might not be for you.

Prioritizing in a Fixed Scope MVP

The Fixed Scope is not really as tough as people make it out to be. Almost always it’s a set of features that have to make it onto the market to test how the product will perform. And usually, the product has a very solid stance in the reality of said market.

In this case, the focus of design is to make the product as usable as possible. The efforts of the designer should be focused on delivering high Usability prototypes that can be implemented within a timeframe of the product. Of course, the effort can include a lot of usual techniques: Workshops, User Research, Interviews.

In the case of a Fixed Scope MVP, most of the optimization comes after the release.

When the Client starts getting some traffic, you can verify the business assumptions and cooperate on improving the overall experience of the product. You can plan out the roadmap for the next releases and set up.

What makes Fixed Scope MVP fun is the fact that once it hits the market, it’s usually a well-catered set of features that can be used to improve a very specific business need. While giving the impression of a complete product, it’s usually only a core of the product that can be later improved by implementing a new set of features.

Designing a Fixed Scope MVP is a challenging process. It usually requires you to prioritize functionalities, not visual aesthetics. But, at the same time, it’s very rewarding to see how the product will fare with its competition.

When to use it: a Fixed Scope MVP is usually a business decision. You can help with prioritization of certain features and have insight into what should be delivered first. You can also perform market research and benchmarking to figure out the scope of the project.

When not to use it: in case you have time and resources to pick another approach, you can try using Agile or Lean to have more time for improvements and User Research.

Delivering the fullest value

While the process itself is quite important to the development of Product, what’s more important is the reasoning behind the choice and application.

Even the biggest and best organizations can struggle with the proper application of Agile, small Startups may have problems with measuring in Lean and Fixed Scope may include some wasted effort.

But it can change easily. Developing Software is mostly a learning process that allows you to draw insights and apply them in the development of next features. You can easily apply knowledge that you learn from your team members, improve communication channels and iterate some more on core features.

While the process of getting an app on the market is getting lower yearly, the process of gaining knowledge is a lifetime experience.

This article was featured in our ebook, Digital Product Design for Stunning Web and Mobile Apps. Download it to learn more about design from skilled and experienced pros!

You may also like these posts

Start a project with 10Clouds

Hire us
cookie