One methodology to rule them all?

All design tools, artifacts, and processes are all means to end and can be modified as needed. One thing that remains constant on every project is the need for the right balance of flexibility versus structure.

Hey all, it’s Genco from Junction Design.

For little over a decade, we have been rigorously observing what works, what is a pebble in our shoe and how can we create better processes internally and within the wider digital agency landscape in order to create the right solutions faster for our partners.

Let me start by saying that have worked with various methodologies over the years either because we believed it suited a particular project’s needs, it was deemed as the widely accepted best practice or simply our clients asked us to in order to be compatible with their internal processes so the purpose of this post is not to call out any company or agency on their choice of methodology or even ”processes will only box us in dude, we’re a startup, we gotta move fast with no defined structure“ freestylers out there (Ok, yea, that was a call out but only because I genuinely think you guys will enjoy the rest of this post :).

The actual purpose is to share with you guys where we currently are with our own processes, why it makes sense to us and why we encourage our peers and clients to try it out.

Ok, let’s dig into our summary…

As we all know, many mature industries such as car manufacturing have come to rely on highly standardized processes where they can create a roadmap as it can predict rough costs, outcomes in terms of overall quality and the required production time needed somewhat effectively for each product unit they deliver to customers. Planning, procurement, design, marketing, production, quality assurance, delivery and maintenance were handled by assigned teams often in silos.

This rigid flow provided clarity and structure, however it had certain flaws, long cycles without user input increasing the risk of getting things wrong, high cost of making a change down the pipeline as it meant going back many stages and waisting time as well as resources, various teams often not getting a chance to be involved in earlier planning stages and losing alignment with other teams as long release cycles progress. Innovative and simply good ideas in the name of efficiency and quality were just not heard on time or not at all as the process in place did not play well with quick changes and pivots. As a by-product of this, experts only owned up to their domain’s scheduled delivery tasks rather than the overall vision as they were isolated and often felt misaligned or resentful towards other departments and leadership.

This was later evolved into a methodology called Lean manufacturing coined by Japanese manufacturing giant Toyota. It had smaller batches in production as it allowed quality control and feedback loops from the teams who were encouraged to sit close and collaborate. They eliminated waste by not keeping a standing inventory. Continuously improved and delivered products that resonated with the target audience’s purchase criteria and retain them easier as the product was high quality, to begin with so maintenance guarantees can be more comprehensive and less costly to the company and consequently to its loyal customers.

Now, why does this matter to us?

In the early 2000s, enterprise-level SaaS products, digital applications, and platforms started to boom exponentially 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 on the internet and triggered their growing reliance on technology to satisfy their key needs and wants. In return, large corporations and tech startups alike found themselves in steep competition to supply the right solutions faster and innovate constantly. As creating a product that achieves market fit with high retention rates, a clear AHA moment to build rapid growth upon towards a Billion dollar IPO or simply dominating market shares is not a trivial task and came with serious financial risk as many needed up and till continue to bleed millions and sometimes billions in the pursuit of getting it right.

In fact, a very similar scenario to car manufacturing started to happen in our field. The switch from Waterfall software development of 1070s to Agile development with lean principles at its heart.

The Waterfall way of doing things for us, the product design team (which did not have that title at the time) did some preliminary stakeholder and heavy user research in the very beginning, did an independent competitive analysis, created the information architecture depicted in flow artifacts, applied the branding, designed UI for each key page and sent to development along with annotated wireframes (blueprints with business rules, content types & interaction design details). Once the development was completed, we would perform QA and launch.

Things were not broken, it actually worked pretty 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 especially for projects where there is a grand vision with no clear roadmap, nor certainty around product-market fit (PMF), there was definitely room for improvement to be faster, more flexible and more risk-averse. After all, we all have biases, industry best practices often don’t cover every contextual instance of a problem and they can change over time. They are in most cases heuristics rather than commandments. Getting things wrong can break your budget, extend your timelines drastically. If the product already met its assumed users and the feedback is quite bad, getting them back on the product will cost you much more than it did the first time around and worst of all without an alternative process, you will have to repeat this process all over again.

Agile development manifesto was looking to capture the most efficient process and principles in order to address the issues we mentioned. It had borrowed many principles from Toyota’s lean, 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:

  • Get to working software fast
  • Develop in small batches with are 2-week sprints that drive from functionality around a user story with a clear acceptance criteria
  • Test early, test frequent, Get it out of the building!
  • KISS (Keep it simple stupid), focus on simplicity

Close collaboration and time-boxed scrums between team members and client rather than heavy documentation
Welcome changing requirements no matter how late in development, create the environment needed for innovation and new ideas, insights which are impossible to fully gather in the beginning of a project.
Constant improvement in increments towards a polished product
Groom and update product backlog regularly to ensure the right features are built-in the right priority

Lean UX by Jeff Godhelf & Josh Seiden

On the relatively younger UX design front, things were also changing from waterfall-like processes and superstar creative directors with overworked production stooges to a hypothesis-driven, build, measure, learn cycle focusing on testing an MVP (Minimum viable product) with real users. It was a movement that was quickly adopted by startup circles.

Remember the first time we read the book, during a visit to the startup hub General Assembly in Manhattan. It was lying on a desk. quickly glanced at it and rushed that night to Amazon to buy it as it was clearly a step in the right direction. It was talking about all the problems we were looking to solve. It had lean & agile principles baked in.

In a nutshell, it looked like this:

  • Replace documentation with collaboration
  • No rockstars, no biases
  • Qualitative and quantitative data are king
  • Smallest possible output increment, just enough to prove hypothesis focused around the AHA moment 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. Create your business hypothesis and desired outcomes around solutions
  • Create proto-personas
  • Evaluate risks and priorities, determine MVP scope
  • Build an MVP and test with users
  • Measure results, optimize accordingly, repeat loop

Later on, 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 pioneers of Lean & Agile (got our leadership certified for product owner and scrum master roles) in Canada as we believed strongly in the principles and saw improved results on all fronts again in terms of speed, flexibility, risk management, quality, and product-market fit.

To say the least we built a successful business by working with Agile teams and creating countless MVP based products with like-minded innovators and still use its design & framing tools as needed.

Flexibility meets efficiency – Enter The Google Design Sprint

We are excited to announce that in the past year we have evolved our process at the studio to include a turbo-charged version product strategy, design thinking, lean and agile workflow called Design Sprints 2.0. Her his why we are so excited about it:

  • Typically 6 months with of agency work done better in a month or less
  • Adopts all the principles and tools that make lean and agile work (aligns all team members, eliminates risk, highly collaborative, includes individual and team ideation, guerrilla research, and rapid prototyping, eliminates wasted hours on heavy documentation)
  • Creates an engaging, equalitarian and rapid decision-making loop, ensures everyone is heard but ultimately has a decider to commitment towards a goal.
  • Timeboxes all activities for efficiency and decreases complacencies and wasted time procrastinating, analysis/paralysis.

As all projects tend to have unique needs, We modify parts of it as needed and compliment with other tools in our arsenal but ensure the core building blocks and concepts are not compromised.

The original version of the tested and proven methodology at Google Ventures was written by Jake Knapp and optimized even further after countless sprints by the awesome folks at AJ&Smart. We can’t stop talking about it! Drop us a line if you wish to chat about how it can help your projects, what would a workshop with your team look like or questions about facilitating training and hiring assistance.

We will be posting more articles outlining our thinking at Junction Design in detail focusing heavily on Design Sprint principles and how we apply them to almost any problem our partners are looking to solve.

Until next time.

Cheers everybody!