Iggy Igner

Magic plastic.



ONLINE: Front end + Back end engineering, technical documentation design, software library contribution, MOCKUPS, UI, communication design

OFFLINE: sales engineering, PRINT DESIGN, EVENT PRODUCTION, hardware testing, 3D Printing

POSITION: Software Engineer & Designer

SnowShoe provides developers with the basic API, libraries and hardware they need to create remarkable digital:physical experiences. Our special sauce is plastic that can be uniquely identified by smartphones. This hardware has no batteries, no power, no circuitry, no antenna and no moving parts. After placing it on any touch-enabled device, our algorithm can identify the particular stamp in contact with the screen. Our team has consistently innovated at the intersection of physical hardware and mobile experiences, with specific expertise in API services, algorithm design, 3D printing, web and native app software products, developer-facing platforms and offshore manufacturing.

As a “first employee” and one of two software engineers, I helped create an active developer platform used by thousands. Our innovative hardware manufacturing process brought mass customization to mass manufacturing. SnowShoe is a venture backed IoT startup with investors including Techstars, 500 Startups, Foundry Group, Lowercase Capital, Pharrell Williams and Nas.


30k+ units sold

1M API calls

3k developers engaged

$3.5M raised




Owned product redesigns from ideation through code deployment


Creative direction + brand collaboration for new products


Led creative + technical integrations with Disney, Red Bull and various music artists. Personally designed and developed an app for Red Bull that resulted in 80% conversion.


Designed UX/UI flows and visual assets



Developed full stack client apps using our tech + core product features


Deployed analytics solutions that allowed for data-driven design decisions


Supported public front end + back end software libraries and documentation (jQuery, Ruby, Python, PHP, Android)


Named author on patent covering physical/digital interaction with realtime databases




1. Defining the problem

Let's point out the obvious - our product is weird. It's really cool, but really weird. When I joined the team, our largest struggle was communicating how to use a physical object in unison with an electronic device in a way no one ever had before. We had inbound interest, but closing sales almost always required phone calls to talk through use cases and limitations.

Defining the problem:

Before we could tease out our specific communication needs, we spent time bringing to light the problems with our product and our current communication style. Major takeaways included re-segmenting our current customers into profiles. From there, we were able to craft a web conversion plan that spoke to each of these segments. Simultaneously, we took into account best practices for our desired conversion: convincing site visitors to buy a demo kit. Above are notes from various whiteboarding sessions and in-person meetings with our mentors specializing in customer behavior and growth metrics. 

After talking with a variety of customers, we figured out the key issue: static images and text didn't adequately explain how SnowShoe worked.

new Hardware:

While planning the homepage redesign, our team was also developing our V2 hardware. Our new hardware would be produced by injection molding machines on an assembly line, whereas our V1 hardware was 3D printed.

While other members of our team concerned themselves with the hardware design, material science and mass manufacturing protocols, our crew of 2 engineers wrote software to support this process. Personally, I spent my time

  1. Writing a program that would add a pre-determined amount of variance to each of our hardware patterns, and then output a file that could be used by the manufacturer to produce the unit
  2. Creating documentation for the internal software we created for our overseas workforce
  3. Hardware testing + logistics stateside 

The Needs (per user profile):

SnowShoe needed a new way to communicate its product. While this would become a multichannel process over 2 years, our first area of concentration would be getting new data. We'd only get data if we sold demo kits. And we'd only sell demo kits if we had a homepage that drove conversion. So first things first...a homepage that answered a few specific customer q's:

  • Touch a hard, plastic object to my very expensive touchscreen? Really?
  • What does it do?
  • How do I do it?
  • How can I make it work on my website or app?
  • How can I buy it?

Also, it had to be modular - simply by changing a few photos, videos and text, we should largely be able to use this same design as we transferred to our V2 hardware.

The Solution:

Use motion and diagrams to show how SnowShoe works, and then craft a new homepage + updated technical docs that use these techniques. Deadline for defining needs, copywriting, asset design, and code deployment to coincide with a software launch: 2 weeks.



2. Build: Design + Development

Decide on a template:

In order to keep our tight timeline and deliver a product that was responsive, cross-browser and cross-device compatible, I used a pre-made template. I would then heavily customize the source code from there. These structural designs were researched and presented to the cofounders for product sign off. With its mix of simplicity, lightweight structure, and ability to add and remove sections, Option 1 made the cut.

Concurrent design and development:

While the core structure was solid, the template needed to be adapted and new assets had to be created to accommodate the following:

  1. Hero video background - the clearest and most effective means of demonstrating our product's unnatural use to new customers.
  2. Animations - clear CSS animations that bring use case scenarios to life.
  3. Custom assets - diagrams and graphics that allow us to compare SnowShoe to other technologies graphically would form the backbone of our communication design.
  4. Video modals - via a third-party, responsive lightbox + dialog script, a video lightbox would allow us to cleanly display videos showing use cases and control playback with cross-device compatibility.
  5. Software libraries - icons representing all software library integrations we offer with direct links to our Github repos so customers may easily implement SnowShoe in their programming language of choice.
  6. SnowShoe functionality - touching a stamp to our website had to demonstrate our technology. And it had to do so with an updated version of our jQuery library with a new help messaging feature that could display custom, textual hints onscreen to guide users toward best stamping practices.
  7. Analytics - decisions on site improvements from here on out would be data-informed.

