Designers and Developers
A few months ago we started talking about design with our developers, read further to know what happened so far and why we think you should do the same.
Outcome over output
As a design and development team, our goal is to make sure that everything we do has a real, positive impact for people, meaning everyone from our clients to the end user.
In other words, we learned to judge our work by looking at the value we deliver, rather than just being happy about what we designed or deployed.
We realized over time that to do so together we needed to share a set of foundational values: good thinking over skills, sensibility over expertise, empathy over understanding, culture over knowledge and, eventually, outcome over output.
For a group of people working together, being truly on the same page is not the same as “Let me brief you on this.” This is why we decided to break out of our routine and make use of design as a topic to start a conversation amongst us.
Design and development
To a client or a user, those can be just words, just like our job titles.
This perspective helped us understand that in reality we are nothing but a bunch of people working together on a project.
What we found makes a real difference from the client’s perspective is the feeling of being actually supported in succeeding.
To make the most out of our collaboration, it became crucial to gain a shared understanding of the basic elements we all handle everyday, such as typography and layout, color and visual identity, photography and illustration, user experience and interaction.
How we organized ourselves
We started setting up a simple schedule: the whole team meets once a week, meetings are then grouped into modules of three, in which we focus on a specific topic.
We use Trello to keep track of our agenda and upload content and materials related to each meeting.
During the first meeting of each module one of us introduces the topic with a talk, everyone else is listening. After that, we all get a little assignment to work on, that will be presented and discussed during the third and last meeting of that module.
In between there’s the second meeting dedicated to what we ended up calling the “article review”: everyone chooses an article he read or a topic, and talks to the others about it in 10 minutes. The goal of the speech is not just to explain what one read or saw or heard, but to bring his view to the others.
At the end of each meeting, speaking one at a time, we briefly exchange some impressions to finish off.
We also found helpful to set up a few ground rules:
- Meetings are free to attend, but if you decide to join you’re whether in or out, no late arrivals or early leavings (within reason). Having people come and go freely it’s not how you keep a good discussion going.
- No smartphones or any other distraction. Pretty challenging to do these days, but very rewarding. The basic idea is not to waste each other’s time and focus on what’s going on.
- If it’s your turn to do something, get prepped, avoid rushing your presentation few minutes before we begin. Again, don’t waste the opportunity to be significant to your peers, you’ll want the same when it’s your turn to listen.
How is it going?
At first, it took a while for us to get into the vibe, we made a few adjustments along the way. It might not be always straightforward to have people talk to each other in an orderly and constructive fashion, especially after intense hours of work. That’s why we decided later on to schedule our meetings early in the morning, providing breakfast then became the nicest thing to add up.
Once we established a routine that could suit us, we are now experiencing the joy of an interesting moment of confrontation, where we can allow ourselves to be reflective about the things we see and make everyday.
The huge difference with just talking about design or code during working hours is that we do it actively.
Another interesting aspect is seeing each other getting better at making a point with actual arguments, at explaining things with proper language and clear visual references.
Last but not least, we are learning a lot, which was the main purpose: as topics are presented with a structure it’s way easier to memorize what you would have usually caught in a random conversation with another team member.
Where is this leading and why you should do it
Right now we have just finished a series of meetings where we explored together the world of typography, from its basic principles to advanced responsive design techniques.
To get into the topic we decided a real world experience could help us dive deeper, so we headed to a trusted letterpress workshop and spent a day printing type the old fashioned way. Getting away from the office and dealing with physical constraints has been great to gain a muscle memory of all that concerns typesetting to then confront how to deal with the same problems on a device screen.
As mentioned at the beginning, the whole goal is to build a common sensibility about design, and we’re seeing this is leading to several positive results:
- We share the same language when beginning to face new projects.
- Bridging the gap between different competencies along with a historical view about the processes of design makes for a more agnostic and creative approach towards solutions.
- Everyone is more motivated to speak their voice and help the others overcome obstacles and challenges.
- We are able to bring both designers and developers to collaborate closely with our clients, who see us tight and feel like they’re being actually supported.
But if one thing, what changes everything the most is the feeling that everybody is looking at the big picture.
We are planning to move on from typography to user experience, going step by step through everything in between, trying to incorporate other topics such as business and science to keep expanding the field.
We’ll keep you posted about further developments here on our journal, in the meantime thank you for reading.