Nathan Burge

Recent Work

for Products
and Brands

As Design Director at Vector Media Group (we’d eventually grow to acquire Happy Cog and rebrand) my role had two sides: designing for user experience and leading a small team of talented designers. Below I've outlined key areas we focused on during my time at Happy Cog and some of our thinking around process.

A startup has a concept for a new subscription service and needs to brand itself and build a digital product to be the foundation of the company.

View the Case Study

Thinking in Systems

System Design Across Disciplines

Over the past several years I've pushed myself to think in systems when approaching any design challenge and have made this a part of my process. Systemic Design takes a Systems Thinking approach to Human-Centered Design and allows us to make better decisions and work quickly to design products that scale. This applies in varying degrees to different parts of my expertise. For example, when designing a brand identity, it's not enough that we design beautiful assets. By thinking in a systemic way we can design a brand system which can act as a foundation for other designers to build upon. Color, shape, illustrations, imagery, iconography, style, tone of voice should all be thought of in a systemic way.

Of course, Systemic Design also applies to product design. At Happy Cog, I championed this systemic approach. I designed wireframes using Atomic Design principles which can be quickly converted into prototypes and eventually to polished designs. I began to approach every problem in a systemic way. We stopped designing templates and started designing systems that could scale. We used this approach on everything we could: from wireframes to prototypes to content models to finished products.

An atomic system of components for wireframing and design prototypes. Taking a systemic approach to design in Figma, I was able to design a functional prototype that could scale up and integrate higher-fidelity iterations.

View the Case Study

User Research + Design Thinking

Users and

I'm always an advocate of a Research & Discovery phase before design begins. It's critical to the design that we understand our users' needs and document these needs. Most of our projects begain with a Discovery Phase ranging in size from "micro-discovery" for small projects to larger workshops, interviews and other research. I've led a number of large-scale design workshops both in person with distributed teams.

At Happy Cog, my team introduced User Stories into our design process. Over the course of several projects refined our approach to User Stories which led to successful projects both large and small. From initial discovery to launch, we would refer to User Stories and refine them as necessary. When a new idea would be introduced, it can be rated against our existing User Stories. Sometimes we would find a place for the new idea and sometimes we need further evidence of necessity (through user testing.) Often we would agree that a new idea is a "nice-to-have" and would be placed into a future phase of the project.

Design Thinking

Prototyping, Testing, and Iterating

Designers of all disciplines know that prototyping a design leads to an understanding that would otherwise be difficult to find. Along with our new collaborative approach to product design, we began prototyping earlier and more often in the process. On some projects we began whipping up prototypes in code (html / css / javascript) while still in design phases. Sometimes a rough sketch in code was better than a polished set of visual designs. We began prototyping our wireframes and designs in Figma and sharing them with everyone. This helped my teams to find solutions and helped clients to be a better partner in decision making. As designers, we knew prototyping to be essential. Over time we learned that they could not only improve products but also save a lot of time later in the process.

Team Management

Leading cross-functional, distributed teams.

I was brought on to this design team with the expectation that I could redefine the existing process of handoff from design to development. I spent time observing the process and talking with people from different teams. We started out by “banishing” the word handoff from our vocabulary. We started assigning developers to projects on Day One and inviting them to design briefs. We wanted everyone on each project to understand it holistically: where ideas came from and why decisions were made. We replaced tools with collaborative ones and shared ownership of key documentation. With persistence, we built teams that were truly cross-disciplinary.

In the end, I learned that solving this problem wasn't about finding the next great design tool or agile process. It was about creating a culture of open communication between these teams so that every team member – including our clients – could participate, have their voice heard, contribute and take ownership. We applied this thinking everywhere we could. We saw firsthand that you build better products faster when everyone is talking to each other.