Using real data in (Figma) prototypes is a headache: here’s how we do it.
Who needs real data?
The power of a supermarket app lies in the fact that the experience can be configured according to each customer’s shopping behaviour. Imagine entering a classic supermarket to find products arranged by what you usually buy, wouldn’t that be handy? At Picnic, a customer’s purchases page always shows their most bought products — with customers expecting this familiar landing page in their shopping journey.
Often times, we consider improvements to such content-rich areas of our app. When this happens, we want to quickly prototype what these changes look like. For example:
- How would it feel if we simply showed you all the products you bought sorted by how many times you bought them?
- What if we group them by isle (or category?) Which isle should we start with?
- How would this look like for a customer who uses Picnic mostly for stock-able products? Or for someone who only eats plant-based?
This highlights how designing and testing the picnic app poses a few challenges:
- Making prototypes where the nature of products displayed matters requires us to use real data. Even if we just want to *get a feel* of what a proposed change might look like.
- Making prototypes where the nature of products displayed does not matter often still requires us to use real data. Customers not seeing *their* own **supermarket makes the app more difficult to recognise and faulty data distracts them from their task, influencing results.
Our 3 approaches to create prototypes with data
Let’s use the following example: we’re considering the design of the *Purchased* page, which displays products that are often bought by a user. We’re considering different structures for the page which we want to prototype. We can assume that:
- we have all the data available (usually in the form of a CSV or Json), but it might not be already formatted;
- the user gave us consent to use this and their data;
- we want to massage the data in some way. For example, grouping products by category, or applying a discount to *some* products;
- we want to be able to repeat the process for different users.
Given these requirements, we highlight three ways in which we’d approach the propblem of creating such prototype.
1. Manually in Figma
One approach we commonly use is simply doing it ourselves. In order to facilitate this, we have built some additional tools that allow us to quickly access and copy paste product information in figma (such as the image of a milk carton).
Pros
- No setup necessary
- Most freedom edit the design during the process
- Works best for proof of concepts, or for explorations
- Interactions can be added in other tools if Figma is not enough (we like Principle).
Cons
- Slowest approach if we need to create long pages.
- Completely unscalable for large sets of products.
- Limited ability to tweak data afterwards (if the concept changes we might have to start over).
2. Code prototypes
We’ve tried to implement the desired logic in a realistic prototype. The actual tool used will depend on what we want to achieve. Notable mentions are the Framer family, and just good-old native code.
Pros
- Most realistic approach. We had customers not realise they were not using a real app until they stumbled on unsupported links/functionality.
- Easiest to replicate at scale (for e.g. a handful of different empoyees and users to test with)
- Allows to bake in realistic interactions such as our add-to-basket animation, making for an even more realistic experience
Cons
- Lots of work to start up, not worth it for small prototypes.
- Designs are not visible in our design tool of choice (Figma)
- Requires some familiarity with code.
- Compromised tooling: no one-tool-solves-it-all. Each has significant limitations (e.g. unability to do remote testing if using a native iOS app)
3. Google sheets sync, Python, Figma
The last option is somehow combining the two. For this, we use Google Sheets Sync to transfer data from google sheets to figma. Given how the plugin works, the data needs to be already massaged and modeled, so we use a simple python script to do that. The resulting workflow combines the best of both worlds.
Pros
- Versatility of code for data manipulation
- Designs stay in Figma
- Can scale easily*
Cons
- Still requires some coding and modelling data
- Extremely limited by what can be done with the plugin
- *It’s easy to create big canvases so full of layers that our Figma ends up running out of memory very often.
Conclusions
Prototyping with real data is still a pain and something that is extremely difficult to do rapidly. Apart from some rare cases (micro interactions), we almost stopped doing realistic prototypes in code. Altho we love the idea, it’s just too slow and hard to maintain, especially at the beginning of the design process, and not being able to iterate through designs in Figma is a significant pain point.
We long for a tool that brings together the power of code (or low-code automation) for data manipulation within Figma. It seems that product designers have to be familiar with many tools and that almost no no-code or low-code solution exists to fill the niche of filling a page with real data.
As for importing data via sheets sync or doing it manually, we simply choose based on whether it’s a quick one-off or something we see ourselves wanting to replicate or scale up in the future. We’re not quite able to predict it with complete confidence (I threw away a lot of prototypes, and I wasted a lot of time manually importing stuff I could’ve automated), but we get better the more we do it. We strongly consider automating our data imports if:
- What we’re designing is purely based on content (or data) presentation or architecture, or
- There is a justifiable benefit in using real data for each person who will see this, or
- We can re-use the output or the automation if we want to explore variations of the same concept with minimal effort, or
- It would take similar (or more) time to do it manually.
All other cases can be solved with a hefty ⌘C and ⌘V workout.
