Why traditional design processes break in B2B SaaS

Modern day design processes promote an iterative discovery technique wherein solution concepts are prototyped, tested, and improved until a point of convergence is reached. The inherent assumption is that the problem definition and product requirements don’t change during these iterations. B2B SaaS is a unique beast, and although the existing design process has been proven to be immensely successful for products in general, this particular segment of products poses some unique challenges that may call for some evolution.

Status Quo: The Double Diamond

Present-day product design processes go through the following phases:

This is popularly known as the “Double Diamond” creative design process, and is well described here.

Key characteristics?

  • Going wide, going narrow: to ensure all possible design options have been considered and reduce the probability of rework.
  • Discover-define phase (diamond #1): involves researching the market, developing personas, and scoping the definition of the problem (potentially ending up with a PRD).
  • Iterating on the solution (diamond #2): involves multiple iterations of prototyping, getting feedback, and going back to the drawing board. Since the problem is clearly defined, the task is to iterate in the solution space.

With the right success metrics set up front, one can visualize how this process would finally culminate in a refined prototype that scores well when tested with the target audience. While this sounds reasonable, in SaaS products, especially those serving other businesses, things are a little more challenging.

Challenges in B2B SaaS design

1. Evolving requirements

SaaS products are characterized by high velocity. Your competitors will continuously improve their products, new competitors may be born at the blink of an eye, and what’s more – your customers may not value things today in the same way they did last week. Product-market fit can’t be assumed to be constant, and the good product managers are always re-evaluating their previous conclusions on what the underserved needs of the market are.

Bottom line – product requirements can and WILL change over a relatively short period of time. Designers who swear by the Double Diamond may find themselves in a tough spot when the problem definition has changed while the team is in the middle of the concept iteration phase.

2. Customer data may be harder to come by

It is always more challenging collecting product usage data for a B2B product versus a consumer product. Businesses have more sensitive and critical data that they want to protect. For a B2B product manager, the best qualitative data about customers comes from limited customer interactions at conferences and events, the occasional survey that most customers won’t have the time to fill out, and a few passionate early adopters. There are other channels to find generalized information about the target market and current usage trends, like talking to colleagues in sales, solutions, and customer success, but these are high level inputs and at the end of the day, to a reasonable extent, are generalized opinions.

So for the design team there will be constraints, assumptions, and decisions that will either be blocked on the next annual company event, or will need to be taken by way of best judgement. Some of them could even change or evolve over time, as the product team gets more opportunities to learn about the market. Ruminating too hard on assumptions about the problem statement could risk stalling the project or keep the product team waiting an unreasonable amount of time before the project actually gets going. “Convergence” may never be reached. So then, should it be the goal?

3. Developer productivity is through the roof

In theory, new code can get rolled out every minute in SaaS. Software teams are trying harder than ever to decouple software components so that various parts of a product can be updated independent of the rest. This gives developers and product teams (and companies) the ability to move at the speed of light, and deploy iterations of a product to segments of the market to test it in the real world. This causes a tremendous amount of organizational pressure on design teams to deliver high fidelity mock-ups quickly to enable the product team to deploy and test.

Designers must ensure that a new roll out is backward-compatible and does not drastically change the way existing customers use the product, and they must do so in a way that doesn’t hold up the rest of the product team. Perhaps it is not ultimate convergence that we are after for any single iteration. Perhaps the topmost priorities of backward compatibility and consistency are the only hard requirements for an individual roll out, as the product team starts to compete with time.

4. Increasing complexity of products

We are in the era of Big Data. Every single product is affected by it, and simplicity as a design principle is more legit than ever. Business needs that were too complex to serve in the past are now at the forefront of opportunities being pursued. Right from infrastructure monitoring to customer success tools, there is no one-size-fits-all design solution. This makes it harder to “simplify” design, which in turn leads to designers leaning toward optimizing for user stories in the problem definition. I have always found it challenging to express to a designer that while we want to address today’s user stories with high quality design, it is as important that the design is “open” to addressing other user stories tomorrow. The good designers will focus on information architecture, but even then care needs to be taken to make sure the product isn’t optimized for user stories in a backward-incompatible way.

Designing to be extensible

To meet the demands of the B2B SaaS market, could the design process be designed in an “extensible” way? By extensible, I mean attacking the design problem in slices that are complete in themselves, yet make as few assumptions as possible. Of course, each slice must account for a finite set of basic requirements (for example, a user should not have to interact with the product differently across versions to get the same task done) and should provide a good experience to the user in getting the targeted jobs done. The key is to stop optimizing early, so that future user journeys can be seamlessly incorporated in a later release. This goes hand-in-hand with quickly delivering high fidelity mock-ups so the product team can expedite the release and come back with real time feedback.

To summarize, frequent iterations with extensible high fidelity mock-ups could:

  1. allow product teams to implement in parallel
  2. while PM and design experimentation is ongoing (to test market fit and usability respectively)
  3. at the cost of high fidelity mock-ups and foregoing immediate optimization opportunities.

This would enable the product team to release more often, test assumptions early, and fail fast.

High fidelity mock-ups drive interest among stakeholders who then are more incentivized to fund the project, as well as team members, who ultimately determine the success of the product. Note that any attempt of an extensible design process must be complemented with in-depth user personas, goals, and stories in order to have a shot at being successful.

While the world of product managers and designers are yet to design the most optimal process for B2B SaaS products, it is clear that this is an area that can use some thought. My designer and I are experimenting with the extensible philosophy, and we continue to “go wide” and explore other solutions as we progress. What does your B2B SaaS design process look like? Share your thoughts in a comment!

Leave a Reply