Sandboxes at Etsy
A Better Experience for Everyone
Here at Etsy, sandboxes are places where designers working on digital experiences can build whatever they want without blowing things up. At their core, sandboxes are really simple: just folders with some template files, hidden from the public. But their technical capabilities, simple setup, and minimal learning curve make them an extremely powerful tool to sharpen our coding skills, work closer with engineers, and, ultimately, improve the user experience of our site. Over time, they’ve evolved to be a valuable tool for designers. But only a few years ago… they didn’t even exist.
Back when I was a design intern, the Shop Management team was rebuilding the tools that sellers use every day to manage their shops and were getting close to finishing the first version of our new web toolkit, a set of centralized CSS components used for building features on Etsy. Teams were eager to try out the shiny and new styles, but there just wasn’t an easy way to play with them and test them on the product. At the same time, user research at Etsy was starting to take off. Each team was doing its own thing to get prototypes working for usability testing: some were creating clickable prototypes with Sketch, while others were writing HTML prototypes completely from scratch, occasionally requiring help from engineering just to test their idea. Great stuff, but it was taking too long to produce.
On my team, we were improving an existing tool and wanted to use the new components from the web toolkit. At the same time, we wanted to experiment with different ways to prototype quicker. Our goal was to do two days of usability testing each week and make small changes in between sessions. The first few rounds were rough. Things didn’t work. The user researcher wasn’t able to connect because of permission errors. We continued to iterate on our process to find better ways to test our designs.
When I left at the end of the summer, we were getting close. With the help of some engineers, we had a place that user researchers could access and that designers could push changes to between sessions, but we were still copying pieces of the web toolkit over and writing our own CSS to make things work. It worked, but it wasn’t good enough.
When I returned to Etsy as a full-time product designer, Diana Mounter was excited to tell me that we finally set up an area of everyone’s VMs (virtual machines) specifically for sandboxes. This meant each designer had their own sandbox that by default included the web toolkit on every page and every template. It was incredibly easy for designers to experiment with and required very little setup. It was unbelievable how fast you could prototype a flow just by writing some HTML and hooking together templates. The best part was that how they worked was consistent from team to team, which meant research didn’t have to relearn a new method every time they did usability testing.
Sandboxes automatically include the styles and patterns found in the web toolkit by default, which means we can design, build, and test multiple versions of designs directly in the browser. They allow us to focus on more than just visual design, as we now have more time to consider user interactions, states, and responsiveness. For designers familiar with the all of the classes and comfortable writing HTML, designing in the browser can be faster than designing in Sketch. For new designers, creating your own sandbox is part of onboarding (remember, it’s just a folder!), where new designers go through a number of tutorials to familiarize themselves with the web toolkit and then continue to use the space to practice or prototype.
Another huge win is the ability to make changes and iterate quickly between usability sessions. Making changes is fast (gone are the days of exporting 50 new JPGs for a copy change), and being able to quickly test multiple prototypes on the fly has greatly improved our usability testing. Though, arguably, the best part is that when we test, users are able to interact with things like inputs, buttons, and dropdowns. They can actually type in them. The native keyboard works. Interactive components like overlays work the same way they do on our site (taking only seconds of work to set up). All of these small details make the experience our usability testing participants have much more real, which means that the feedback we’re getting is focused and accurate. And while we’re on the topic of real, we recently added the ability to build prototypes using real data. With just a short snippet of code, things like names, avatars, and listings are pulled directly from production, making prototypes even more real.
In most cases, working with other prototyping tools takes a lot of effort, but the finished product can’t be used by engineers. It’s unfortunate that we as designers spend so much time mocking things up just to have to start over in code, or worse, spend even more time getting it ready for an engineer. The code we write in our sandboxes is almost always production-ready, which makes handoff and implementation faster and easier for the engineers. As a bonus, when a designer needs to make tweaks in production, they’ll be much more comfortable doing so. The markup is the same.
Sandboxes provide our new designers with spaces to learn about our web toolkit, practice their coding skills, and understand our design systems. They’re spaces to play, iterate on design quickly, and prototype. We use them not only to understand the front end architecture better and to build better relationships with our engineers, but to learn more about our users and to make usability testing as close as possible to the actual experience. At the end of the day, sandboxes are just another tool in our toolbox for creating better user experiences. But they just might be our most powerful one.
