Designing the Future

Here’s what’s on the minds of my colleagues when we got together back in April 2019 to think about what our lives might be and feel like 30 years from now, and what our work and business might be like.

I’ll have more to share on my reflection, but the first thing I learned was how hard it was for us to empathize with our future selves. Futuring is hard, but it’s important and necessary work if we don’t want to end up living in scenarios our future selves and families wouldn’t want.

The Design Pyramid – draft

Screen Shot 2019-05-23 at 10.39.21 PMJesse James Garrett’s Elements of User Experience has guided me in my practice for so long, it feels like a comfortable second skin. I continue to teach this model to new generations of designers whom I’ve had the privilege to coach and mentor.

For some time now, I’ve layered on my own flavour based on my personal field experience. I’ve drawn my design pyramid many, many times for different audiences (designers, product managers, business leads)…and in several different ways. At long last, I’ve gotten tired of drawing the thing over and over again, so I thought I’d commit a bit by publishing on my blog. For one thing, I can finally stop drawing it, at least for a while. For another, I’m curious as to how my own thinking will continue to evolve.

This is meant more for my own thinking and as a spark for those who are interested in casual intellectual conversation. It’s by no means meant as an improvement or commentary on Jesse’s work. Not by a long shot. It’s merely how I’ve used Jesse’s framework and forked it within and for my own practice.

design pyramid v1

A Framework to Design for Impact

Design serves a purpose, solves a problem, addresses a need. This gives us the natural boundaries to create a design framework that we can use repeatedly to deliver results. To make an impact as designers, we must be motivated by delivering results. The good news is, there’s a repeatable process we can use that many designers before us have proven.

To design for impact, we need answers to three main questions:

  • Whose problem is it?
  • What’s the real problem we’re trying to solve?
  • How will we know if we’ve succeeded?

Whose problem is it?

Our goal here is to build empathy: for the business, for customers, for the technical landscape. We’re seeking to understand what other people are going through and what the system is capable or incapable of in order to solve problems and find solutions. This desire will drive our commitment and creativity. But we don’t want to get so immersed that we lose objectivity.

We need to walk that mile in someone else’s shoes, then put our own back on.

To understand the problem we’re trying to solve, we need context: business and customer context, as well as any delivery constraints. Often, business stakeholders ask for a feature to solve a customer problem when, in fact, it’s a business problem. Or worse, a problem that customers experience is actually one that’s created by the business, rather than a customer need.

Understand the business context

Why is the business asking for a feature? They almost always frame it as a feature rather than a problem. It’s our job as designers to de-construct that feature into a problem statement in order to unpack the motivations.

  • Why is the business asking for the feature / problem to be solved in the time frame that they’re asking?
  • Is there competitive pressure?
  • Is it a first-mover advantage that the business wants to take advantage of?
  • Is that team’s funding dependent on this problem being solved?
  • Etc.

For every “crazy” request, there are usually deeper reasons. Find out what those reasons are. As designers, we’ve been conditioned to have empathy for users. Go one step further: build empathy for stakeholders. This delivers a one-two punch: first, building empathy for stakeholders help us unpack the reasons behind the seemingly crazy requests, and more important, the empathetic relationships we build foster mutual trust and may actually empower us to dial down the crazy.

Understand the customer’s context

Dig into the motivations behind the requested feature or the problem statement from a customer’s perspective:

  • Why are customers asking for the feature?
  • What are the underlying motivations?
  • What conditions generated the problems that customers are experiencing?
  • Could the problem at hand be eliminated by resolving an issue upstream?
  • Etc.

Understand the delivery constraints

Often, especially in enterprise settings, the most usable/user-friendly/customer-centric solution is not feasible for a variety of reasons:

  • The existing antiquated technology infrastructure can’t support the solution
  • The solution runs counter to the organization’s business model
  • There’s no business appetite to pay for the ideal solution.
  • The technology needed to support the solution doesn’t exist right now
  • Etc.

