Key to nearly every process in building digital experiences is the ability to adjust to changing perspectives.

A project kicks off with an array of perspectives: Stakeholders and domain experts, each responsible for a particular aspect of a project, each with their own vision and expertise. And then your team: Design, engineering, QA, project management, and more.

All of you gather in a room and begin the journey of molding a vision more powerful than any that has come before it. At the end of the meeting, you’ve got new acronyms, full whiteboards, and the client is practically speaking agile (#livingyourbestlife).

Congratulations, you’ve stepped into the first of several perspective-shifting moments: The one after a kick-off ends. This happens on a large and small scale, throughout every step of the product lifecycle.

Coming Down from Kick-off

The vibrant sticky notes that once covered the entire conference room with equally vibrant ideas, visions, and tactics form a tiny, unassuming stack. You start a new spreadsheet. And as you go cell by cell, column by column, the energy changes. The fresh perspective around a new project wrestles with familiar tactical workflow realities.

You start to wonder if your partner thinks back on the brainstorming and vision building as much as your team does.

Did they walk away with vision alignment and perceived value?

Will they be ready for and committed to daily stand-ups?

Are they ready to define MVP?

Diving into Discovery

And then you snap out of it because now it’s time to get to work. Once that communication begins, your partner’s product owner comes into focus. You’re ready to dig into Discovery so you can then start sprinting, together.

How our team presents our process has to align with how the product owner sees their potential product. At the beginning of Discovery, there tends to be a gap in understanding around sprints, iteration, and collaboration. Bringing it all together in a roadmap and a backlog helps define the journey. But the shift in perspective occurs when we can make Discovery a real learning experience. It’s never easy, but worth it–because this is when trust and shared expertise kicks in. The client becomes your partner.

Defining MVP

This one is big. Defining the MVP requires a unique and difficult perspective shift. Together we are moving from nothing–to the start of an actual something. An idea is an idea. Strategy is a strategy. Product development requires the designing and making of an actual thing. Through the exercise of defining an MVP we begin to pluck the most valuable ideas and outcomes from the clouds and put them into the hands of a capable team. Things start to get real, and the vision starts slowly coming into focus.

It’s important to recognize the sensitivities around MVP. There is potential for significant misunderstanding and a range of different, conflicting views around what it means. My best tool in getting alignment on MVP is first really nailing down the outcome they desire. “Let’s just get something out there,” is a world away from “We want our customers to perceive us differently and change their perception of our brand.” Obviously the latter inspires deeper, better conversations. The former begs more definition and setting of expectations.

Identifying Features

A feature usually begins its life as a short phrase, a few manually scribbled words. But it moved from hazy idea to solid feature the moment it was written down. And there it lives for quite some time–as something simple, straightforward: Log In. It’s beautiful.

Easy, right? There is so much more to it than meets the eye:

How do you log in exactly?

Is there a username, email, face scan?

What about a password or secret phrase?

How many times can they enter it wrong?

Do they get locked out?

How much are you asking from your user?

Here, we must shift our perspective again. Transforming a representation of an idea to a set of requirements to a diagram of a real thing. We begin to get down to how it really works, the anatomy of a feature, building an experience with functionality–and prioritizing the backlog.

Designing a Feature

Process and documentation is also an iterative, ongoing process. We learn where we lose time, and where we have the loudest voice. It shouldn’t be an argument about the complexity of each feature. There’s a lot behind simplicity and how it creates software people love to use.

It’s always interesting to me that people think they can do a designer’s job. And almost always, they assume they CAN’T do an engineer’s job. Developers have a specific language to talk about the work they’re doing. Design doesn’t. There isn’t such a direct, mathematical break down to design work. For UX designers, especially, putting on the dev hat when it comes to process can help significantly.

Here comes another shift! When the vision from your first product meeting gets closer and closer, a product that has taken shape now also has added color. We defined a vision, an MVP, have a solid backlog filled with features and now the designers can’t wait to get their hands on that one feature everyone thinks is “easy”. Your designed Log In feature now has users, use cases, edge cases, errors, interactions, visual character, maybe even some fancy animations. It looks, feels, and is ready to spring to life.

Developing Functionality

We’ve done the research to define the user flow and happy path so development can start digging into “if-then” situations. As always, it’s helpful to have back-end and QA available early on, so when we reach this stage in the product lifecycle, we already have checks and balances in place to anticipate barriers and challenges.

This is where another shift in perspective happens. Partially because features are being brought to life, and the excitement is building. But there’s also one that needs precipitation when it comes to making assumptions about design at this stage. Design is not a toss over the fence situation. It is based on hypothesis, and you continue to learn throughout the build. Prototypes happen sometimes, but not always.

We landed on the moon in 1969, but we’ve been gazing at the stars for over 300,000 years. What engineering does is shift our perspective from possibility to feasibility. As we build, we learn more about everything (including the design!) vs. what we could glean from visuals and design comps alone. Everything and everyone takes a real breath.

Experiencing a New Product, Learning, and Moving on to the Next

The most wonderful, yet troubling shift. Something new and beautiful is at your fingertips. It does everything you need and want in an instant. And it’s why we start all over again with a vision of something better, faster, more reliable (and waaaay cooler).

I like being a designer who can shift someone else’s perspective. It facilitates learning, understanding, and evolution for all parties involved in the creation of digital products. I don’t think it’s a fair assumption to think other people recognize and look to drive and accommodate changing perspectives. Throughout the entire process–there’s a vision, a set budget, and stakeholders. I believe it’s our job to shift perspectives into more real places with tangible deliverables. Removing functionality, testing an idea, planning out the build–it’s not taking away, it’s making it real. If you do it right, it is a great process.