The next important part of the canvass is the target use section.
Now there are often two types of users.
Those are end users and stakeholders.
Now, the goal here is to identify groups of people whose cooperation will be required to make this
project successful.
Now, the groups are united by common goals and concerns and include varying roles or occupations,
and users are the most, you know, the most obvious target users.
So those are probably the users we think about pretty much only.
You know, because they are the primary audience for using the application, we're trying to build their
goals, provide opportunities for developing features to help them get there faster, easier or with
more engagement, whereas their concerns help us understand what may hinder successful usage and offers
an opportunity to address them.
Examples of an end user would be something like a job function.
So if I were thinking.
Maybe like a mechanic that could be an end user if we were thinking more specifically about our product
and a user would be like a shopper.
That's pretty vague.
If you want to dig even deeper, we can say a family shopper, a person who shops for their family.
Or if I were thinking another thing, it would be maybe if we're thinking more like a method of use
that could be like mobile user or desktop user.
Or maybe.
Typical situational users.
It could be like a last minute user, so like a person who is maybe shopping very quickly, like their
situation really depends on getting in and out of the product as quickly as possible because they don't
have much time.
And that happens to everyone.
Sometimes, you know, we may embody different types of ambiguity, that one, but we embody different
types of users because, you know, sometimes they are very situational.
So let me just put these together perfect, generally, what we want to do is we want to get these users
and we want you again, we want to get together.
We want to diverge everyone right down on stickies.
Give them like five minutes to do that, come together.
And figure out what are the users we really want to target for this project, in our case, we know
maybe it's going to be a mobile user.
We want to really focus on last minute shoppers.
We can bring this one in here, too, so we can say that, hey, we're really focusing on this for this
project family shoppers will think about at a later date and we don't forget about them.
We just keeping to the side now.
Next thing we're going to do is we're going to actually think about end user goals.
So what questions we can ask are the following.
What frustration or pain point are we trying to help alleviate is where we can ask these types of questions?
We get our participants.
To start writing down on stickies.
So just going like this, what are we trying to alleviate?
What results are we helping to make better?
What limitation are we helping them overcome?
What type of device would they most likely use to perform these tasks?
So we need a mobile products, mobile, fast product.
I often get like answers like that, but I usually ask them to dig a little deeper.
I want to show a more seamless product experience, you know, there could be like if there's a Web
application, maybe that translates really well to the mobile application.
Maybe there's different touch points that are important.
What's another thing we can say?
And maybe a more personal shopping experience?
You know, understanding those goals really help us to think about this application in a different way,
and the next part after that is let's make red stickies.
I mean, it doesn't really matter like the color code sometimes because it helps afterwards when we
have to debrief all this.
We want to talk about the end user concerns, what would make them hesitate to take on a new application,
what ill consequences is likely to happen with this application?
What competitive level should this reach to be the preferred choice for this problem?
So there's a lot of tough questions to answer here.
One example could be like irrelevant results.
Pretty bad results.
Four searches.
Another one could be.
This could be more of a developer based NGO like application stability.
Another one could be foggy UEC, so like I'm just writing Foggy Unni's, very vague, but that could
be like, you know, users really want to know, like the status of their order.
And if we don't allow for a really great user experience, people are just going to drop off and never
use our application again.
So these are the types of questions you're looking to ask and these are the type of answers you get.
And this really starts to kind of define what type of things you're going to be focusing on in this
project.
Know what you want to do is next we're going to just do the exact same thing for other users.
Now, the next set of users are stakeholders.
Now, these are less obviously important target users, but often prove very important to the project's
success.
So you aren't really going to be like publishing an application or you're not going to be able to get
by like all that red tape if your stakeholders aren't on board with you.
And that's really the main factor here, is to get their understanding of what their goals and concerns
are, many projects start as an opportunity to prove that something can work effectively to some key
stakeholders.
Key stakeholders will include this.
Remove this.
They may include something like investors.
They may include sea level exacts.
They may include.
Buyers, so an investor who uses early traction to invest in the company's success.
We have buyers who, like a salesperson, is trying to convince to become a customer.
The success of the project can rely upon these stakeholders, sometimes more than the end users.
And this is why we really need to focus on this part to understanding the goals and concerns of these
key stakeholders can inform decisions and reveal opportunities to validate the direction of the product
early and often.
This really reduces the probability of failure throughout.
What will help make this project real, you know, external team stakeholders, investors, sponsors,
departments, partners, et cetera, all those types of people are actually going to be the ones that
are maybe, you know, paying for this project.
They're the ones that are pumping life into this project.
And we need to take them into consideration as well.
Questions could be, are like the APIs available, how responsive can the external team be to changes
to validation rules or model designed to meet the project goals?
How can we engage with stakeholders throughout the process, whether that's like with demos, user acceptance,
testing, design reviews, what information do each of the stakeholders really care about?
Some concerns may be like questions you want to ask or what are the risks the each of the stakeholders
are primarily concerned about.
Generally, that's going to be different for each type of user.
In summary, the end users help make decisions on what to build and, you know, key stakeholders provide
an opportunity to involve those that can influence the success of the project early.
So their input comes in right at the beginning stages.
And not like when you've been working on high fidelity designs, it's really important to identify all
these different types of user groups.
That way, it really can help inform the success of your project.
And that's it for target users.