Designers Make Things Look Nice, and Developers Make It Work

Something hit me this week, that resonated with both my designer and developer colleagues. It's that thing people refer to when they say that there was not enough "communicaton", but really cannot point out what exactly went wrong. I noticed it while discussing this issue, and I realized what caused it. That felt as if I just had hit the jackpot.


This miscommunication will especially happen when you divide the two professions into:

  • designers make it look nice;
  • developers make it work.

Because that feels as if there is a clear split, and each can take their own approach to tackle the overall goal. When that happens, things go bad.

But it may not feel that way. You can be in fact professionally excellent at being bad for others. For instance, a designer can make something look really attractive, use awesome interactions, and in that way complicate the implementation. The other way around developers may build such complex ingenious systems to store and calculate data to be displayed, that it will restrict in what can be shown, or it adds no value for the end-user. Effectively, one profession is hampering the other by excelling at their own techniques.

Proposed Interaction Method

I propose the below steps as method of interaction between designers and developers, with the goal to satisfy the client or stakeholder.

  1. Client or stakeholder provides:
    • Goals,
    • Requirements, and
    • Draft Wireframes
  2. Turn into Wireframes with designer and developer
    • Per screen:
      • Purpose - goals?
      • Visual elements - show what and how?
      • Behaviors - what should it do?
      • Navigation - how to move between screens?
        • Incoming routes - how to get there?
        • Call to actions - where to go?
  3. Build Application Logic by developer
    1. Draft Screens - layout of Visual Elements and testing of Behavior
    2. View Models - Visual Elements
    3. Controllers - Navigation & coordinate Behaviors
    4. Services providing Behavioral Models - Behaviors
    5. Services providing Storage Models - Persist Data
  4. Implement Design & Appearance by designer
    • Finalize Screens - Visual Elements & visual aesthetics

The above shows a flow with dependencies as results are created for each step. In the below sections I detail how these may affect each other.

Goals, Requirements, and Draft Wireframes

These need to be provided by the client or stakeholder. In general this would be an interactive process where both the designer and developer would discuss this together with the client or stakeholder.

The goals are essentially measurable achievements that need to be met so the client or stakeholder can sign off the project as completed.

When discussing the goals, inevitably there will be specific requirements that the client or stakeholder has. Don't confuse them with goals, since requirements could be easily reconsidered if there are issues implementing them. It is much harder to argue on goals, because you may change the reason why the client or stakeholder came to you in the first place.

Requirements usually translate into what the end-user should see or be able to do; therefore, affectting the visual elements and behaviors of the wireframes.

For this reason, it may help to already draft wireframes together with the client or stakeholder when discussing these goals and requirements. You get early feedback on things that may be hard to change if they would be reconsidered later on. Plus, the client or stakeholder can see clearly the effect of changes in specification, and realize their own responsibility to be firm in making choices.

Wireframes with Purposes, Visual Elements, Behaviors, and Navigation

When designing wireframes, you can embed the goals and requirements of the client or stakeholder per screen.

Goals translate into purpose statements for creating particular screens. They are also a reminder for both the designer and developer to keep focus. What matters for the client or stakeholder, and what can be omitted because it adds no value?

  • It helps the designer to realize when things become too fancy that the purpose is no longer clear.
  • It helps the developer to realize when things become too complex that the purpose is no longer clear.

The components of the wireframe helps to separate concerns.

  • The visual elements help the designer in deciding what is important to get right.
  • The navigation and behaviors help the developer in deciding what needs to be functionally sound.

The wireframe is where the designer and developer cross each other, and is a stage where neither has anything to lose. Perfectly suitable for discussions, and aligning each expertise. So this is the moment where "communication" happens.

When designing wireframes it often occurs that something needs to be reconsidered, because it does not make sense. At this point it is easy to make a new proposal and discuss this with the client or stakeholder. This would happen before anything has been built, and minimizes waste of time.

It was exactly this point where I had a situation that we needed to change something in our design. Because we had listed out the goals, I could see that the functionality we were building did not match the purpose. Together with my designer colleague we decided on a change in the visual design to adjust for this, and that solved the issue. It saved me tons of time, by avoiding to build an implementation that eventually would have been useless.


The above is not meant to be a comprehensive listing of the method. I'm sure it can be improved.

The key takeaway here is that when designers and developers use wireframes, they help to align each profession and provide elements to discuss on. This can prevent miscommunication and make it easier to achieve together the goals of the client or stakeholder.

In a next blog post I will detail how the wireframes can be turned into application logic and how the method of this post may help to tackle revelations of implementation challenges.