Building Kit: The Canvas
The core component of Kit is the kit page, where a creator can showcase a collection of products centered around a specific activity or topic. We recently spent some time redesigning the kit page, as well as adding a few new features — you can read more about that here.
The biggest change is the addition of what we call the “canvas,” a snapshot of product images within the kit at the top of the page. Having learned some lessons along the way, I’d like to share our experience designing and developing the canvas, while shedding some light on our product development process here at Kit.
Goals
Our redesign effort was largely guided by user feedback. On a very high-level, our goal for this sprint was to “make kit pages silkier,” as Naveen would say. To drill down what this means:
- Improve the concept of a kit as a unit. We wanted to better communicate the idea of a kit, after seeing our users struggle to understand the product. A user should also be able to get a sense of what a specific kit is about without having to scroll through each product.
- Open up a potential place for custom media. We wanted to allow our creators to add their own personal touch to their kits. This could be anything from their own flat lay image, a branded banner, or a video — all things we’ve found requested through user feedback and research.
- Add more visual flare. We found that our users were confused about the array of images at the top of our old design, and mentioning that “the images were too small.” We wanted to iterate on this element to address this feedback and further enhance the kit page aesthetic.
Process
To meet these goals, we came up with the canvas (kudos to our designer Aloke 👋). The initial designs pitched two ideas: adaptive coloring and adaptive layout.
Adaptive coloring
We had some ideas about using color to help personalize the kit page inspired by iTunes’ dynamic backgrounds. We were excited to try out color thiefing, and did a quick exploration to see what was possible.
Our version of color thiefing extracting a color from the user’s avatar and overlaying it on the canvas. We tried a few color extraction libraries: adaptive backgrounds, color thief, and vibrant.
All of these libraries worked well enough, but we settled on vibrant.js for its API and bright color results. The exception with this library is with grayscale images, a known issue that results in a non-grayscale color palette.
After testing it out on staging, we quickly noticed that most extracted colors were fairly flat, boring colors. This made sense considering avatars were typically human faces, so of course our color extractions would result in skin tones.
We played around with different palette options, but they were wildly inconsistent. In an effort to maintain predictably appealing colors, we switched over to a fixed color palette, with each kit mapped to a color from this selection. While this gave us more control, we decided it proved to be too distracting. In the end, we dropped the color altogether and stuck with a simple, dark background.
Canvas layout
Ideally, the canvas should show all items of a kit in an interesting layout. We had a difficult time finding a library that would fit a fixed number of images into constrained dimensions. So, we did an exploration with some options like Packery, pairing it with sizing patterns, and dynamically adjusting image sizes based on the number of items.
There were a few considerations with this approach:
- Our implementation wasn’t perfect at fitting images within the boundaries.
- Loading so many images at once would often result in a staggering load and a bad UX. Waiting to show any image until all images were loaded might take too long. Not to mention we would eat up a ton of data for our mobile users.
- At a high enough number of images, each image becomes very small. Would the products even be recognizable at that scale?
We knew the average number of items in a kit is less than 10; with that in mind, instead of trying to accommodate for any number of images, we decided to design around this average figure. We landed on designing individual layouts for one to ten images, for desktop and mobile, which will work for most of the kits on our site.
This design looked great as we viewed it on a few of our staging kits. At the time though, our staging data didn’t quite reflect the types of kits we had on production. To get a better sense of how this would look with “real” kits, we copied over some production kits into our staging environment.
After seeing our canvas layout with a few production kits, we noticed that some images were unrecognizable.
Cropping images at the aspect ratio on desktop usually led to strange looking images. We decided it was best to simplify on desktop by keeping images to one row, and limiting it to six items.
Launch
Several refinements later we launched with a simpler version of our designs.
Bento.js
We’re open sourcing this first iteration of our canvas layout as a small JavaScript library, Bento.js. It makes it easy to create a header element out of multiple images as outlined in this post.
At the time of this writing, the library uses the naive approach of fixed layouts for up to ten images on mobile (six on desktop). While this works well for this version of our kit page, it’s a bit too opinionated. We have plans on improving the flexibility of Bento.js, including its layout implementation.
Lessons learned
Designing around UGC is hard. User generated content is a much different beast from other types of media. The adaptive colors in iTunes works so well due in part to basing the colors on album covers, which are typically colorful and artsy. Standard product photos are also especially plain, so it’s a challenge to build elements that are both beautiful and versatile enough. Since this kit page redesign, we’ve also allowed custom image uploads for product recommendations. We expect to continue to iterate on the kit page design based on these new uploads.
Test with production data. Designs are sometimes created with the ideal situation in mind. Having a testing environment hydrated with production data proved to be invaluable. Moving forward we are testing our designs with real data in an effort to catch things earlier in the process. Using a tool like Craft makes this process even easier by enabling designers to create mockups using real data off the bat.
Keep a tight feedback loop. As a startup it’s important for us to move quickly. The dynamics which worked incredibly well during this sprint were rapid design explorations and prototypes coupled with constant feedback from the team and our users. It allowed us to play with our designs, spot issues early on, and refine before launch.
Hope you enjoyed this post! If you have any feedback 🗣, suggestions 💡, or just want to say hi 👋, send us a message @hashtagkit on Twitter.
