Design Processes, Implementation Phases and Creating an MVP
The topic of MVPs recently came about in a discussion with fellow Designers and former co-workers. Our discussion was prompted by the question: Does an MVP compromise the scope of a solution that is achieved during the Design Process, or is it simply an edited version of a potentially larger narrative, which has been backlogged, and will eventually see the light of day. Also on this topic, we discussed how the Implementation aspect of a Design Process, and particularly its quality, can enhance the experience of a solution or on the opposite side of the spectrum, completely underwhelm and undermine it (and just as a friendly reminder, Implementation is a part of the Materialization Chapter of the Design Thinking process). This article showcases two examples I have personally been fortunate enough to have worked through, which illustrate how different approaches towards MVPs can and will actually influence timelines of product delivery to market, the quality of Implementation associated with it, and how the Design Process itself was deeply ensconced in all these events.
Design Processes and MVPs. Wikipedia as usual provides a succinct definition of what constitutes an actual MVP: “A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. A focus on releasing an MVP means that developers potentially avoid lengthy and (ultimately) unnecessary work. Instead, they iterate on working versions and respond to feedback, challenging and validating assumptions about a product’s requirements.”
Interestingly enough, the definition of MVP never refers to Design or its process altogether, choosing to focus on the implementation aspect of a solution that has been devised. I’ve written previously on the topic of Design Thinking, Iteration Cycles and generally going through that process with the intent to grasp and establish a solution/path which is solidly constructed. At its core, this process and methodology, represents the convergence of multiple points of view hailing from varied Team Members and Departments, but also and just as crucially important, gathers all the input collected from the research that has been performed. I’ve also alluded to the topic of research in previous articles, but it specifically entails and includes analytics, usability testing, customer interviews, gathering of user review and ratings, competitive analysis, market canvasing/triaging, all of this assessed, compiled and documented, obviously sustaining the iterative cycle and refinement process.
The goal is of course to understand customer/user journeys, the jobs to be done, identify patterns (both behavioral, but also operational tied with software solutions, all of this married with gaining a clearer vision of expectations) and generally speaking, address the most important focal problematic points which need to be solved. Typically the output of the Design Process up until the Explore path, allows for these scenarios to be uncovered, tested and gain insight and validation from users and testers. However when it comes time to defining an MVP and implementing a solution, there are several factors that are usually taken into consideration, namely timelines, cost of development, availability of resources, sales strategy, brand positioning, among many other factors. All this to say, typically not every single feature or flow that is uncovered during the process is implemented as it was outlined, tested and refined. This does not constitute a fallacy of the Process itself, it merely surfaces the inherent aspect of being flexible and malleable, qualities that both Design and Designers need to always have in their minds.
The MVP is, for the lack of a better definition & analogy, a version 1, a first chapter of something that is being progressively built, of an ongoing narrative. A product has a life span, and that is ever more present than in software design, where most teams are agile, and just as importantly, where products and solutions keep evolving as a direct result of actually being used by clients/users. I’ve been fortunate to have worked & contributed to many products, alongside an array of very talented teams with very different timelines, but for the sake of illustrating this article, I’m going to provide two very distinct examples of how MVPs and Design Processes were tackled.
The first one, is a rather recent example of a Progressive Web App whose incubation process and Design Process was swift and agile. The timeline for this application, and for its first release was 4 months. The Design Process which my team embarked on, produced a series of outcomes and artifacts which informed the direction in which the first release was going to go. This MVP was a result of several discussions, but included aspects such as client feedback, time to market, implementation cost, resources, brand strategy, seasonality, to name but a few factors. Some of the flows uncovered during the process were backlogged and new directions were devised and tested, in order to effectively marry the MVP logistics. This is an example where the Design Process and MVP establishment were collaborative partners and the integration was seamless.
The second example, pertains to an application and even more so, to an ecosystem which was developed within a far more considerable time frame (quite a few years of incubation and also investment). This product had a lengthy Design Process, since it was an entirely new Product Line which demanded a thorough research process, across multiple geographical locations, not to mention it had ties with different product lines and also hardware/industrial design components). That being said, this application also had an MVP, which upon its release was promptly analyzed, triaged and assessed. Understanding the metrics sustaining the early adoption was essential, since there was already a series of subsequent features and enhancements which were being orchestrated to be released. Once again, the MVP was a part of longer Product Design journey, which ultimately aimed to pierce through a new market segment and expand the brand’s footprint. MVPs that are effectively delivered, should be a convergence of points of view and one of the outputs of the Design Process itself, even if they are indeed a bashful version of what the solution is going to be. That effectiveness is deeply tied to them ultimately remaining faithful to the integrity of the solution that is being delivered.
Implementation Processes and Quality of Output. One of the most important chapters of the Design Thinking Process is the Materialization chapter. Implementing what is uncovered in the previous chapters is a fundamental aspect of delivering a solution that is useful, usable, credible, findable, desirable, accessible and credible. The virtuosity of good implementation can include automation of processes, machine learning integration, AI paradigms, enhancing motion details, to name but a few, but all these have a common narrative thread: quality married with accountability. Whatever is materialized and implemented should always be consistent with what is uncovered, tested and prioritized in the previous chapters of the Process. Whenever the implementation fails to represent what was uncovered, the process itself is a failure. The integration of all these diverse teams, is done with the sole purpose of bringing insight, shared ownership, but also awareness towards what is being conceived, in order for everyone to understand where constraints lie, and overcome them accordingly. The necessity of having this coherence of efforts and ultimately outputs, throughout the entire process is fundamental to deliver solutions to the market which are impactful for the business as well as the users.
Reality check. Shaping MVPs can induce a fair amount of stress on teams, particularly when team members fear that what was uncovered during the sessions is being abandoned. Hopefully as teams ingratiate themselves and their efforts, they realize that the narrative that is being shaped, is a continuous one. What comes next after the release is driven by momentum and continuing to tell a powerful story. The question is always — are we saying enough with an MVP, and will it be impactful enough for clients and customers. The core aspect of the process that teams always need to keep present, is essentially the problem statement that sustains the solution being edified. Is that problem being addressed, is the solution presented relevant, credible and distinguishable enough from what is already on the market. These are topics which need to be reflected upon when devising MVPs. When it comes to Implementation phases, it’s always important to keep in mind topics of accountability, quality triage, and finally assessing if the process itself and the output produced, is actually marrying with the statement an Organization plans to unveil in the market. Independently of being an MVP or otherwise, having a robust and solidly conceived product/feature solution carves out a path of excellent for whatever endeavor that is established, and will likely retain users and clients attention and retention.
I’ll conclude this article with a quote on the topic of quality, from the great Aristotle:
“Quality is not an act, it is a habit.”
