During 2018 I did a year long internship with a local SaaS startup, Atomic. Their product was an advanced prototyping design tool, which saw hundreds of thousands of users before the company's pivot after I left. The team was relatively small, so I was able to work on some pretty impactful stuff, including educational content for the platform, marketing collateral in the form of customer success stories, and engaging the community with sample projects and hot-tips on their Facebook group.
As part of this project, I used Augmented Reality to prototype form quicker than building real life models, for instance times that I couldn't be in the workshop building real models or needed to test a small idea without spending time using foam/wood – I used Fusion 360 to model my designs, and in some cases textured them using Substance Painter. Finally, I exported them as a .USDZ file (Apple & Pixar's new AR file format) and can share them to friends & stakeholders to visualize the product in their own spaces, in life size.
AR mode only works on iPhones and iPad.
The problem is, it's genuinely hard to figure out how much your summer roadtrip might cost. You can easily figure out accomodation costs, and you can budget for food costs, but unless you know your car really well it's hard to budget for gas prices – which, as it turns out can be fairly expensive!
We built Roadtrip to make it easy to figure out how much your road trip is going to cost, based on fuel prices. You simply enter your starting location, your destination, your car’s license plate and fuel type, then Roadtrip calculates how much it is likely to cost you.
Originally Roadtrip required users to enter their car’s fuel efficiency in KM/L. However, we realised something in user testing: Nobody in their right mind knows their cars fuel efficiency. Literally no one we talked to. So it was back to the drawing board, we had to come up with something that was easy for people to enter, but accurate enough that it wouldn’t show misinformation.
We considered having an option between 3 different car types, but after some research discovered that car’s since 1995 have become 25-30% more fuel efficient, so using an average could end up being very inaccurate.
So we thought, we need something that everyone knows about their car, that makes it unique. We considered using a database that had a variety of different car manufacturers, models, and years – but this result made the user experience a lot slower than we’d like from a simple calculator, and it meant it always had to be updated with new cars.
Then we had a breakthrough: What if it was possible to find out a car’s fuel efficiency, based on it’s licence plate. Lucky for us, it was. The team were able to create an API using an existing New Zealand licence plate fuel efficiency database, which meant we could call our own API and get the car's fuel efficiency. Magic.
When I joined Atomic recently, I was excited to learn I’d have the opportunity to be hands-on, making sample prototypes and sharing them with the Atomic community. Some will be ideal for everyday prototyping use-cases, others will be more for fun, to illustrate what Atomic is capable of, like the sample I’ll show you in this article.
This sample shows key steps in an online clothing purchase. You can browse through (really expensive!) shirts & pants before adding items to a shopping cart by clicking on them. You can select any items you like and the prototype does the math to calculate the amount to pay.
Historically a layout like the one in this prototype would be static; the garment images, labels and prices would all be specified during the design phase, and then baked into the final prototype. The first part of this sample I want to highlight is how it uses Atomic’s components and data sources capability, to build a modular, data-driven layout.
Each ‘clothing item’ is a copy of the same layout component. The component defines the style and layout of the item.
The awesome part is that the designer (me) didn’t have to go in and manually add each photo, item name, price, and brand to each one of these components. Instead I simply connected the spreadsheet to Atomic, and the data from the spreadsheet such as the name of the clothing item, price, photo & brand are automatically imported into each component. It also meant that if I wanted to see what other items looked like, or I changed my mind on which ones to include, I could easily swap them out.
And get this: to add another item of clothing to the prototype, all I have to do is copy & paste a component.
The second part of this sample I want to highlight, is how the prototype responds dynamically to user-choices.
This type of realistic experience can be crucial to your user testing. Instead of distracting your testers with rigid instructions about where to click, and being unable to see how testers respond to things like the final price based on their preferred choices.