One methodology to rule them all?

All design tools, artifacts, and processes are flexible as they are simply a means to end. Design principles, however, must be your red lines that constrain this constantly shifting adaptive path so it does actually lead to your intended goal.

Is there one production methodology to rule them all? All design tools, artifacts, and processes are flexible and simply a means to an end. Design principles, however, must be your north star that guide your work to your intended goal.For over a decade, we have been rigorously analyzing and creating better processes internally and within the broader digital agency landscape to create the right solutions for our partners.Naturally, this urge brings us to examine the best production processes for our work!

Choosing the Right Process to Support Productivity

As we all know, many mature industries, such as car manufacturing, rely on highly standardized processes. Companies can use these to create a roadmap, as they can predict rough costs, outcomes in terms of overall quality, and the required production time needed for each product unit they deliver to customers.

The teams handle planning, procurement, design, marketing, production, quality assurance, delivery, and maintenance work in silos. This rigid flow provides clarity and structure. However, it had certain flaws, including:

  • Long cycles without user input increase the risk of a costly error
  • Non-inclusive planning can lead to misalignment between teams as long release cycles progress.
  • A lack of innovation or new, good ideas, as the process in place, did not play well with quick changes and pivots.
  • Experts only owned up to their domain’s scheduled delivery tasks as a by-product rather than the overall vision. Instead of working in an environment that fostered cooperation, they were isolated and often felt misaligned with other departments and leadership.

The Rise of Lean Manufacturing

The Japanese manufacturing giant Toyota attempted to solve these problems with a new approach called “lean manufacturing.” It produced smaller batches, allowing better quality control and feedback loops from the teams encouraged to sit close and collaborate. They eliminated waste by eliminating their standing inventory.

Toyota continuously improved and delivered products that resonated with the target audience’s purchase criteria and thus retained them easier. With a higher-quality product, Toyota could also offer more comprehensive maintenance guarantees, which were also less costly to the company due to the newfound loyalty of its customers.

Now, why does this matter to us?

In the early 2000s, the adoption of enterprise-level SaaS products, digital applications, and platforms boomed as server capacity, bandwidth, processing power, device sizes, and networks evolved. This boom also started to have behavioral effects on people’s perception of trust in the internet. It also triggered their growing reliance on technology to satisfy their essential needs and wants.

In return, large corporations and tech startups compete to supply the correct solutions faster and constantly innovate new ones. However, getting to that “Aha!” moment with a product for the mass market is expensive. Many companies bled millions and sometimes billions to get it right and failed.

These environmental pressures required a new production process than “throwing everything at the wall and seeing what sticks.” And once again, the not-so-distant tech boom provided a ready model.

A similar scenario to car manufacturing started in our field—the switch from Waterfall software development of the 1070s to Agile development with lean principles at its heart.

Inside the Waterfall Development Process

In the Waterfall development process, the product design team (which did not have that title at the time) started a project by doing the following:

  • Conducting preliminary stakeholder and heavy user research
  • Doing an independent competitive analysis
  • Creating the information architecture depicted in flow artifacts
  • Applying the branding
  • Designing the UI for each key page
  • Sending the project to development along with annotated wireframes (blueprints with business rules, content types & interaction design details)

Once we completed the development, we would perform QA and launch.

Things were not broken. The Waterfall model worked well for projects that were smaller in scope, with well-defined needs, and with low-risk functionality. It was easy to track and report for us and our clients. But there was room for improvement to be faster, more flexible, and more risk-averse, especially for projects with a grand vision, no clear roadmap, or certainty around product-market fit (PMF).

The Drawbacks of the Waterfall System

Even the “best” industry best practices don’t cover every contextual instance of a problem; they can change over time. They are, in most cases, heuristics rather than commandments. Getting things wrong can break your budget and extend your timelines drastically.

If the product has already been brought to market and the feedback from consumers is quite bad, fixing your product will cost you much more than it did to develop and produce it the first time around. Worst of all, without a production process to implement these changes, you will have to repeat this process.

The agile development manifesto aimed to capture the most efficient process and principles to address these challenges. It had borrowed many tenets from Toyota’s lean production process: industrial designs, rapid prototyping, and iterative design flow, as well as the irrefutable reality that a degree of flexibility to shift and pivot as needed inherently is a part of software development.

The typical agile process looked something like this:

  • Produce working software fast
  • Develop in small batches with 2-week sprints
  • Focus on creating functionality around a user story with clear acceptance criteria
  • Test early and frequently. Get it out of the building!
  • KISS (Keep it simple stupid), focus on simplicity
  • Emphasize close collaboration and time-boxed scrums between team members and clients rather than heavy documentation

The agile process welcomes changing requirements no matter how late in development and creates an inclusive environment for innovation and new ideas. These insights are impossible to gather at the beginning of a project fully.

Importantly, the agile development process facilitates constant incremental improvement toward a polished product. Developers could groom and update product backlog regularly to ensure the right features are built-in on the right priority at a cost-effective price.

The Rise of the Minimum Viable Product

Agile worked great for the unique demands of software design, but what would come after? Enter LeanUX by Jeff Godhelf and Josh Seiden.

On the relatively younger UX design front, things were also changing. The old waterfall-like design process with its superstar creative directors with overworked production stooges was giving way to a hypothesis-driven, build-measure-learn cycle focusing on testing an MVP (minimum viable product) with real users.

Startup circles quickly adopted the movement. In a nutshell, the new approach looked like this:

  • Replace documentation with collaboration
  • No rockstars, no biases
  • Qualitative and quantitative data are king
  • Smallest possible output increment to prove the hypothesis of the product
  • Talk to stakeholders and look at any existing data around the user, analytics, competition, and past attempts
  • Frame the problem being solved around desired outcomes around solutions
  • Create proto-personas
  • Evaluate risks and priorities, determine MVP scope
  • Build an MVP and test it with users, measure results, optimize accordingly, repeat loop

Later, as there was a natural fit between agile and lean UX, Agile UX was born to work seamlessly with the rhythm of Agile development. Our team at Junction Design was one of the certified pioneers of Lean & Agile. We believe strongly in the principles and saw improved speed, flexibility, risk management, quality, and product-market fit results.

Flexibility Meets Efficiency in the Google Design Sprint

We are excited to announce that in the past year, we have adopted a turbo-charged version of product strategy, design thinking, and lean and agile workflow called Design Sprints 2.0.

The original performance of this proven methodology at Google Ventures was written by Jake Knapp and optimized even further after countless sprints by the awesome folks at AJ & Smart.

Here’s why we’re so excited about it:

  • Six months of agency work can be done better in under a month
  • The process adopts all the principles and tools that make lean and agile work (better team alignment, elimination of risk, more collaboration, better individual and team creativity, guerrilla research, and rapid prototyping, eliminates wasted hours on heavy documentation)
  • The process creates an engaging, equalitarian, and rapid decision-making loop
  • All stakeholders have a voice, but ultimately a decider commits to a goal.
  • All activities are timeboxed for efficiency, decreasing complacencies, wasted time, procrastination, and analysis paralysis

As all projects have unique needs, we modify parts as needed and complement them with other tools in our arsenal, never compromising the core building blocks and concepts.

We can’t stop talking about this process! Drop us a line to discuss how it can help your projects, what a workshop with your team would look like, or questions about facilitating training and hiring assistance.

We will post more detailed articles outlining our thinking at Junction Design, focusing heavily on Design Sprint principles and how we apply them to almost any problem our partners seek to solve. Join us in our next blog as we explore more ways to implement them!