At Brightec we have a fantastic design team. Not only do they create astonishingly beautiful designs, but also well crafted UX flows. Time and again clients and users are left satisfied.
But what good is that if you can’t translate it into a working xml or nib file?
So, how do we (as developers) at Brightec interact with our designers?
One of the most important things for any team is communication. This is particularly true within in a development context.
We don’t just limit ourselves to routine transactional interactions; “Here is the design file”, “Thanks” etc.
There is always an open dialog around questions such as - What will work well? What won’t? How will this work on the device?
We are all part of the design process and we can all input into it's success. Both designers and developers need to be open to suggestions and willing to try something different, either for the sake of the user or for the sanity of the developer.
We have found that being in the room together (for at least some of the time) aids this communication. It stops tones of voice being lost and we get a better understanding of what each other mean.
We have adopted a more liberal approach to design files.
We don’t just take them at their word and blindly implement whatever is in the design file. This can lead to mistakes ending up in the user's hands which, in turn, can kick start a blame culture within the team.
Instead, as developers, we use some intuition to realise that it’s unlikely that we are supposed to have a marginStart of 16dp and a marginEnd of 17dp. If in doubt - ask.
At Brightec, to try to mitigate the need to discuss every 1px mistake, our designers create style guides. These hold a multitude of things, like common metrics and button styles.
These can help the design stay consistent throughout the app especially when we developers utilise styles in code.
Developers get involved in the design process very early in our team.
We have found that the resulting design is often more consistent with the platform. Also, it gives the developers the opportunity to stress how difficult something might be.
Although we don’t allow time constraints to stop a great design being implemented, it helps to know early so that we can plan our time better.
It’s also great to just get another pair of eyes on a problem to make sure we have come up with the best solution possible.
We have found it helpful to try to get to know each other's tools.
It can also be helpful to understand how to export assets as it means if one asset is missing we can jump on and get it ourselves rather than adding another task to our designers todo list.
This helps them to consider the challenges of implementation when they are designing.
Both of these pull together a sense of team and help us to understand each other's work load. This promotes a much closer knit team feel.
It helps to make time for a proper design review of the app.
Once you have built out the design, does it still look and feel how the designer expected? Have we missed a divider line on that screen? Should we have coloured that button blue?
These kinds of comments lead to better apps for our users. As a rule of thumb, we ensure we do this before every major release and it ensures we hit that top 1% which we strive to do.
There needs to be a sense of team to do design reviews well. It shouldn’t feel like someone is critiquing your work but rather we’re collectively assessing the state of our combined work.
The key to us working well together is simple - team and community. We are all continuously striving to improve and we are open to the help we can offer each other.
We communicate strongly with our designers and get involved in the design process early. We have found this leads to better design and implementation and therefore better experiences for our users.
Search over 200 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!