AirTable as a Band-Aid for User Testing

Lookback is a must, Instabug is godsent.
When you can’t use either, Airtable is there to help.

The Bear Grylls meme Improvise, Adapt, Overcome with the text saying When you want to use specific user research tools but your developers cannot manage to implement it

The Renault app I had been leading design for had gone through its usual paces of pre-launch research and design iterations, and we were ready to take the next step during development, which requires feedback from a larger audience to work out smaller details and unforeseen issues.

However, the platform we used to develop the app (a tool that provides a cloud IDE, React Native-like JS-based library, and a bunch of distribution tools) did not support the third-party SDK’s I asked for at the time, so I had to come up with an alternative solution.

Why Airtable?

I really love Airtable. I created database designs and prototyped with its API (a whole another article), created forms to collect data, and used it to take notes for many things, including my customs declaration forms when moving to Canada. (Sooo many fountain pens.)

If you need to take notes for some reason and need to show it to someone or sort it out later, Airtable probably has a way to do that.

There are even posts and podcast episodes about using Airtable for user research.

Our Use Case

So, let me get into the details.

We needed a form. Airtable allows you to create forms from tables, so we would start with our basic fields; a long-text column for message, an attachments column for a possible screenshot, and a phone column for the ID of the user. As the app uses phone numbers to authenticate users, we just made that the default identifier for users.

An Airtables spreadsheet with user, feedback, and screenshot fields.

After that, creating a form is just two clicks away. It is a view you add to your table, and it generates the output automatically.

The option to add form view in the app, with a description saying: Create a shareable form that populates rows in your table, send anyone the form for them to fill out.

The created form can be edited to include or exclude any fields you want. For example, later iterations of the table is used to add tags, and assign tasks to people, which are columns inside the same table but are never shown in the form as fields.

Form edit screen, with drag and drop areas to add available columns to the form, and a form field shown with editable title and description areas.

After you are done with the form, you can preview it. The preview link is also the final URL to share the form, so you can just copy and send it to anyone

The generated form, ready to fill out and submit.

Airtable supports form prefilling with query strings. My intention was to use this feature all along, so that registered users who wanted to give feedback would not have to fill in their numbers over and over again.

Airtable form page with URL query strings targeting specific form fields and filling them with passed values.

The link to the feedback form already has the phone number embedded with this trick, so whenever a user decides to leave a feedback, they follow the link and their phone number is automatically filled.

Getting Information, Sorting Data

We got hundreds of responses in a very short amount of time. Sure, the method is not as intuitive as taking a screenshot and having a form pop up, and it does not give the option to record screen to get better feedback, but we still managed to get decent amounts of data which we used to fix bugs and prepare other researches.

I wanted to provide some compensation to initial participants, but the company already had an accomplished -albeit extravagant- tradition in place, and we had to go with it. We gave a small gift for the most amount of useful feedback submitted for certain set dates, which we filtered for, and then grouped by phone number and sorted by count. No SQL, no nothing –just a few clicks and we got the results we wanted.

For reporting, I set the ~~document~~ base up so we could use additional columns to tag issue scopes and assign tasks to groups. We also created a second ~~sheet~~ table to leave comments that were connected to the feedbacks, and had columns to link Github issues back to them. This does have a tendency to get out of hand rather quickly, and like any other project management tool, you have to be careful while entering the data. But it was a fast and efficient way to get data and information we needed.

Use Again?

Absolutely.
There is a time and a place for every other research type, and we are still moving forward with Lookback/Instabug implementations, but in a pinch this is a very fast method to capture user input and do some analysis without much technical experience. Especially for designers, it definitely is a game changer.