We can sit around and bemoan the delivery constraints, or we can find ways past or around them. It’s not helpful to think in terms of ideal versus compromise. The real world is all about costs and benefits, pros and cons, give and take: our job as designers is to find a balancing point that delivers a user experience that the business can feasibly fund and that engineering can technically enable.

What’s the real problem are we trying to solve?

The business, customer, and technical context we gathered gives us the data we need to triangulate the real problem we’re trying solve.

The project might have started off with one request, but in digging behind the request, we may uncover something deeper. True story: once upon a time, the business asked for an ‘download PDF’ feature, but digging deeper revealed what customers actually needed was a spreadsheet they can manipulate for custom queries they need to run. Without the research, we would’ve agonized over a ‘download PDF’ feature that included trying to figure out how to message customers whose PDFs take 24 hours to generate, when all they really needed was a .csv export. In fact, because a PDF is a static artifact, customers are copying and pasting the data from the PDF into a spreadsheet.

Defining the right problem is more than half the battle. We can’t reliably deliver an effective solution if we focus on the wrong problem.

How will we know we’ve succeeded?

Building in a feedback loop is critical to the success of any design solution.

  • Did we frame the problem statement correctly?
  • Did our solution create any new problems?
  • Did our solution solve the problem?

Always be testing

In the problem framing stage, we talk to customers to validate our problem statements. We believe our idea Y solves problem X. First, we need to be sure that problem X represents a real business opportunity. Many ideas arise out of problems we’re solving for ourselves. For our solution to be financially viable, we need to find out if enough other people share the same problem and are willing to pay for a solution. In other situations, businesses create problems for their customers and then try to sell a new solution for those problems; is it possible to eliminate the original problem to begin with? Perhaps the real problem to be solved is further upstream.

In the solutions framing stage, we test our solutions to identify any usability issues before we release our solution into market. If our solutions are complicated, hard to use, or otherwise unusable, we haven’t actually solved the problem. Testing solutions before we commit the time and resources to make those solutions is a gut-check: the goal is to identify as many usability issues as possible. Better that we discover and address usability issues than to have the support team be overwhelmed by customer complaints.


In the delivery stage, we need to bake measurement points into our solution to feed us the data that tells us whether our solution worked. These measurement points can range from specific things we want people to do, such as calls-to-action, to behind-the-scenes tools such as heat map and click analytics tracking.

Often, we release and walk away. As designers, we should hold ourselves and our work more accountable. From a career perspective, holding ourselves accountable gives us credibility. If we work as consultants, holding ourselves accountable is also good for business: it presents natural opportunities to check in with clients after the project is done.


If we can’t answer the following two questions, we need to go back to problem-framing:

  • What do we want people to do?
  • How will we know if they’ve done it?

Being clear on what we want people to do helps us understand how to measure success. Maybe it’s “sign up for our services”;  “buy our products”; “create better onboarding so that customers don’t have to waste time calling us for support”. Sometimes, it can even uncover business gaps or opportunities: for instance, if we want people to go to a brick-and-mortar store to complete an action, we need to be prepared to handle the increased store traffic or risk alienating hard-won new customers.

Easier said than done

Three steps. Is that all? Yes, these are admittedly three giant steps. And they’re not easy either. However, they offer a structured, foolproof way to get started. For projects that are complex, this 3-question design framework can help us manage the chaos. For projects that appear simple, this 3-question framework can sometimes expose underlying complexities early enough for us to organize around. It’s a framework that has served me well and helped me design for impact.

Held Hostage: the Forgotten Users of Software for Business

I had to write down step-by-step instructions so I could remember what to do.
Usage was incredibly frustrating. The dark green with black text is impossible to read at a glance, and the contrast with the bright yellow is really harsh if you’re trying to find something. You can resize the columns and sort by the columns, but resizing and sorting needs to be done every time you come back to the screen. So the filter option is the only realistic option.

Meet Valerie and Michelle – two individuals I happen to know.

I reached out to them on Facebook. They don’t describe their experience with Facebook in the same way.

