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.

My background has always involved the overlap of design and tech. At school, it was a passion for Design & Technology (or CDT as we called it). At uni it was Product Design. From then, it has been front end web development, bridging designs with client side interaction.

I work with a team of Front End Developers (or Client Side Designers, or Interaction Developers, or Behaviour Specialists, or whatever new buzz words sums us up.. but that’s a whole different conversation) as their manager.

My team in my eyes is brilliant. I can always, with confidence, take on a new challenge and know that the guys will either be able to do it already; take a little practice run before cracking it; or spend a few days researching and come back grinning knowing they’ve worked it out. And quality is always at an optimum.

Not too long ago, I would have been part of that process… getting my hands dirty in trying stuff, learning stuff, doing stuff.

That has changed since stepping up my management role.

I feel my team have surpassed me in the technical ability stakes. Yes, I have years of hand-honed CSS skills under my belt, and often see things in a different way to the new fly-by-the-seat-of-their-CSS-pants young guns to solve problems. But it’s the core skills that have are now seen as the norm in the role of front end that I no longer do on a daily basis where I feel I`m getting overtaken.

I try to stay aware of as much new web tech as I can, and always try to have a play to at least get to grips with the principles behind them, but it ultimately comes down to a simple matter of volume; there is only so much time available to work with new tech vs time needed to actively a manage team who are doing the work.

My team is far more experienced and skilled than me in the Coffeescripts, Backbones, Nodes, and whatever other new jiggery pokery is available as part of a toolkit of front end development. I go to them to get the professional answers on what technologies are capable of what features, on which device and how long they will take to develop. I ask my team to clarify what is possible, by when, and who is best suited to do it.

And I like it that way.

To me, my job is to ensure the front end output for the company I work for is the best it can be. I need to ensure the team we have producing the work are the best we can get. To allow that to happen, I should be hiring people with the best skills and knowledge, ninjas of front end, who will very likely be more skilled in coding than me.

As I see it, in my position, management is a niche skill. Proper management. Not just management by procedure, or checklists, but real personal “come on team, lets sort this” management. It’s much more about empowering a team of already highly skilled individuals to push to produce the highest quality they can and to constantly aspire to improve, hone, and learn new skills.

So, I’m not embarrassed the people I manage are better coders than me. On the contrary, I’m proud, because to me, that means I`m doing my job, and doing it blummin well.