Micro-iteration ruled here. There were no mockups. And almost all actual design was done on the fly, in-code, without much being documented. Inspiration from other websites arose, custom product photos were taken, stock photos searched, and iPhone videos filmed. Yes, that is me working off of 2 computers.

There were a few late nights. Things got weird...

Lesson learned: Especially when crafting video assets (albeit for the hero section), aim for magic. It's important to hire someone who can spend their time shooting and editing not just for style, but for emotion. Even though our homegrown video generalized our technology to a wider audience, it's quality and lack of emotion rendered it a flub. Luckily, we had an incredibly talented customer that professionally filmed her own video with kids in her classroom. Shortly after launch, we switched to this.

Even as we transitioned to V2 of our hardware, we continued using this old video because it showcased the "magic."

Animations and Diagrams:

SnowShoe stamps were 3D QR codes, effectively able to trigger any action in a web or native app after being placed on any touchscreen. In order to showcase its multitude of use cases, I crafted a motion graphic utilizing CSS animations. Iconography representing these use cases "floated" around a phone being stamped by a SnowShoe, representing "payoffs" that could be triggered by using a stamp.

As a developer platform (that also sold hardware), our main product was the SnowShoe API: an authentication service that recognized any stamp being touched to the screen. With a returned serial number, the third-party app utilizing SnowShoe's technology could use this information to trigger a particular event: like starting an iTunes download or unlocking a player in a video game. To clarify our service and make clear that customers were responsible for building their own applications, I was tasked with updating our technical docs with custom diagrams and code samples that displayed the software architecture options available to them. The full set is live at snow.sh/docs.




After the homepage was deployed in early 2015, it became a work in progress. Sections were removed and headlines tweaked based on customer feedback and changes in company goals. 


  1. Homepage code (optimized for template inheritance)
  2. Large assets served from an edge cached CDN
  3. Edited video files
  4. Vector diagrams
  5. Updated software libraries

A few months later, after working out the kinks, we launched our V2 hardware and successfully used this homepage template as our springboard.


Case Study

Red Bull

SnowShoe partnered with an incredible group of clients over the past couple years. While our engineering team hopped around the full stack, my focus was on crafting the customer-facing side of our product + building apps for clients that implemented our tech.

Red Bull hired us to drive engagement with their new music artists during the 2015 30 Days in LA concert series, a month-long lineup matching on-the-rise talent with heavy hitters in the industry like A$AP Mob, Chet Faker, Run the Jewels and Big Sean.

I personally led the design and technical development of the full stack web application commissioned by Red Bull. 

The Goal:

Drive digital listens of up-and-coming artists opening for show headliners. 

Users would simply visit a shortened url like win.gs/30days. A Red Bull ground team member would then stamp their screen, triggering an iTunes download from an artist playing that evening.


The initial plan was to drive engagement with the Red Bull Sound Select (RBSS) platform. Red Bull stakeholders opted to first push users through the RBSS signup flow. However, after taking into account the current platform's asset load times, 4G connectivity at concert grounds, and deciding to optimize around the primary goal of artist listens, we agreed I should build a standalone solution. In order to accomplish this, the next version of the app would need:

  1. Clever cookie management allowing us to anonymously track stamp uses (and song downloads) on a per device basis
  2. Gated downloads allowing a single stamp to deliver multiple, indvidually trackable downloads when passed between friends
  3. Low latency asset loading even when WiFi was not available
  4. Full analytics for engagement + conversion
  5. Optimized iTunes flow for iOS users
  6. Email flow enabling users of devices without iTunes to claim the song at a later date

From there, I produced UX flows and a technical plan that took into account all major devices and mobile operating systems. I then personally developed the final product, and led its integration onsite with the RBSS technical and digital teams.

The Result:

For the first time ever, Red Bull now had data on who was listening to the artist's music after a show. And which new listens could be directly attributed to that show. Even cooler - some implementations resulted in over 80% conversion. As a result of the implementations in LA, Red Bull decided to renew the relationship for a series of concerts in NY.




We solved some fun challenges at SnowShoe. Unfortunately, we figured out some of them a little late and our funding window closed in early 2016. At that point we had a choice - spin down the company and return the remaining money to investors. Or go for broke, and do everything we could to find a home for our technology and a win for everybody at the table. We chose the latter...


In May 2016, after a few exciting (though unsuccessful) acquisition attempts, the founders decided to roll down daily operations. Our API is still functional for our customers, but now with a new pricing model for new buyers. We all had multiple chances to leave, but we decided to stay. I was there when we laid off each other. And I was there when we all showed up to work the next day anyway. Until the next adventure with those misfits...