The thing is, they’re still Valerie and Michelle whether they’re using software for work or for pleasure.

Business software: we have no choice but to use it.

Most business software is badly designed. From custom software that’s home-brewed by engineers and business analysts working in big companies to design software like Photoshop, users of these products face steep learning curves. These steep learning curves are a harbinger of opportunities for improvement, if not downright disruption.

It’s easy to find companies that peddle consumer-grade software caring about design. The resulting usability of well-designed products reap measurable dividends. A key reason these products succeed is the focus on the user. Before “user experience” was all the rage, “user-centred design” was the big awakening. In all the excitement, business-grade software – and the humans who are forced to use that software – were left behind and forgotten.

It’s hard to find designers with the appetite and aptitude to design business software. Paul Adams’ pithy coinage of the phrase “the dribblization of design” reflects the persistence of design being perceived as visual or graphic design. It’s a mental model that plagues designers and non-designers alike.

I’m certainly not the first or the only one to have raised this point.

Dylan Willbanks recently noted, “…when you talk to the leadership of these enterprise companies, they want a consumer-grade experience built into their SaaS-based billion dollar applications. So they bring in consumer-grade user experience designers, raised on user-centered design, taught that “innovation” is supreme. Bolstered by a “make it pretty” attitude in the executives, they set to work trying not for Olive Garden but more Eleven Madison Park — locally foraged! Haute cuisine! Sous vide! And their resulting designs end up emphasizing the wrong things. Icons get prettier. Cool new animations in a cool new iOS version of the application. The aesthetics are greatly improved. But the underlying functionality is still a mess, performance is still slow, and even as they’re defending their slick new mobile app[,] there’s a nagging doubt whether someone really does want to review complex spreadsheets on their phone. The drive is on presentation, but experience driven design goes by the wayside.”

Tom Hobbs, back in 2015, issued a ‘call to arms’ for improving the design of enterprise software. And earlier this year, Facebook’s Margaret Stewart was at O’Reilly’s Design Conference trying to rouse the troops to take up the cause of designing for business users. And yet others, such as Uday Gajendar, have felt the need to be apologists for heeding the call.

Business users are people, too!

I’d like to add my voice to the ‘call to arms’ by making the case from the perspective of the users.

The design community has made great strides in improving the experiences for many people when they use software for pleasure. We can do the same by remembering that these same people also need to use software for work. In fact, they’re the same people for whom we designed Pinterest, Uber, and all the other digital darlings du jour.

What if the software they use for work sucked a little less?

So, what’s the field of play? What’s software for business? Most people define it as software built by companies for use internally by employees. I would also include software designed, built, and sold by companies to their customers, as well as software designed and built by companies for use by their customers. Most of this stuff is terrible; some of it is really terrible. And the kicker is that lots of time and money was involved in producing this terrible stuff to be inflicted on hapless people who have to use this software every mind-numbing, rage-inspiring day.

We can do better. We should do better.

How can business software be more human-optimized?

Back to first principles. Our designer’s toolkit is still valid, though some of those tools may need a bit of imagination and creativity to be adapted to handle the more complex data models and mental models of the business landscape:

  • Develop empathy for the people who have to use it
    • users of business software are humans, too
    • go beyond tasks to understand the real reason they’re using the software
    • understand the workarounds they’re coming up with to get through their day and still catch their commuter train home despite the bad UX of the software they need to work with
    • creating taxonomy, IA, and mental models that are understandable by users rather than the engineering vocabulary used to describe the system;
  • Design for the network
    • no enterprise software exists in isolation: it’s always connected to something upstream, something downstream, and often something adjacent
    • work flows in a single application typically traverse multiple systems, some of which aren’t even digital;
  • Consider AI augmentation
    • consider the possibility of designing parts of the system to offload work that scripts and bots can do in order to free up humans to do the work that only humans can do.

Business software is the next frontier of UX design, rich with opportunities and relatively free of competition for right-minded designers to make our mark.