Twentysix Twelve

A blog by Ollie Wells about web, design, work and stuff.

There’s no “i” in design.

| 0 comments

Ok, there blatantly is. But what I mean is design shouldn’t be a closed off, one-discipline role. Collaboration between creative, front end and back end developers is the only route to real quality.

I work with a very skilled team of creative designers. They are adept taking on a UX-washed list of requirements in the shape of a wireframe, and applying their voodoo skills of coming up with “stuff” to make something beautiful.

But then that artistic impression of a website gets handed to my team, who’s task it is to interpret every detail of what was going on inside  the designer’s head when she put pixel to Photoshop.

And for years, that’s worked. But in a modern online world, these pictures of sites need to come to life through clever interaction, beautiful user experience, and that little “je ne sais quoi” that is now expected when actually using a site or application online.

A designer has probably got most of these little details in mind, but cannot feasibly display each and every responsive feedback element within their design files. As a front end team, we sometimes get frustrated when its not clear what happens when you transition from one field to another, so we either guess, or get out of our seat and go and ask the designer.

And that is the key bit… asking the designer.

Talking to designers about their decision process is key in being able to create a tactile piece of web design or web app. The questions asked, the answers given with explanation, the non-obvious anticipated user-interactions will all help in the overall quality of the technical build.

The question is, when should designers and developers get together and talk? At project kick off stage? During the first round of design iterations? When the first clickable prototype is being built?

Yep, you guessed it… all of the above.

The ideal is an ongoing iterative collaborative process, where regular get-togethers are arranged to iron out any kinks, clarify foggy areas, and crack on with creating a thing of beauty, brawn and brains.

Regular cross-discipline working ensures quality is maintained throughout the project lifecycle. Instead of painting a picture of a completed website, designers should be given the space to apply their skills in art direction, tone of voice, visual language and overall creativity to help the final product be the best it can.

One way of doing this is taking a much more modular approach to design and build. I wont go into the details of how that would work yet, that’s another article altogether, but in a nutshell it allows a designer to focus on forging the creative of the whole site instead of using up valuable time in Photoshop moving a pixel here and a header there to generate a completed “page”.

Its good to talk.

By sitting together, working together and actually talking to eachother, the cross disciplined team are all reading from the same page. Assumptions are kept to a minimum, and knowledge is shared across the team. Questions are answered in minutes, and not lost in a bug tracking application or in an inbox somewhere along with other “very important” emails. Its a very AGILE way of working, which in my opinion is the way true quality is built in.

Ofcourse, the whole ethos of this post is about cross discipline teams and not just designers. But in my experience the design team tends to be much more separated from the people actually building the application or website. And it can all start with tiny changes.

Get the developers, designers, UXers, testers all in a room at the start of a project. Get a big flip chart, and lots of pens. Get coffee. Spend as long as it takes to talk about the idea, ask questions, answer questions, get stuff on paper. The time spent at this stage is invaluable.

Regular check-ins, or scrums, or get-togethers, or hub-chats, whatever you call them, are key. After kickoff, get the team back in a room after a week or so (relative to the project size). Go through the flip chart notes you made last time, and iterate on those. Too often, the first kick off goes ahead, then people are too busy working on the project for further meetings. This is where mindsets need to change; these meetings ARE work.

So, on your next project, get everyone together at the start, and book in another meeting. Each meeting, do the same. Its vital the meetings are productive, so no laptops (unless code sharing or prototype demoing etc), no time wasting, just clear constructive conversations with outcomes. Sit the team together, and get them talking. Its a sure-fire way to increase accountability and responsibility, and ultimately, to increase quality.

 

Leave a Reply

Required fields are marked *.