Getting Things Right

… or; How to keep an eye on the interface and usability without becoming a crazy, controlling, burnt out designer.

What I see in certain projects and in the professional lives of people around me, is that a lot of times some work has to be done twice, because either a developer didn’t implement the user flow correctly, lacked caring for great mark-up or just plain and simple didn’t get it. No one is to blame, because everyone has their own league; if a developer doesn’t have a feel for what’s simple and/or usable, or doesn’t really connect with the interface, there’s going to be some wrongs to be set right.

What gives?

We need to fix the connection between the designer and the developer. It has to be absolutely clear to the developer what to implement. It has to be absolutely clear to the designer that he can trust the developer with the implementation.

A few ways of doing this, comes with hours of work and preparation. For example; a storyboard or a comprehensive design document. Both take hours, if not days, to create and still there will still be some miscommunication in certain areas.

The abstract solution

There’s a need for a workflow in which the designer and the developer meet; a place where there are standard ways of taking on certain pages of information. In this place, designers and developers will come together and work out the astonishingly important details of a project, an application, an interface.

Both developers and designers have a certain number of best-practices and standardised ways of building projects. Combining these into a central documentation will give them a standardised way of taking on certain tasks. It will create the aforementioned place where they ‘meet’. They don’t have to have redundant meetings about the same basics in a project. Which gets me at the point where I reference back to “On mark-up and frameworks …” and the ‘protocol’ mentioned there.

Standardised but not constrained

The problem you get with something like a protocol is that it’s too fixed, the word protocol feels too rigid, and most developers and designers are somewhat stubborn babies. Yet if you have an extensive and up-to-date reference which shows how to take on certain tasks, that is the place where the designers meet the developers, the place where you can easily find a way to jump the current hurdle. And if there’s even the slightest doubt in one’s mind; ask for it effectively. Explain the problem as simple as possible, reference (if available) a possible solution – in the reference document or on the internet. Continue with other tasks while waiting.

With that a designer can outline the ‘big picture’ of a project, discuss the details – with the developers – in-depth and reduce re-iteration time to a minimum.

To be continued …

The first draft of this ‘protocol’ is currently in the works. Meaningful iterations of the document will be put life under a license that is yet to be determined.