Low-Res Prototyping: Fast-Forward Your Product Development

I’m currently working on a product redesign for a self-service support desk. Although there are various facets to rebuilding this product (UI improvements, adding and optimizing functionality, user navigation, cross-integrations with other products and content providers – which will all be launched via continuous development) the first priority is creating a new look and feel for the users.

For those of you already involved in the UX world this is nothing but a friendly reminder. If you are just getting started as a designer or working on launching a new product, this brief should be a good bit to add to your knowledge bank.

Getting started

Low-res prototyping has been around for ages. However, it has evolved over the past few years thanks to continuous influence from lean startups, agile development, and user-centric design thinking. One of my favorite UX methodologies to follow has been the concept of Sprint, created by the team at Google Ventures. I won’t go into detail about the book – you can enjoy that on your own time – but the book does an incredible job of helping you build low-res prototypes.

The most valuable aspect of running a “Sprint” is the ability to fast-forward your workflows. Once you have tied down who your audience is (user personas), the next step is to hit the drawing board. It’s important to understand that failure is inevitable – regardless of how skilled or creative you think you are. As Thomas Edison said, “I have not failed, I’ve just found 10,000 ways that won’t work.” Don’t worry too much about the details, the more creative ideas you can get on paper, the better.

Build a foundation: Early-stage sketching

The first week I started working with my team, I conducted a sketching exercise. I handed the reigns over to my colleagues and asked them to sketch what they felt would be the best design/look for our support desk – no restrictions applied. After some time (be sure to set a time limit for these exercises), I compiled the sketches to discuss the similarities and differences each team member brought to the table. In a short period, we were able to collaborate together to build a mind map and storyboard highlighting the key pros and cons to our current interface.


“Working with my colleagues helped me create a different vision and perspective of the product.” – Brady Mason

As a designer, it’s easy to fall into a repetitive pattern of creativity (using the same font types, components, colors, etc). Working with my colleagues helped me create a different vision and perspective of the product, and made it easier to start iterating my own sketches moving forward.

Test, test, and test some more

Once your foundation is laid, its time to test the results. There are various strategies to user testing (here is a nice library of links to read from to get started: Nielsen Norman Group) and conducting an expert analysis of your work. Find what works best for you and start out with what you feel most comfortable with. Work on adding new strategies each time you test. Over time, the questions you ask and exercises you run will become second nature.

I find it most useful to diversify the types of tests you conduct with different user groups (note: a user group does not need to be a large audience – but the commonly quoted statistic “Five participants will discover over 80% of the problems” only holds true some of the time). As your setting up these groups, think about what you hope to achieve. How many problems are you hoping to solve during this test? How impactful is this problem/ solution going to be for your product?

To better gauge what your audience size should be, use the tables and analysis in this article from UX Matters to help shape your decision.

Here are a couple test examples I have recently conducted (with an average audience size of 3-5 people):

  • Findability test: This was a test to see how well users could locate the support desk. I tested using an icon in the top navigation vs. a side tab with text “support desk”. The feedback varied by user expertise. Those more familiar with online dashboards found it easy to locate with the icon, but those who did not, found the tab with text easier to find. In short, go for what makes sense to the lowest level of expertise – the simpler the solution, the better it will be for all users.
  • Detachable Window: Users enjoy flexibility with a product, and by adding the detachable window the users felt they were able to solve more complex problems in a quicker manner.
  • Feedback Functionality: To better optimize our product, we currently need a more frequent flow of user feedback. To achieve this, I have relocated the “user feedback box” to stick and hover at the bottom of the screen until a user has responded. Part of this test is to identify the placement (is its location disturbing at all to the content on the page?), as well as how users prefer to interact with these types of functions. Results so far are that the placement is much more noticeable and not disturbing. As for interactions, users prefer to simply click “thumbs up” or “thumbs down” but aren’t as keen to leave a detailed response.
  • User Flow Test: With this test, I wanted to find the preferred functionality for finding a solution. Do my users want to use search, navigate and filter through content, chat, or directly call our support center. As a self-service support desk, our goal is to guide the users in a hierarchical process of choice. First search, then filter or navigate – and last resort – contact our staff directly. Before testing users, this assumed priority of steps was put together to save money for the business. Luckily for us, up to this point users agreed that they would prefer to solve the problem on their own via articles, how-to videos, or e-learning courses (note: this is contingent on our ability to build and organize functionality that is supports this user journey).

*some of these features you can view in the video at the top

These are just a few of many tests that I have conducted over the past few months, but I think you get the idea of how using low-res prototypes can expedite the process of testing a large list of potential improvements to a product – regardless of how big or small they may be.

Iterate your sketches

After enjoying the rounds of tests with your sketches, take that feedback to iterate your work into a prototype that is a bit more interactive. For me, I use Sketch to create wireframes and sync those designs to InVision to create clickable prototypes.

Although these designs will now be digitalized, you want to keep them in low-res form. Otherwise known as grayscale wireframes. At this stage of development, you are still solely focused on usability and transparency. Often when users are overwhelmed with colors and fancy components they lose focus on the simple tasks at hand. Working with grayscale wireframes will help maintain a user’s understanding of your product’s functionality and pinpoint areas that may need improvement.

Traditionally, grayscale wireframes consist of static elements – boxes, an image icon, and generic text. This works for some user tests, but it does not entirely represent your product. Even though you are just presenting low-res wireframes, I would suggest avoiding the use of filler text like lorem ipsum. If you can use your own unique content and design, the easier it will be for the user to relate to your product.

As a UX Designer, the majority of your time should be spent on user research and testing. At some point, you will need to beautify your product by adding color, cleanliness, and interactive components. But the value of UX is found in the foundation of your work – building from the ground up. Save time and money by following these steps instead of back tracking later on down the road.

“The value of UX is found in the foundation of your work – building from the ground up.” – Brady Mason


Brady Mason works as a UX Designer at Visma. As a UX Designer he enjoys the opportunities at hand to marry his passion for creativity with human behavior and psychology. He is driven by the challenges to identify problems and provide validated solutions.
Connect with Brady: