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 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.
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.
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.
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 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.
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
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.
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.
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.