Check out a free preview of the full The Product Design Process course

The "Future Vision" Lesson is part of the full, The Product Design Process course featured in this preview video. Here's what you'd learn in this lesson:

Paul discusses the importance of creating a future vision to help with design consistency, consideration of future features, a goal to work towards, and increased morale and creative freedom. He also explains the process of creating a future vision, which involves research, brainstorming, prototyping, testing, backlogging, and sharing with the organization.


Transcript from the "Future Vision" Lesson

>> So one of the things alongside a minimal viable product that I've increasingly started doing is creating a future vision, right? So don't just prototype the minimal viable product, prototype the maximum product? I don't know what the the kind of opposite of that is the end goal. Where do we want to be?

Where do we want to get to now we don't need to build this in code. I'm just talking now about kind of figma II type stuff. But it turned out to be a really useful tool for us especially as product designers but also for getting a unity of vision across the organization.

So there's several reasons why I've started doing this more and more. First is design consistency, right? So it allows that product designer to put together a kind of a design system and dot design language for the whole application, even for bits that you're not intending to launch yet or create yet, right?

And this vision will change, right? I was complaining earlier about people that had a backlog of features, right? When they haven't even launched the MVP yet. And now I'm saying, create a whole vision of everything. That's contradictory, isn't it? So I'm very aware that I'm doing that, but I'm not saying we're gonna create this vision, but it's an opportunity for us to look a little bit further ahead and maybe start to resolve some of those more holistic design decisions.

But also it helps for more. It allows to consider what features might come into the app and start putting the foundations in place today, right? Because it could be from both a development point of view and a design point of view. It can be very challenging to retrofit a new feature onto an existing application, right?

It may mean changes to the underlying database. It may mean changes to the code base and how that operates. It certainly means problems from a design system point of view. And so there's a lot of complexity but if you've got a kind of these are the kind of features that we,might have, and these might be how they look.

then at least you can bear those in mind when you are creating the actual stuff for the MVP and it also gives you a, goal to work towards, right? A shared vision that everybody can look at. Excites people about the potential, it brings the team together, it helps flush out a lot of the disagreements early on about where things might ultimately go.

But within a less urgent way, because this is never gonna be built as it is anyway. Now I know that all sounds very wasteful. But you're building this thing, creating this thing that probably won't ever be. But increasingly if you get the opportunity to do this, it helps solidify a direction, a vision and prepare the ground for the future.

Yeah, go for it.
>> Yeah, I think this is actually really a good idea for another reason, and that is to provide people with a sense of it would increase morale.
>> Yeah.
>> That it's like, these ideas are going somewhere that you can envision something great. You have something to look forward to.

>> Yeah, absolutely. So the only danger here is that this becomes a straitjacket, right? You need to know you're not gonna build this and you need to say that upfront. I'll tell you the other thing it does is it gives people creative freedom. So stakeholders will start suggesting things that they'll never have suggested normally, right?

So I did this for an insurance company. I don't know why I'm looking at you, you're banking, but for an insurance company, and we started create this prototype and I said up front, we're never gonna build this. This is never gonna get built, but we're envisaging what might be, let's, go for it, right?

We were doing all these things and of course, I was breaking compliance rules left, right, and center, and the legal department would go, yes, fine cuz he's never gonna get bill. It's amazing how many of those things actually carried through, right? Once you kind of put your stake in the ground, they got compromised down a bit.

And the wording was true. But we got a lot further than I expected we got because everybody got carried along with the enthusiasm of it. It's a weird thing. It's quite hard to explain, but it's worth giving a go on one project so you can see for yourself how it works.

How do we go about creating this vision for the future. Well, we can do some research up front, find out what our user needs are, what, are the stakeholders different visions are for the project, all that kind of stuff. We can then brainstorm lots of ideas what could go in it.

We create a bit of a prototype around those visions. This is all stuff that I'm sure you're very aware of and you've heard a hundred times, you can test that, see how people respond to it, iterate around it a little bit. And maybe even start turning this into a bit of a backlog.

But probably not the right word because that means it sounds like it's prioritized. But break this down into projects that could be potential projects. And then you share it with the rest of the organization to get other people excited and on board. So those future visions can be a really powerful tool that I don't think there's a lot of people doing a lot of that there's a big focus on MVPs and not as big a focus on where are we heading, yeah?

>> Is this are you seeing this as different from or the same as a map like as a.
>> Journey map.
>> Journey map?
>> Yeah, a journey map is nothing yes, it's different. So when we talked about journey mapping on the user research and testing thing, that is you can create an aspirational journey map, right?

Which looks at, well, what if this, it was a lot easier for the user and that could act as this. If you wanted it to it's a lot quicker and a lot easier to create an aspirational journey map than what I'm proposing here. What I'm proposing here is we actually create a figma interactive prototype of what the app might look like.

A few years down the road.
>> Right, I meant a roadmap, a product roadmap. Is that different from this?
>> Yes, yeah, a product roadmap is more set in stone, right? This is more what could be. It sounds so pretentious and so kind of wooll, and who let's all imagine the beautiful future we could live in together.

But it helps the UI designer, because they can start thinking about the thing holistically. So it kind of ticks that box, but it also helps enthuse stakeholders and bring them on board. It also means that you can prototype without constraints. So a lot of ideas that would have been killed dead by legal or compliance or whatever can kind of sneak through.

And even with developers, it helps them go, well, if we might be introducing this feature later, I need to make sure that that's gonna be easy to build when it comes along. So it is just a bit giving you a vision, a direction to go on. So just to kind of wrap this all up, what I'm basically saying is we're starting with an MVP and we're continually iterating upon that MVP over time.

But we also need to remember to look ahead, to have some kind of vision. Now, how you express that vision, if it's a prototype, if it's a journey map, if it's a road map, whatever works for you, but having that vision of the future. I like prototyping personally, because I think it is very tangible.

And also, just never forget that product design is fundamentally different from web design and it's got a lot of nuances and is a lot broader in some ways. And a lot of other considerations that need to be brought into it, especially if there's not good product owners and a good structure within the organisation.

But then what we're gonna do is we're gonna move into looking at kind of good some of those areas in a lot more detail in particular we're gonna start off by looking at use cases. And how to really understand what users are wanting to do with this app because that's the fundamental building block upon which you grow from there.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now