What’s the difference between Potato and places that you’ve worked previously?
Before I joined Potato (nearly three years ago) I’d spent most of my career working at agencies that were design driven, or at least had design teams that were typically as well established, if not more, than the development side of things. What was designed got implemented - for better or worse - and where things could have been done better, sometimes we only found out when the developers complained. At which point it was usually too late to change.
Potato is (and always will be) an engineering company at heart. Coming into a background where developers are not only in the majority, but also have strong opinions on how things should work was a big change, and was one of the main reasons I wanted to join Potato.
The developers here saw bringing design in-house as an opportunity to influence and be part of the design of the things they were being asked to build. I saw it as an opportunity to improve the way I design by working closely with (and learn from) the people who have to make my designs into actual things.
So you joined a dev company with no existing design team or design experience. How’d that work out?
My first day I wasn’t sure what to expect. I definitely knew it wasn’t going to be the same as what I’d been used to but I was also excited to have the opportunity to work with a team who come at the same problems that I’d been working on from a different perspective.
It was also a chance to build a team from scratch, and to create a way of working that is much more in line with modern design and development practices. But obviously that takes time. You have to be sensitive to how others work, especially in a company like Potato that has been so focused on creating a great place for developers to produce the best code. Even though there was a lot of enthusiasm from around the company on the value of UX and design, there was still a fair bit of feeling around the best way to make it work.
It wasn’t a case of you arriving and all of a sudden there was Design then?
No, but then it was never going to be. It’s not something that you can just drop in on day one and expect everyone (Potatoes and clients) to be comfortable to just run with.
There’s been a lot of education around process, timelines and outputs. We try to strike a balance between structured process and pragmatism - finding the best way to work for a client or project. Given the way many of our clients want to work, it’s important that Design at Potato is flexible, rather than a task-driven checklist of ‘design deliverables’.
What are some of the big challenges you’ve faced?
Potato prides itself on being able to deliver incredible quality and at a pace that others find difficult. We’ve worked really hard to get away from the perception that including Design means adding huge amounts of time and budget to a project, and leaves devs sitting twiddling their thumbs while the designers do their thing.
In the past, our PMs had been used to getting developers into the mix and ‘hands dirty’ from day one of a project. Introducing Design to projects means that there’s a natural delay before production-ready code is written, but getting designers and developers talking to each other as early and as often as possible has been the key to many of our most successful projects. And our devs often use that delay to do technical spikes or rapid prototyping in collaboration with the design team, which is always time well-spent.
And what do you think are the biggest benefits and opportunities of being a design team surrounded by developers?
Breaking out of the design echo chamber and being challenged, definitely. Although the developers here respect the expertise and experience of the design team, there are some fairly strong opinions that get shared the other way. Having these discussions early and getting to a shared understanding on a project isn’t always easy, but it always pays dividends. Having those developers on hand and as part of the team, makes it so much easier too.
Have you changed anything about the way that you work since joining Potato?
At every agency I’ve ever worked at documentation and handover between designers and developers has been a pain point. Building the team from scratch has allowed us to avoid legacy systems, software or templates and make choices (alongside the devs) about the best tools for the job.
Apps like Sketch and Zeplin make the handover between design and frontend developers so much faster and more efficient than in the bad old days of style guides, and we even have our designers using traditionally developer-focused tools like GitHub and Tower to integrate the project from end to end across the whole team.
For the last few months, we’ve been trialling using Tower (a graphical interface for git) as a good way for us to store source files, assets and documentation securely and make them available to all members of a project team. Developers and project managers receive updates as the designs are being created and importantly, using branches and commit messages helps with version control, effectively creating a log of your work stream.
Let’s face it, most designers aren’t the biggest fans of tools like Codebase and GitHub. They’re not built with them in mind and they don’t work the way the tools they’re used to do. But, when you’ve got a big part of the company working with them day to day, there’s a strong argument for using the same tools as a way to close the gaps between design and dev.
Do the old clichés still come out?
Of course. But we’re also learning where we’re more similar than different too. You might find it harder than you think to pick out the designers from the developers these days, and that’s the way we like it.