Zach Sherman

I design and build digital tools and toys

⌇ zach [at] anemon.es

⌇ github ⤴️

⌇ are.na ⤴️

⌇ San Francisco

RESUME.PDF

I am a designer, engineer, and community organizer, and I want to spend my life building tools that expand our ability to think and create. I learn quickly and like wearing a bunch of different hats. I can help design, build, and user-test your frontend and have experience coordinating teams with wildly different backgrounds.

I believe that effective design emerges from understanding how your product fits into social systems— my diverse experiences have prepared me to build products for a world that extends far beyond Silicon Valley.

Used professionally: HTML/CSS/JS, React + Redux, NodeJS + Express, Git, Figma

People who have influenced how I think about computers, their role in society, and our responsibilities as designers and developers: Bret Victor, Gilbert Simondon, Francis Tseng, Paul Chiusano, Laurel Schwulst, Cade Diehm, the folks at Ink and Switch, and many others.

Open Work Labs (July - Nov 2019)

Product Engineer

“I had a blast working with Zach! He brings great energy, healthy skepticism, a strong set of values, and an insane amount of talent. I have’t worked with many people that can pick up new skills and deploy them so quickly. From product strategy to dev ops, he’s able to make great things happen, fast.” - Thomas O’Brien

Streams: GitHub version (source code):

Design process:

Through a series of interviews with companies building open-source software, we found that they have a lot of difficulty tracking and organizing their work. Also there lack a simple way to ambiently capture and share that work. Our goal was to turn organizing and sharing work into a continuous, passive process. We wanted to replace the "hey just updated this doc" or "just PRed that branch" slack messages with a tool that updates teammates automatically and enables more asynchronous work. In its early iterations, Streams was an experimental product that created shareable feeds of your GitHub events for any given repository.

I led a series of iterative design sprints– sketching, wireframing, prototyping, and user-testing a variety of organizational schemes for a team’s 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 people desperately needed a way to view all their team’s work in one place, 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) sketches, wireframes and 80% of the figma mockup and was completely responsible for user-testing. I tried to use the onboarding flow to ease users into the understanding the full UI, by presenting a vastly simplified step-by-step walkthrough of sharing updates with a teammate. I then expose the entire UI with the corresponding parts of the ‘compose’ window filled in, so that users can easily see map the questions they answered in onboarding onto the full-fledged UI.

I 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. Document-specific updates take place within their respective apps (i.e. GitHub or Google docs) and via Slack or a project-management tool. A single place to view all of your team’s work was not valuable enough to convince people to construct that place manually with yet another app.

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

OWL website (source code):

Details:

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)

e-worm.club (source code )

Design:

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. Besides being much more visually interesting than our facebook messenger groupchat, e-worm also attempts to solve design problems around conversational, collaborative thinking. The biggest of these problems 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). These threads currently have top-level tags that are chosen from a few preset options when the first post is added. No one has really been making use of these, so I’m in the process of testing out other options.

I also plan to add an ‘export to are.na’ 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 are.na because its interface encourages a sort of public digital memory that I haven’t found with any other software. Are.na 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. I’m still sketching out ideas for how to better tie these two interfaces (e-worm conversation and are.na archive) into one.

The UI is completely navigable by keyboard shortcuts, which can be viewed by holding down the ‘control’ key.

a cute twitter-like UI

notes.e-worm.club

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

Design:

This wasn’t a particularly in-depth UX exercise, but it highlights how I use aesthetics to encourage certain modes of interaction. The original etherpad interface was plain and conservative, but we (the collaborators) are whacked out and radical. Aesthetics set the tone of interaction and I believe that they should mirror the goals of the interface, not fight it. The goals of this interface were (similar to e-worm.club) to create a space for radical, non-linear, collaborative thinking that would preserve those thoughts rather than cast them aside. These sorts of interactions would have been oddly dissonant with the original etherpad interface but were harmonious with (and even encouraged by) my version.

If "beautiful interfaces" were an objective standard than we wouldn’t have UI design trends— I choose aesthetics based on the feelings and interactions I want to encourage, not some handwavey notion of beauty or what’s popular on dribble.

a colorful etherpad document

anemon.es

Details:

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 anemon.es

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.

a little plaintext editor in rust

screenshot of a plaintext editor
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. After studying so many different disciplines, both within and outside the classroom, I learned how to quickly teach myself anything from programming languages to research methodologies.

Political organizing taught me how to lead effective teams and collaborate with people who had totally different backgrounds from my own. We also won a ton of people-powered victories across Chicago and Illinois.

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

Details:

Tech used: Zola, Tera templates, HTML/CSS

I analyze how early Latin American net.art 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 net.art pieces below the title

Techno-Visual Performance (and server)

Details:

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.

Details:

[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

Details:

Tech used: Unity, ARCore

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