A Designer’s Secret weapon, the Developer
Things I’ve learned from sitting right next to them
As a Digital Product Designer, I have seen that great design solutions, and thus great User Experiences, are created when the designer and the developer work as an integrated team from the start. I was lucky enough to always have been part of multi disciplinary teams where I learned, experimented and collaborated with developers, both front end and back end, while working in the same room and behaving as one team for every project.
In many organizations, developers are excluded until it’s time to develop design concepts or validate the feasibility of a design, which a lot of times requires redesigning and rethinking of the problem. This is a shame, because developers have a huge amount to add to discussions about the design solutions. And it’s sad when I hear that some designers believe that only they can come up with good ideas and produce solutions that “solve a users pain”. Which couldn’t be further from the truth.
I came to understand that including the developers in the very early stages of a project can have a huge impact of the success of the product. Developers can validate designs solutions and uncover technical constraints that might cause trouble down the road. A developer’s insight is essential knowledge for the success of any project. Without this perspective, creative teams risk investing in ideas that can’t be implemented as they thought they could.
A developer’s insight is essential knowledge for the success of any project
By integrating technology into the design process we can produce new ideas while ensuring concepts get delivered on. Here are some things I learned that I believe can break down the barriers between those two roles:
Work like a team
Include developers at the very beginning of every project. Build an environment of open communication where each team member seeks the feedback and ideas of others. A quick conversation with your developer friend right at the beginning of a project can help clarify the entire process. Go to a room and discuss the project over high level wireframes, quick sketches in the whiteboard or on paper. A quick feedback session could result in an even better design solution and also could keep you from wasting time on something that isn’t possible to build.
Web applications aren’t one-off projects. They grow, evolve, and change. When making decisions, designers must consider how the design is constructed. A design that looks great to the user but breaks every time a developer needs to make a change isn’t functional. It may be a pretty UI with a serious underlying problem. That’s why I firmly believe that a digital product designer should have some knowledge of what is happening in the front end level. I always compare it with my core background studies as an Industrial Designer. It’s in everyone’s best interest if you know a little about engineering and material processes when designing a physical product.
A design can be greatly improved with the input of a developer, and code can be better written with the help of a designer. Working together as a team, consciously knowing that this is not just a step in the process and understanding where both roles can contribute to the project will help tremendously in achieving goals and overcoming obstacles.
Get to know the client-side limitations and abilities
Designers don’t necessarily need to know everything about development, but they should know enough to feel comfortable when having chats with the devs. The reality is that design usually happens first. So knowing what tools and techniques are going to be used to carry out your design will have a much bigger effect than that of the opposite. Most things you learn in the process and through constant and open communication but there are other examples that you can learn by your own. For instance, if you need to make a specific element work on Explorer 9 or earlier (really!?), you have to be aware of the Browser limitations before you create those gorgeous diffuse shadows for you card elements on sketch and those rounded corners on the buttons.
Another thing to consider is the frameworks that the front end team is using. Do they use a certain library throughout the product? Can you make any adjustments or do you have to base your designs on that? That said, when you feel that a certain solution will have a clear benefit to the user, do it and don’t let a developer talk you out of it. Ask how you can help get this done. Use whatever sources you can to explain your position, but don’t let the user suffer because it’s slightly more challenging for the developers. Investigate whether there’s a way to create a similar effect. CodePen is a great source of inspiration with ready made code. Many times what you want to accomplish can be done in a similar way that’s easier or less messy to code.
Also, you have to consider what happens on other devices such as a mobile or tablet? Is your web-app going to be used on any mobile device? If yes then you have to think about how to manage the scenario when the user hovers over an element in the browser and what happens on a touchscreen device where there is no mouse over.
Strive for better communication
Learning how to code will obviously make the communication easier and will teach you to think like a developer. I personally invested some time and became familiar with front end frameworks such as BEM and less/sass CSS languages and I saw that it does give you a better understanding in every way. Coding gives you the ability articulate your ideas in a way that a technically driven mind will hear with much more attention. But this isn’t always the case and it shouldn’t be. As I have expressed my opinion before no one has to learn to code if they don’t feel like it.
Work close to each other, literally. I can’t stress enough how important this is. By working closely with developers, my understanding of development has increased in every level. When you work so close you have the chance to be educated when the code is being written and learn a ton of new things. You can even have a lot of impromptu chats about issues and impediments that you both have and even find a pain point from a product and organization perspective and start a new project that will benefit the product (aka a redesign project). And I don’t need to tell you how much PM’s listen to engineers ;)
I’ve learned that you don’t have to be a developer to think like one. If you can specialize in your own craft and the things you want to focus on, like animation and how to export animated assets for instance, but you have the communication skills, the patience and the will to work with your dev friends, you can take your designs to the next level and become a great digital product designer.
Closing thoughts
Remember, the better the relationship between a designer and a developer, the more likely it is that you’ll create amazing products. Involving the technology in the design process is not rocket science. You just have to invite the developers to any design sessions that take place and involve them right from the beginning of the project. The earlier you do it, the more you will benefit.
Excluding the developer from the design process will do nothing but prevent the product from living up to its potential. In fact, excluding anyone will ultimately compromise it. And that’s because every person who helps make it better is helping in the optimization of the User Experience of that product.
In the end, this is all about breaking down the barriers between roles and encouraging more collaborative work, not just between designer and developer but between all roles in the organization. The more we understand what our fellow colleagues do, the better the result will be.
