Everyone, and welcome back, we're going to be talking about how do I create my own wireframe?
So the one thing I really want to stress is to keep things simple.
You know, don't worry about fidelity, especially when you're wireframe.
You just need just enough to really get people to understand what you're trying to convey.
Pencil and paper is probably the best way to wireframe quickly, you know, this is one of my mantras,
like we've already done this.
I mean, we sketched a bit, we did some user flows, and you've already kind of started wireframe mean
even if you have a whiteboard, you can use one.
But I mean, pencil and paper are huge.
You know, if you do have a client, you can polish them up to showcase some of your interactions of
more prominent areas within your photos and, you know, pages that you're designing for.
You can definitely, like, add a little bit more fidelity, just showcase or demo them, but you want
to keep your colors to grayscale.
White and black is perfectly fine.
Grazing between don't go crazy on fonts.
Maybe, too, you can even get away with one.
You can easily show hierarchy with bolding fonts as well or increasing the size.
Avoid any flashy images.
You can use rectangles and squares and, you know, an X through the middle to say that that would be
an image.
And for videos you can add a triangle in the middle to indicate that that's one as well.
So, you know, keep it simple.
Don't worry about fidelity, especially at this stage.
Next thing is, you got to ask yourself some pretty important questions.
You know, what are the users and the business's goals when interacting with this page?
How can the content be organized to support these goals?
What should the user see when they first come to a page?
What will the user expect to see on certain areas of the page?
I think these questions are a perfect Segway really into wireframe.
And, you know, consult your old artifacts right here.
I have a story map and definitely go back to the story map if you have one to really consult like user
stories and requirements so you can understand what will be on every page.
We even did user flows as well.
And we're going to get into that right now.
So consult your user flows and your sitemap.
You know, as I consult my map, I'm always looking at the key requirements and hierarchy's for a certain
page.
I want to know, like, what is the most and least important thing that should be there, you know,
different user stories that are really great because they're better indicator of what exactly needs
to be built from a user's perspective.
And a proper like if you have a storm map, like I mentioned before, we would, you know, have users
rates for every single instance throughout the product journey.
And then we would come together to discuss, which is like the riskiest part of the product we want
to tackle first.
So, like for our client, we probably want to, you know, tackle search or the home page where maybe
the initial registration, all those different points where it really depends on users actually finding
products or registering their interest.
So that way the product can actually be successful, their high traffic areas and the interactions are
pretty integral to the user goal and we need to get them right to succeed.
I always and I mean always tackle the riskiest features first.
So like I mentioned before, like that's a perfect segue into this, because everyone has a different
definition of what risk is.
And it can mean a lot of different things.
It could be features that dictate the success of the product.
It can be certain assumptions that your team and client have for a certain feature.
When I'm in a Kick-Off meeting or I'm talking to clients, I really kind of I have a list of risky assumptions
that we have as well.
And I mark all those things down.
Anything from what we assume the user wants or assume will be a good feature or certain things like
risks.
There are high traffic areas that really depend on nailing the interaction in order to succeed for the
business, for our client.
If we release a search that just doesn't work or the interaction is way too complex, the product essentially
will fail.
So there's a lot of things like that we need to account for, and we should probably be focusing a lot
of our attention on, like in comparison to another feature like profile or a wish list.
So always keep that in mind.
Another big thing is to bring your team into the process.
I mean, this is huge.
You should often be talking to every member of your team.
It doesn't matter product managers for business goals, developers for like development strategy.
You can even talk to a quality assurance, people like quality analyst people to talk about just how
certain things work within the product and what their expectations are.
Other disciplines will provide priceless insight into the ways you can build those wireframe.
So make sure that you include others in your process.
It may be a business school that you aren't meeting or a technical challenge that you may have.
Like for certain interactions, you want to come to life.
So tap into your peers example of, you know, trying to do things that are way too hard to develop.
So if you have, like, a wireframe that is just way too complex, you should definitely be talking
to your developers.
I often take a look at dribble.
I mean, I mentioned dribble a lot because it's a great place to get inspiration and all that.
But the majority of the designs showcased there will probably never be built and have never been built
because they just are way too complex and time consuming.
I'm not saying that it is impossible because everything is possible with enough time and money, but
most times you want to build your way up to something that is considered perfect and we may release
in different stages whether that be like a minimum viable product that has only the features that you
truly need to validate if your product has any, you know, legs.
Sometimes we may be releasing on top of that the next best features, and over time we'll get to a point
where we can really hone in on the design and polished different things.
But generally, you want to release in kind of waves instead of building out a product from zero to
100.
You want to get like 25 percent of the way they're.
Build another set of features, improve on other features based off of what you've learnt from your
wireframe, testing and even just basic prototype testing.
Remember, loopier team in, it's really going to help you understand what you can and cannot build.
It also really help you understand what kind of like different business goals you may have that you
haven't considered.
Maybe stakeholders have certain goals.
So these are the tips I often give other designers for when we want to actually use wire frames and
when we actually want to create our own.
So follow these tips and you'll be well on your way to making some awesome wire frames that are based
off of facts and different types of data and are used to actually validate everyone's assumptions.