View the original post
Front-end prototyping is the making of a simulation of the final design. It’s a sample of how the final product will look and feel. This gives the design team something tangible so it can assess its functions, plus it helps uncover flaws.
Teams can test the prototype before investing time, money, and labor. Stakeholders can give feedback and approve the next phase.
Why front-end prototyping?
A prototype helps clarify the goals of the product and how to move to each phase in the project.
- It gives stakeholders a first look at the design.
- UX teams can test the feel of the product.
- It shows the design’s states in the context of the product.
- It helps reveal those pesky algorithms that output nonsense.
Front-end prototyping begins with the end
It’s easy to fall in love with all the bells and whistles in a design and forget that the goal is a good user experience (UX).
As a UX designer, it’s important to get inside the users’ heads. Get to know their pain points. What frustrates them? What are their goals and aspirations?
There are some useful UX marketing tools that let you “tell the story” about your target user.
- User personas. These are fictional characters that represent your end user. You can have 1 to 3 personas for each product.
- User stories. These are brief tales of your user personas using the design. They can help you avoid adding features that aren’t useful.
- User scenarios. These help you connect your UX design with the personas and their goals.
- Customer journey maps. By mapping out user behaviors and emotions before, during, and after can help you predict users’ needs before they are even aware of them.
Although these are fictional portrayals, they should represent real people and real events. In other words, you build them from what you learn from user research.
Static front-end prototyping
A front-end prototype could be almost anything. You could scribble it on a paper napkin, in a notebook, or on a whiteboard. You could create it in Photoshop or Illustrator. Static prototypes like these can show how the product will look, and they can show how the user interacts with it.
Suppose you’re designing a mobile website for a restaurant where customers can order carryout. You’ll need to design the prototype to show user interactions and screen states while placing an order.
- Create account. The prototype should mimic the process of setting up the account. Suppose research shows that restaurants get more orders when users create the account at checkout. The prototype should simulate user input at the checkout.
- Log in. Here the prototype would show the input fields. It also needs to show the response if the user enters incorrect info. It would also show the screen state if the user tries to log in when he or she hasn’t yet created an account.
- Ordering. The prototype would have the menu categories (main dishes, sides, drinks, etc.) It would show how the site behaves when the user chooses a category. It should also show how the product appears on the screen when it’s selected from a category.
- Checkout. Shows how the user enters payment information, saves it for future orders, etc.
- Arrived for pickup. Simulates how the user announces their arrival at the restaurant. For example, if the restaurant has curbside service, the user can enter a parking space number.
But suppose the restaurant also wants to let customers reserve a table in the dining room. The prototype would show how it presents the options of order carryout and reserve a table.
A static prototype might present the product like this:
- The home page. In this example, you can order carryout or reserve a table. The prototype shows the buttons taking them to the carryout page and the reservations page. Arrows or lines could join to drawings of those pages.
- Carryout. Here it shows the layout of categories.
- Main Dishes
- Reservations. Shows which tables are available.
- Checkout. Represents how the user completes a carryout order.
- Login/Create Username and password if needed
- Payment info
- Confirm order
- Arrival. This tells how the user alerts the restaurant staff.
- Curbside parking space number
- Arrived for reservation
You could arrange each of these like a flowchart so it communicates what each piece of the prototype does and how the product will look.
But it doesn’t allow user interaction.
Interactive front-end prototyping
An interactive prototype is better because UX teams can get a feel for the design. With feedback from product testers, you can improve the prototype before moving to the next phase.
- Home page. The interactive prototype lets you test the links by choosing carryout or reservations.
- Carryout. Here you can see how the button and other graphics look. You can tap the button and judge if the design needs improvement.
- Reservations. You can evaluate the UX of reserving a table. You can see how it shows which tables or booths are available, whether there are patio and bar tables available, and what times you can make the reservation.
- Checkout. You can see whether the site makes it easy to enter and save payment info, save favorite orders, etc.
- Arrival. Demonstrates how you let the restaurant staff know you’re there.
Front-end prototyping with code
Using code in front-end prototyping is solves all your problems connect with static, vector-based design. Let’s say it’s the “real” front-end prototyping. With UXPin powered by Merge technology, you can import coded components for your prototype to the library in UXPin. This makes it much simpler when you move the project forward.
- Designers don’t need coding expertise.
- Engineers can work with design elements already coded.
- Design ops teams can build prototypes that serve both designers and engineers from a single source.
Since you’re working directly with code, you won’t need to translate it later. That helps design editors avoid making complex codes that can be a nightmare to fix and remove the whole design-dev process.
Merge not only makes your prototype functional but also lets you do that easily and fast, just by drag-and-dropping the component on the canvas. You don’t need to add any interactions unless you want to. Merge technology is the ultimate front-end prototyping as you just focus on UI, forgetting about the back-end with the production-ready components.
You don’t have to reinvent the wheel. You can import coded React.js components from your Git repository like Github or Bitbucket to the UXPin design tool and make the most of what you already have.
Try UXPin powered by Merge technology to start designing with code components and cut down your product’s time to market.