About me
Kaleigh facilitating a feedback workshop in the Defense Digital Service offices in the Pentagon, Oct 2019.
Facilitating a feedback workshop in the Defense Digital Service offices in the Pentagon, Oct 2019.

Designers rarely have a linear path. Here’s mine.

I started out as a journalist. I worked in local television, wrote freelance articles for my local newspaper in upstate NY, and absolutely loved it.

It was the perfect outlet to indulge in my need to understand what makes people and systems tick, and use that to tell stories that mattered to my community. If the news industry was a healthier place to land for a young grad with boatloads of student loans in 2008, I might still be in it.

After my time in news, I had stints in supply chain operations and B2B marketing, then moved to Chicago in 2013 to be part of the city’s quickly growing tech startup community. It was here where I got my first taste of user experience design. The ability to ask questions, dig into meaty problems, and help solve them was instantly interesting to me. But even though the work was fun, I found that I still really missed the sense of civic duty I felt in journalism.

This desire to combine the two is what eventually brought me to Truss in 2018, a small government contractor where I could apply the inquiry and curiosity of design to problems faced by everyday citizens and public servants. I worked on multiple projects across several federal agencies as an individual contributor and design lead, while also supporting three senior designers and one design manager’s growth as their supervisor.

In early 2024, I decided to join the United States Digital Service (USDS) and apply my public service research and design skills on the inside, as a member of the Executive Office of the President. At USDS, I’ve been mostly engaged with the Social Security Administration alongside a cross-functional team, working to bring a survivor benefits application online, while also demonstrating a modern and agile approach to software development.

While I can contribute across several areas of the design stack, my depth of expertise lies in content design, strategy, and research. Writing is how I got my entry into design, and is still one of my favorite parts of the work. I feel strongly that the words are the most important part of an interface and will forever be an advocate of plain language and content-first design. And when it comes to research, the curiosity that came with being a journalist back in the day never quite went away. I love to understand what makes people tick, how large systems unfurl behind the scenes, and how we can use what we learn to drive evidence-based decision-making.

In my free time, I can be found practicing guitar, cooking, reading a book, letting off steam on my Peloton, or playing with my puppy, Tito. I keep close to my journalism roots by supporting local non-profit news organizations such as City Bureau and Block Club Chicago – check ‘em out!

Frameworks, methods, and concepts I’ve adopted over the years that give a window into how I like to work

Allegory training: Back in 2020, my then-employer Truss paid for all employees to go through behavioral communication and leadership training with Allegory, Inc. I can’t say enough about how transformational it was in helping me understand my communication style, how my preferences impact how I view others, and what unhelpful soothing mechanisms I fall back on when I’m uncomfortable. I still reference it every day. Christina’s book, Swayed, is a great overview of the general concepts.

Leader Lab: A former colleague, Amy Meng, introduced me to the book The Leader Lab several years ago, which has become another resource that I reference on the regular, in addition to Life Labs’ more interactive trainings, which I also recommend. This book changed the way I approached coaching as a manager, and also how I approached large-scale change both internally and for clients I was working with as a consultant.

Personal voltron: This was a concept I borrowed from Lara Hogan’s Manager Voltron and used a bit more broadly. I have my own voltron of folks that I look to in various situations, and I’ve encouraged folks I’ve managed to build their own as well.

Hype documents: There are a million articles explaining the concept, but I’ve tried to keep one at every job I’ve had by checking in at least twice a year to write down things I did that I’m proud of, and how they impacted the business/organization, people I mentored, or people I managed. It’s really easy to forget all the small stuff over the years, but these docs are a great reminder of all the good I’ve done, especially when times are tough.

Highlighter testing job descriptions: As a content designer, I’ve used highlighter testing for lots of different things, but especially love applying it to professional development using job descriptions. I’ve done this for myself and for folks I’ve supported over the years, with the prompt being anything from highlighting things you feel strong in vs need development in to things you’d love to do someday vs things you’re not interested in doing. It’s a fun visual exercise that can sometimes unstick a conversation about someone’s professional ambitions and future.

Team norming exercises: Though I helped develop some of the exercises that are now part of Truss’s norming library, many thanks are owed to Karen VanHouten and Carmen Bocanegra for initiating the practice and showing me what good looked like. Things like workstream norming, the BICEPS activity, and superpowers and kryptonite helped break the ice on many new project teams and also helped us understand how to work with one another. Won’t go without them now.

Pre-mortems: I can’t think of a tool better suited to align a new team and client around the potential risks of a project and how to proactively address them. I’ve even seen it used as a pre-launch activity, to much success.

Mini Slack retros: I set these up on a project years ago, and have employed them several times since. It’s a great way to get a quick pulse of the team on how the week went.

Meeting notes Slack channels: Our team tried this for the first time on a project with CMS, and I’ve loved it ever since. In addition to our main team channel where day-to-day chatter, async standups, and mini Slack retros went, we created a specific channel just to post meeting notes. After every call (and eventually we started folding in research sessions, too) someone would post the notes document as well as a TL;DR recap and any AIs in this channel. It was a quick way for anyone, including our client, to catch up on the work, and a great way to reduce meeting FOMO.

Decision records: While these have been an important tool in the engineering community for years, I started writing them for product and design decisions five or so years ago and haven’t looked back since. It’s a foolproof way of documenting what considerations and constraints factored into the decision you made, in case you ever have to revisit it.