Zach Sherman

I design and build digital tools and toys

zach [at]

github ⤴️ ⤴️

⌇ San Francisco


Open Work Labs (July - Nov 2019)

Product Engineer

At OWL, my leadership in the design process and quick learning abilities allowed us to complete weekly design sprints while spending the majority of our time doing external engineering contract work.

Streams: GitHub version (source code):

Design process:

Our team found that it's all to easy for people on teams to lose track of what work their team is doing. Also it's pretty difficult to ambiently capture and share that work. Our goal was to turn organizing and sharing work into a continuous, passive process. In its early iterations, Streams was an experimental product that created shareable feeds of your GitHub events for any given repo.

I led a series of iterative design sprints– sketching, prototyping, and user-testing a variety of organizational schemes for your GitHub events. Along the way, we learned that filtering and grouping the firehose of data is crucial to its usefulness (people do a lot on GitHub). I also tried out a bunch of different UI tricks to filter out information, while making that data easily accessible through user interactions.

For these experiments, I was entirely responsible for the visual design and its implementation. I also contributed significantly to prior user research, application logic (React + Redux), and user-testing. If I had to do it again, I would test Figma prototypes first instead of fully built web apps.

a list of GitHub events ordered by time and group according to their metadata

Streams: Links version

Design process:

The goal of this sprint was much the same as the previous: design a product for sharing your work with collaborators. This time, I tried substituting the work of api integrations (e.g. GitHub) with manual updates by users themselves. If this was something people desperately needed, would they be willing to manually report when they had edited docs or pushed code?

For this sprint I decided to validate the hypothesis with the Figma prototype itself. I created the initial (paper) skeches and 80% of the prototyping for this sprint and was completely responsible for user-testing.

We found that, no, people do not need something like this badly enough to go through the effort of manual updates, unless their work is spread between like eight to ten apps with no integrations between any of them.

a screenshot of a figma prototype of an inbox full of links, each with its own set of comments

OWL website (source code):


I am responsible for all the design and code for the OWL site, including the logo. I also contributed significantly to the copy. We wanted to capture our no-BS, playful attitudes and emphasize our belief in the power of open, transparent work. This site was crucial to establishing the OWL brand early in its existence.

a screenshot of a website with a really cool owl logo

Quasar (my commits):

Quasar is a NodeJS server that allows file or dag pinning to IPFS nodes via (ethereum) smart contract events. I wrote significant parts of the application logic, and was personally responsible for docs and deployment setup.

Post-Grad Projects (from my free time) (source code )


I'm building a custom pleroma client so that my friends and I can have a cute, self-hosted social network to post about politics and art. Right now our biggest problem is the inherent ephemerality of our groupchat— it doesn't really succeed as a collaborative thinking space, because it has no long-term memory. When messages are constantly buried under new ones, it places the burden on us to remember previous conversations. So the ultimate design goal for e-worm is to create a self-archiving conversational interface that preserves thought and helps us keep thinking new things rather than going in intellectual circles.

One idea I'm testing is emphasizing threads in the UI to force us to delineate our conversations rather than having an unparseable monolithic stream of consciousness (as in our current groupchat). I plan to add an export to button on each thread that will create a channel from the thread with each message as a 'block'. Higher level channels will categorize these 'thread' channels by subject. I chose because its interface encourages a sort of public digital memory that I haven't found with any other software. However, itself doesn't have the conversational UI that I think is necessary for a real-time collaborative thinking tool— it's interface is more about discovering and connecting than communicating directly.

a cute twitter-like UI

I forked etherpad-lite, so my friends and I could have a collaborative docs app that was actually fun to use

a colorful etherpad document


Built it all myself; the css isn't clean and reusable but I want to style every page differently anyway. No build step means I can deploy it in one command– $ dat . sends all the files to a dat + http server I have running. Also it has some fun audio effects you should check out (on Chrome please! Firefox audio api is all crackly).

a screenshot of

some cute themes for VSCode

screenshot of a light purple vscode theme

Some Visuals

My friends and I threw a party and I made some sick visuals to go with their DJ sets using the amazing hydra video synth.

Relevant experience:

↘︎ Product Engineer @ Open Work Labs (July 2019 - Nov 2019)

↘︎ Student @ University of Chicago (Sep 2015 - June 2019)

Things I do well:

↘︎ learn quickly: new tech stacks + programming languages, work frameworks, design tools, etc.

↘︎ quickly sketch out designs and prototypes

↘︎ collaborate within and outside of the tech world

↘︎ employ a broad perspective informed by years of social sciences study and community organizing experiences

Professional experience with:

↘︎ HTML/CSS/JS, React + Redux, NodeJS + Express

↘︎ Design Sprints, Full-Stack Engineering

↘︎ Figma, Inkscape, Adobe CC

↘︎ IPFS, Git

Passionate about:

↘︎ functional programming, no-code tools

↘︎ UIs that clearly map interaction to result (e.g. Ableton, Notion, Figma ❤)

↘︎ systems-level thinking + wearing a bunch of different hats

↘︎ ↝unicode arrows↜

People who have influenced how I think about computers, their role in society, and our responsibilities as designers and developers:

↘︎ Bret Victor, Ted Nelson, Gilbert Simondon, Francis Tseng, Paul Chiusano, Laurel Schwulst, Cade Diehm, the folks at Ink and Switch, and many others.

University of Chicago (2015-19)

At UChicago I studied design, ecology, sociology, computer science, etc., learning to think systemically about a wide variety of problems. Political organizing taught me how to lead effective teams and collaborate with people who had totally different backgrounds from my own (and win a bunch of people-powered victories!). In UChicago's design program I practiced using my systems-analysis skills to create useful products. Most importantly, I learned to quickly teach myself anything, whether it's a programming language or a design approach, and to collaborate and communicate effectively.

Selected Projects ↴

All of these were done completely on my own. Most are from when I was first learning to program, so the code quality here is definitely below my current standards.

B.A. Thesis: Campeones de la WWW


Tech used: Zola, Tera templates, HTML/CSS

I analyze how early Latin American wielded playfulness to undermine neoliberal rational-choice narratives. I designed and built the website myself using a static site builder written in Rust.

screenshot of my thesis homepage - images of various pieces below the title

Techno-Visual Performance (and server)


Tech used: NodeJS/Express, websockets, Unity, GLSL

I was invited to perform at an audiovisual festival on campus, along with friends who make claymations and techno music. For the show, I developed a NodeJS web app that used websockets to allow people to control 'dancing' characters in the visuals. For the visuals themselves, I created a Unity app that served as the glue between a variety of visual effects: 1) the dancing characters (controlled by viewers' phones via websocket) 2) live-edited GLSL shaders that morphed in response to incoming audio 3) midi-triggered claymation loops and 4) live midi-controlled Unity camera effects.

Over the course of this project I learned how to use websockets to pass data between apps and organized people with divergent talents (animation, music production, and programming) into a cohesive team that produced a brain-melting performance.


[frame-rate on the video is crap because my poor computer couldn't handle running the software and screen-recording at the same time]

[screencap below shows what it looked like with people logged on and controlling the emoji characters]

audio-reactive shader with overlaid emojis

AR Planets


Tech used: Unity, ARCore

I wanted to put a solar system in my bedroom, so I did it in AR.