Prototype is tuning your idea into something that mimics what the real product will actually look and feel like. Prototyping is a great way to get feedback about your idea, without actually having to build a fully functional representation.
Usually a prototype’s just a skeleton of the most critical aspects that need to exist in order for you to get signal in the validation phase. The more detailed and realistic your prototype is, the better the feedback you will get form users.
Use realistic assets and avoid using placeholder copy when possible. It doesn’t have to be 100 percent perfect, but you really do want to make sure that your prototype feels realistic.
English – English
Different types of prototype
There are a couple of different methods for prototyping from video to paper to interactive. Interactive prototypes are generally what you use during design sprints. This is because you’ll get a very different interaction from users when you put a prototype in front of them, that they actually can interact with and use and navigate, and the type of feedback that you end up getting from these types of prototypes is really rich. Both about the idea, as well as about the usability of the specific design that you’ve chosen.
The aim of rapid prototyping is to affordably demonstrate to stakeholders, end-users, and your own internal team what any given piece of functionality will look like, and how someone can interact with it. Critically errors in prototypes are far less expensive than errors in software development.
What is a storyboard?
A storyboard maps out the entire experience and it’s also going to become the blueprint that you use to build your prototype. You can also use a storyboard as input for the research plan for the validation phase.
The UX storyboard can help visually predict and explore the user experience with a product. It visualizes how people would interact with a service or app. A UX storyboard can also help understand users current motivations and experiences connected to a certain problem.
A storyboard is composed of frames or you can use cool storyboard scenes. Like a comic strip, each frame captures an important part of the story that you want to tell. Not every frame has to be related to a software experience or UI, and the first frame should actually be focused on the user and explain the problem that they’re running into.
Use the frames to map out how your idea helps the user to solve their problem. Use text and annotations in the frames to help add clarity, and each frame should also have its own caption that clearly explains what’s going on.
If you have personas and journeys. Why do you need UX storyboard?
You’re already using user journeys to understand user flows. Why use storyboards too? They have some indisputable additional benefits:
Visual benefits – Images on a UX storyboard can speak more powerfully than just words. Stakeholders can often process visual information more easily.
Emotional engagement – A UX storyboard focuses on problems and situations rather than features, like personas or journeys do. Storyboards are a more engaging visual form, that people can emotionally relate to.
Communication – Storyboards communicate flows and problems quickly, and displaying them keeps the flows and stories insight.
Why it’s happening? Who’s doing what?
Start by writing out the key scenes that you want to show. Use the first frame to explain the problem or situation that the user’s in before they even interact with your idea. Use the first frame to set up the value of your product. Map out the different actions or steps that the user goes through, don’t have to show every single step, but make sure that you’re highlighting the ones that are most important to your concept.
Remember that the first frame is about framing the problem
Last frame is about articulating the impact of your product and the solution
Frames in between are used to connect the problem to the solution through the steps that the user takes with your product in order to achieve their goals.
Validating
Once you have a prototype, you’ll want to put it in front of real users and get feedback. Validate is the sixth phase of the design sprint. Validation is important because it allows you to get feedback from real users if your idea is actually meeting their needs. It’s always an eye-opening experience, you should learn a lot and gain valuable insights.
In addition to talking with users, it’s also important that you validate the concept can be built with engineering team. If you have an amazing idea but it can’t actually be built in a reasonable amount of time, the entire team will end up being super frustrated.
Don’t validate ideas, test them
Putting a concept in front of users is a great way to understand if you’re on the right track. You’ll get valuable feedback about whether your idea is meeting a need and if it’s something that people would use. Additionally, you’ll also get feedback around how usable your prototype is. Both of these types of feedback is incredibly helpful, because you’re still at a stage where you can make changes and easily course-correct.
User research is as much a mindset as it is a science and an art. In a user study, attitude greatly affects participants, your team’s reactions to their behaviours, and follow-up actions on study findings. Planning the testing, observing users, analyzing findings, and describing the research process all require a delicate balance of curiosity, realism, diplomacy, honesty, and a profound ability to welcome and withstand criticism.
What you say from the inception of the study to its conclusion — how you recruit, write tasks, ask questions during a test, and lead posttest interviews — can all subtly (or not so subtly) affect how the test participant reacts.
Saying to your team that you want to validate a design suggests that you know it works and are simply looking for concrete proof. It implies that you are resistant to learning that the design doesn’t work or that you may need to fix it in major ways.
Validation (user test) step by step – download here
Before you start a Design Sprint it’s good practice to plan what the best steps afterward will be. But it’s also important to acknowledge and respond appropriately based on the outcome of what happens during the sprint.
DEFINE YOUR FOCUS: WHAT DO YOU SEEK TO VALIDATE?Cleary define your challenge, and at what stage of the innovation funnel you’re in. Are you looking to validate the problem you’re solving, the solution to address that problem, the business model or the revenue model?
MAP OUT YOUR ASSUMPTIONS, PRIORITISE THE MOST CRITICAL ONES AND CONVERT THEM INTO HYPOTHESIS READY TO BE TESTED – Regardless what stage you’re in, you can now map out the assumptions you’re making.
CHOOSE AND DESIGNTHE RELEVANT EXPERIMENTS TO TEST YOUR HYPOTHESES– Once you have ranked your assumptions and defined a key hypothesis you want to test, you can pick the most suitable experiment(s) to test and (in)validate that hypothesis.
Who will you be interviewing?
This doesn’t mean the names of people, instead it’s about identifying your target user. Who are your target users? Are you interested in getting feedback from existing users, new users, users of the competing product? All of these users will have different needs. You can also think about demographics or other characteristics that relate back to your concept and your specific goals.
You’ll usually screen perspective interview participants through a survey. It’s super important to make sure that you get the right people into the study. Very few products are truly built for everyone, instead they’re built for a target user.
You’ll usually screen perspective interview participants through a survey. It’s super important to make sure that you get the right people into the study. Very few products are truly built for everyone, instead they’re built for a target user. Imagine that you’re working on a new feature for TikTok, you would get a completely different outcome if you interviewed a high-schooler versus a grandparent.
Finally how many interviews should you complete? Generally, five to seven interviews is enough to start seeing trends and themes. These interviews can be anywhere from 20 minutes to 90 minutes. Recruiting participants can take a lot of effort, so short interviews might not be the best use of time, and interviews that are too long might not be in the best interests of the participants.
Technical Feasibility
Even if you have the best idea ever, if you can’t build it, it doesn’t matter. Involving engineering early on in the process allows you to get a better sense of what is and is not feasible. It also allows engineers to give you feedback about what is easy and difficult and where complexity may exist. It’s important to have these conversations, and as a result, you might end up simplifying some aspects of the product in order to accelerate timelines. Or sometimes engineers might have ideas about a better way to build the product.
Use mocks or a prototype as a walk through to illustrate all the flows that a user will go through. Prepare specific questions or assumptions that you have about how things will work from a technical perspective. These questions should focus on things that impact the way the experience is built. For example, in order to render a screen, there’s a number of different pieces of data that are required. Where does that data come from? In the case where user is inputting data, where is that data stored?
It’s also good to ask about potential causes for latency, as this can have a negative impact on the user experience. If there is a lot of latency, how can that latency be mitigated?
Share a PRD of the feature and ask engineers the level of difficulty it would be to build.
Provide a mock for a feature, explain why it’s exciting and request the engineers perspective, the engineer can see and discuss the flow
What do you do at the end of a design sprint?
there are a couple of different outcomes for a design sprint. Potentially you could move to implementation, you might need to get more stakeholder buy-in, you might want to spend more time iterating either as a standalone work-stream or potentially through another design sprint or, sometimes after you go through a design sprint, you learn that it’s actually not a feasible idea.
