Building interfaces and shared foundations at PartySlate.

A new way to explore event ideas

My first feature at PartySlate was Idea Gallery. We drew themes from the site’s collection of professional event photography and gave people a place to browse for inspiration as they thought about an event of their own.

I built the feature end to end. It was our first use of React Router and client-side routing: people could move between pages without a full page reload. I defined skeleton loading states and worked with Imgix to optimize the images, paying attention to how the experience felt while content was loading as well as when it was ready.

At the time, our React application was closely tied to Rails and the way it supplied data to each page. Working within that structure could be cumbersome. Idea Gallery gave us a working example of another approach. For Ben Kimpel and me, seeing client-side navigation become a practical option for the wider site was a significant moment.

We delivered the full feature, including the image handling and loading states. I don’t recall it attracting much traffic, but the engineering work proved useful beyond that first release. The patterns I established there carried into the later Find a Venue work.

Starting with the buttons

One of the problems I had been hired to address was consistency across the interface. Shortly after Idea Gallery, I carried out a comprehensive button audit. There were dramatic differences in how buttons were used and styled: borders, backgrounds, fonts, sizes, icons, icon placement and hover states.

I led the audit and implemented the shared button component. Ben helped me find my way around the codebase when I needed guidance. Mark Semon, our visual designer, and I worked together to establish a consistent button interface.

That work also meant improving how design and engineering communicated. Mark was working in Photoshop, and I encouraged him to adopt Zeplin. He was willing to learn new ways of working, including using a symbol library to produce more consistent buttons. We had challenges along the way, but we were able to work through problems that had been holding collaboration back.

The result was something I could point other engineers to and they could use. I remember feedback from Lucas Brandt, an apprentice engineer at the time, that the component was a joy to use. We had more consistent buttons and a shared starting point for the people building the product.

Later, similar audits became useful work to delegate to junior engineers. They could learn their way around the codebase while contributing to the consistency of the interface.

Connecting venue search to the map

Find a Venue took the client-side patterns further. The existing experience used defined search zones. We wanted to add a map view alongside that approach and give people another way to explore the listings.

I owned the entire frontend implementation and the data contracts it needed. That included adapting the existing URL-based API design so the frontend could fetch data as people interacted with the page.

People could drag the map to explore an area. Hovering over a listing highlighted its corresponding map pin and tooltip, and the map tooltips offered quick actions. The results and the map worked together, giving visitors a different way to navigate venues while retaining the existing search-zone approach.

We saw a substantial increase in engagement and in people contacting venues through Find a Venue. Contacting a venue was considered the highest-value action someone could take on the site. It was rewarding to see the engineering work contribute to that outcome.

Helping event professionals get started

For event professionals, getting started on PartySlate could mean creating a new company profile, claiming one that already existed, or joining a company with an existing account. Those paths had developed separately, with different behavior for venues and other event businesses. The registration and onboarding work in early 2023 aimed to make that first experience easier to follow.

The goal went beyond creating an account. A professional needed a path toward a useful company profile, with contact information, images and details about their work. The designs broke that journey into smaller steps, with visible progress, clear actions and layouts for both desktop and mobile. They also accounted for the less tidy moments: missing information, invalid entries, choosing a photo and deciding to finish a step later.

The engineering plan treated these journeys as related flows built from reusable pieces. It called for shared form-validation and upload patterns, explicit navigation between steps, and saving information to the server before advancing where possible. Another priority was making individual steps easy to reach and test, so the team could develop the underlying flow before every screen was finished.

I led and implemented the main flow, then delegated other flows to Katy Cooney and Lucas Brandt. The work gave us a way to divide implementation across engineers while working toward a consistent experience for the professionals getting started on PartySlate.

The flows shipped, but I don’t recall their impact. In my experience, and to PartySlate's detriment, we rarely came back to evaluate the success of these initiatives.

Giving the design system a way to grow

I was PartySlate’s design-system lead throughout my time there. It was one of the priorities discussed when I joined, and the work continued across changes in our team and frontend architecture. Alongside building components, I worked on how design, product and engineering would maintain them together.

That progress was uneven. In my 2020 self-review, I described releasing Storybook and establishing a production path for our design-system work as goals we had not yet reached. By 2023, Soirée gave that work a concrete implementation and a renewed focus on the process around it.

I led the definition of a component-development process that made the decisions explicit. When a new design need emerged, the team would consider whether an existing component could meet it. Design would explain the opportunity, engineering would assess the work involved, and product would decide whether to invest. The process connected reusable components documented in Storybook with corresponding symbols in the Figma library.

I also led the framework evaluation and the Chakra/Soirée work. The evaluation considered maturity, customization, community support and integration with design tools. We selected Chakra UI as a foundation for Soirée, PartySlate’s design system.

We built a fully custom Soirée theme through Chakra’s theme object, with a Rollup build system that integrated it into both our Next.js application and the legacy frontend. That let us bring the same theme into newer and existing parts of the site.

I wanted us to stop negotiating the same interface details at every handoff. Shared components and a common design language gave us something to build on together. Keeping that useful required continued investment from design, engineering and product.

Helping other engineers find their footing

Alongside feature work, I spent substantial time helping other engineers develop. I paired with junior and apprentice engineers, hosted technical lunch-and-learns, and created documentation to help people understand our codebase and conventions. Making it comfortable to ask questions was an important part of that work.

As the frontend changed, there was a lot to learn together. My teaching materials covered React Context, GraphQL and the structure of our shared code. I wanted engineers to have working examples they could refer to and someone they could work through a problem with.

In 2022, I created a style-guide repository and drafted technical documentation to support hiring and onboarding. I also continued supporting colleagues as they took on larger initiatives. That meant making room for questions about the work and helping people communicate what they needed to move forward.

Learning what it takes to sustain the work

PartySlate gave me opportunities to build substantial features and help other engineers grow. It also taught me how difficult that work becomes when responsibilities, priorities and support are unclear.

An earlier effort to move the marketplace to server-side rendering was shelved in 2022. It competed with feature delivery and did not have the dedicated planning and support I felt it needed. That experience stayed with me: a large technical initiative needs realistic scope, shared ownership and room in the team’s priorities.

I also learned that supporting everyone else could come at the expense of supporting myself. Being committed to the work meant learning to communicate my own needs, make limits visible and protect a sustainable balance. Those lessons were hard-earned, and they remain part of how I think about working with a team.