We’re not designers. Except we are.

By Harry Harrold
Published

At Neontribe, we often say we aren’t web designers. In a way we’re right, because we don’t lead projects with visual design. But that doesn’t credit the importance of design in what we do. We view design as a problem-solving exercise, and function rather than form is our problem domain. Our problems are not “Make this static collection of text and images into a beautiful page!”, but “Make this interaction delightful.” Our work doesn’t end up static. Even the simplest web site is an interaction. What we aim to do is focus on the process that the web property is implementing, whether that is a booking path, or a form designed to help structure someone’s thoughts. Or, even, presenting a set of text and images as a web site.

When our projects go best, they start with an understanding of people and objectives. This is part of our discovery phase: a short period at the beginning of the project where we get to grips with the people who will use something we’re building, and the objectives of the organisation we’re working with. We deliver this knowledge as user stories, short sentences which enable us to check what we deliver is the right things, in the right order. Our design is about turning these stories into a piece of code that functions beautifully.

That might mean working on the categorisation and collation of text and images to present a message or communicate some information. For that, we’d start with post- it notes representing that information in sections. We’d move those sections round, test how the information was organised with the kinds of people who’d actually consume it. We’d rearrange until we were happy with how the content worked for them, and achieved its objective for the people who we were working for. Maybe we’d need to commission some more text or images, maybe we wouldn’t. Mostly we’d re- organise it. Starting our work with content in this way means that we don’t end up with a visual design dictates what text and images are required.

Or, more often, it means implementing a more complex interaction, again starting by understanding people and objectives. We believe in articulating this understanding as a series of user stories which speak to people and their feelings about the interaction. We prototype a response to these stories, so we can get testing our design early, and we prioritise the stories we’ll implement depending on the importance of the objectives they achieve. Our design here is to solve the equation of what is required and what is possible within budget in the most elegant way, balancing people and objectives.

We’ve found the greater the focus on visual appearance at this stage, the more the requirements of content and interaction are obscured. It’s these design problems we concentrate on solving, and that’s how we’re designers.