Too many designers spoil the code.

Talu was a first for us. One small step for man, one giant leap for… meltmedia-kind.

When we were starting out building Talu, we were unsure how we’d approach design, and what problems we might encounter, but we put on a brave face and set out to make something awesome.

We certainly didn’t expect to switch designers four times.

A project like Talu usually has a single designer responsible for the look and feel and User Experience (UX). Within one year, however, four designers had worked on – and three transitioned off – Talu, passing assets and ideas to the next designer.

If that seems atypical, that’s because it is. The reasons were not really related to the project, sometimes perfect storms just happen. “It’s not you, it’s me,” one designer after another said as they changed projects or moved on in their careers, leaving Talu behind. This led to some unexpected issues.

With so many designers working on Talu, the consistency of work became puzzling and we were met with a slight roadblock, but not for the reasons you might expect. The new designers, believing the notion, “What was done before is what we’re doing now,” led to a lack of design inspiration and a stagnation of imagination.

When a new designer takes over a project, any project, they tend to take what was designed before as mandate. This is where the trouble for a designer can begin.

Turns Out, the Limit Does Exist
Taking over a project creates limitations. When you take on a project already well underway, there are almost certainly decisions that have been made and you might not agree with all of them. Or any of them. You have a choice to either work within the constraints, or resist and cause more problems.

Trust me, I understand that no designer likes to inherit work only to feel a lack of creativity and control, but this comes up time and time again. Why? Here’s what I figured out.

There’s a Don’t Ask, Don’t Tell Policy
Not being privy to the background of a project can be rough. When Designer Four took over (me!) the overall look and feel was nearly finalized and all but encased in a carbonite block à la Han Solo. It’s not exactly what I would design, but for the rest of the team, it worked. That was what was important. However, the critical aspect I had missed was my lack of background information as to how the team arrived at some of the design decisions. And I didn’t ask. I simply looked at the state of the designs and made judgements based on design principles, not the needs of the product.

This can be damaging.

You’re “The New Guy”
Another problem I felt, whether it was real or simply perceived, was that my opinion mattered less when it came to decisions about user experience. When I would make comments or offer ideas, they seemed to be met with resistance. After time, I came to realize the reason: many of the ideas I was suggesting had already been proposed previously.

It wasn’t that the team wasn’t listening to me, I was just giving comments and input about areas they felt had already been decided long before I was tapped in. Your opinion seems to matter less since you weren’t there from the beginning. That can sting.

“It’s not you, it’s me,” one designer after another said as they changed projects or moved on in their careers, leaving Talu behind.


What Should You Do?
You need to take the time, as much as you can, to find out why certain decisions were made. A tight ship will keep a captain’s log (I mean, it worked for Captain Kirk, right?) and while my guess is that most application startups don’t keep detailed journals of their ongoing decisions and milestones, it might be helpful in the long run to start. A great way to transition a new designer, or any team member for that matter, would be to give them a detailed enlightenment of the project’s decision making timeline and a clear understanding as to what areas are immutable and what areas are open to change or flexibility.

Much of the responsibility needs to fall on the person joining the team. It’s important to understand how to propose changes to the design approach so they don’t feel out of place. Remember this: you might know what works in design, but you have to show it in a way that doesn’t feel disruptive to what has already been established. Any new developments in mind need to feel like an improved transition or an added feature that doesn’t diminish or harm the previous work. And for God’s sake, when deadlines are paramount to the entire team, don’t create even more work. But, I’m pretty sure that one’s a given.

We’re sharing our story, but we’d love to hear yours. Leave a comment below or drop us a line via email hello@talu.io