Data, it's one of the most important aspects in web development. Studying how users interact with a product can only help to make it stronger, not harm it.

If a team or company can understand what causes their users to leave their site or click a buy button, they can enhance the product's experience and increase its overall user satisfaction.

How do web designers and developers collect data? And more specifically, how do agencies or studios building web applications, get their clients to buy into the idea that spending time collecting data is the right move financially?

At Made By Munsters we collect data regardless of the client's buy-in. That might should harsh. But give me a chance to explain. You might side with me after you hear me out.

We found, over our company's existence, that collecting data doesn't have to be an expensive venture. Nor does it have to be a long-drawn-out, time-consuming phase of a project. As agile designers and developers, we collect data during the life span of the project.

This doesn't require client buy-in. We only ask for resources such as users or feedback from our clients. We value our client's opinions and lean on them heavily to provide us with users who will use their product.

Gaining access to these users allows us to send various surveys, conduct paper prototype sessions and test clickable proofs of concept to help validate assumptions we make during the development of a product.

So why did I say we don't care about client buy-in? It's not that we don't care, it's just that these techniques don't require additional capital from our clients. With a little time and effort on our end, we can improve our clients' products.

Here are a few of our methods.


User Surveys

Informal, quick surveys can help designers and developers understand what limitations their targeted user base might face. Additionally, they can help answer questions such as, what browsers should we optimize this platform for? Or what devices / operating systems are most popular. While it's best to build for and test for as many platforms as possible, these results will allow you to build for day one and release a product that meets 80% of your user bases' needs.

As an example, we recently deployed an AngularJS application for one our clients. The product streamlined and simplified the lengthy review process employees conduct twice a year.

We used a simple Google survey to collect basic data on this user base. We were most interested in determining what browsers were used daily, in addition to, what type of devices reviews were conducted on.

This survey was necessary because our day one release came only eight weeks after our inception workshop.

The results helped us narrow our performance testing down to two browsers for the first release, as well as, one type of device. The majority of our target audience used Mozilla Firefox or Google Chrome for web browsing and all reviews were conducted on desktop computers.

This free survey helped us deliver the best experience possible for the majority of our users. Once we released the first product, we were able to pivot and focus on the browsers and devices used by a subset of our users.

As you can see from this example, we didn't need the client's buy-in. We just needed their assistance to send out our survey to their employees. Google did the rest for us.

There are various tools that allow teams to collect user survey feedback. At Made By Munsters we use Google Drive for document sharing and storage. Naturally, that led us to Google Forms and Google Sheets.


Paper Prototypes

While surveys are great, they don't allow designers to gain visual feedback on the structure of their products. That's where paper prototyping steps in. This technique couldn't be more inexpensive.

What you need: A few users, several paper copies of your designs and a few pens or pencils. We like red pens at Made By Munsters.

That's it.

We like to make a game out of paper prototyping. We focus our test on a specific feature or flow and then ask our users questions around these tasks. This is how:

  1. First, we ask users to perform a task. (i.e., Add an item to your cart)

  2. Based on the element they circled we hand them the second piece of paper that reflects that action.

  3. Then, we ask the user if they expected that behavior? (i.e., You clicked the add button and we notified you via a message or icon that the item was added to your cart.)

  4. Repeat the above steps until the flow in question is completed or failed.

Not many steps. It's a cause and effect game. As designers, we have assumptions about how a feature should work, but we need to test that assumption. What better way than getting immediate user feedback.

What makes this technique even better is the ability to change designs on the fly. If you notice users are continuing to circle the wrong action, sketch a new design and test a new theory until you get it right.


Clickable Prototypes

Lastly, we take advantage of tools such as InVision App to allow potential users to click through gray-scale wireframes or full-color designs and leave us feedback. These don't have to be perfect, but it gives the user the ability to interact with a real-ish product.

InVision's tool makes it easy to share your prototype with users. You can give them access to leave comments, as well as, click from one view to the next.

Additionally, you can start a live share with users and watch their every action as they complete various flows and tasks. What a great way to collect real-time data.

Similar to paper prototyping, designers can make updates while the user interacts with the design. This allows designers to collect data and make immediate and informed design decisions to improve the overall experience of a product.

Did I mention that InVision is cheap and even has a free plan?

All three of these techniques don't require client buy-in. The only thing clients should bring to the table are their users. Once you have their users, you can collect data, iterate on poorly performing designs and produce a tested / proven product for day one.

Questions? Reach out to us. We are more than happy to talk about how we conduct cheap user testing on the fly.

More posts
  • Tips and Reasons to Embrace Remote Work

    Although it’s not an option for all businesses, there are so many benefits to remote work and I’m not sure why more companies don’t offer the option if it is possible.

    Read More
  • Should I be using global or local Sass variables?

    Sass variables allow developers to build flexible, modular and consistent stylesheets. However, at the same time, they can cause just as much harm as they do good. Let's explore when and how to use global and local variables in our stylesheets.

    Read More
  • Getting Around API Rate Limiting

    Anyone who has had to work with an external API knows the problems that can occur when there are a lot of users hitting endpoints that directly pull from the external API's.

    Read More