Putting It All Together
We’ve finally gotten to prototyping, the task most people(including my parents) think is the whole UX job! At this point in the design process we’re combining the work we did in the previous sections, particularly the wireframes and sketches. These, in turn, were influenced by the information architecture and market analysis. This article is going to assume that you, the reader, know how to make a prototype using Figma, Adobe XD, Sketch, or some other UX/UI tool. Instead, I’ll be focusing on how to prototype can be given to various stakeholders. Final note, we’re also going to be going into aspects of code hand-off to developers, but prior programming knowledge won’t be necessary to follow along. Now let’s get to it!
Iterative Design Loop
Plan, create, evaluate, repeat; these are the steps that will improve not only every design, but every aspect of your life. The most obvious function of the prototype will be to layout the design in a tangible form. This means the first people that will see any of your mock-ups will be designers. With the right direction in usability and aesthetics, the design can be quickly be changed into something much better. When taking constructive criticism on your designs, it helps to listen and record any thoughts the tester has, rather than defend or explain your design choices. Not to yo-yo, but this doesn’t mean you shouldn’t explain their thought process, just not as a defense. The theory behind this is that nobody designs anything useful in a vacuum.
Once the prototype has been shown to a few designers, it’s time to introduce some stakeholders! The first group of people I like to show a product, as a people-centered designer, are the users! Proper usability tests will alert you of anything that doesn’t work or people don’t like. The goal during these tests is to record as much feedback as possible. It’s best to track everything using video and audio recordings, as these tools are impartial and can be replayed while working on the product. When making recordings longer than five minutes, I’d recommend splitting it into sections. These could be categorized by the page, the function/purpose, or anything else that creates ease of access for the designer.
Let’s talk really quickly about the other primary stakeholder at this point, your boss/client. While a manager of a product company will have more practice with understanding a given design, the approach to presentation should be similar to that of a client. I have found that the ‘report’ format works to explain my thought process as well as display any aesthetic mock-ups. Define the problem, show potential solutions, then recommend the best option. This format gets to the heart of the problem, saving time for everyone involved. Another benefit of this practice is that when writing up case studies, we already have the introduction complete. As the designer, you’re trying to only convey ideas, meaning it’s important to stay flexible and remain open to any advice.
Hand-Off: Delving into Development
Once we’ve established what it’s going to entail, the next task would be to prepare the files for a development team. Humans are visual creatures, yet programmers are data-driven. Let’s first understand what the developers need to code a project. CSS is the styling language of the web, in addition several native-app tools; any web designer should at least know the basics of this programming language. If your development team is using a specific framework, this should be known before any prototyping begins. I’ve personally found it helpful to always make designs that can be structured with grids or flex-box. Regardless of the technological specifications, it is important to remain in direct communication with the dev team as they produce the product.
Before we more on, let’s talk about how the hand-off should look for a brief minute. Inside the file labeled after the project name, there should be three folders: mock-ups, assets, and notes. Mock-ups should contain screenshots of each page with style notes, as well as the actual prototype file(ex: .xd). The style notes should only be about the layout, function, and aesthetics of the page that’s been screenshot. Assets is one of the most important parts to get right. I split this folder into images, icons, animations, copy-write, color palette, and fonts. When naming assets keep in mind, they should make sense in the information hierarchy and they should not need to be changed in the future. Also consider transparency, padding, dpi, and file size when putting images, icons, and animations in their respective files. Notes are important for conveying any concept not blatantly displayed in the mock-ups. This can include the style guide, design system, personas, and anything that makes the programmer’s job easier. Every roadblock that either designers or developers need the other to solve can set a project back for days at a time. To alleviate this, consider the perspective of the developer when creating the hand-off files they’ll use to program the project.
Post-Production Improvements
Alright, the product has been released and now we need to make it better! We’ll use common techniques like A/B Testing and Feedback Prompts, which can start simple and become a cornucopia of complexity. A/B testing, as the name implies, is the statistical study of two potential choices, in our case related to the design. This can be performed in a lab with a limited number of test subject, but is especially effective using Google Analytics. This testing method should be performed using the scientific method to reduce bias and raise accuracy. We can use the test to discover the more popular of two design choices, but how do we narrow down the choices to just two?
Feedback prompts are strategically placed forms for users to send any thoughts they have on the product. By allowing users to tell the company what they want changed, the designer can get a better understanding of where the user want the product to go. It’s important that the prompts are conspicuous but not in the way, since users hate annoying pop-ups. There’s a curious iterative loop on the feedback form, where A/B testing will improve the form, which will improve the impact of future A/B tests.
Conclusion
Designers are the empathy fueled glue of any product team, constantly collaborating and communicating to various stakeholders. A designer should make it their business to know how their work will be perceived at the various stages of construction. The most important lesson from this article is that the presentation and quantity of information will be vastly different when discussing any potential designs. While all opinions should be taken in and examined, it takes a discerning eye to recognize which advice to act upon. By taking as many recommendations as possible, designers can focus on what’s best for the product.
If you’re interested in learning more about UX Design, check out my posts on: Market Analysis, Sketches, Information Architecture, Personas, & Wireframes.
Congratulations if you read the whole series on my process; as always, thank you for reading and have a great day!
