Communicating between team members is a critical part of continuous improvement. This can, however, be quite difficult, since giving feedback on individual elements might only lead to temporary changes or small ones. Indeed, there’s a difference between notifying someone about a mistake and identifying a pattern that reappears often during projects, and more importantly, finding a realistic solution to improve it.
Thankfully, our agency is aware of those challenges and therefore offers the opportunity for feedback rounds and workshops to discuss those topics. Discussing as a group creates a different dynamic since we can hear everyone’s side, make it less personal, and include everyone in improving this practice as a mission. Out of those meetings we were able to improve quite a few components of our process.
The first one was how to implement responsive styles. Originally, there was little organization on this level, so developers checked every element individually for font sizes and then wrote individual CSS rules for each of them. This was a nightmare to implement and update, and also very error-prone (since it’s easy to make a mistake on some values when you need to update a lot of them). After explaining this problem to the design team, with the first concept of a solution, we reworked the initial proposal so that it would suit both sides.
We now have a style guide page, where all the styles for the typos in the website are shown, for different screen sizes. We can then enter those in the project (with the same naming convention as used in Figma), and when we look at elements in the design, we know which style to use, since the name of the font style in Figma is the same as the one in the code. This makes it easier to enter the styles initially and update them later on. This is also an improvement for design since this naturally forces designers to be more consistent in their projects.
This new system is also applied to other elements of the website, for example, the spacing. This facilitates the communication between designers and developers, since sometimes, it is obvious to the design team that elements like spacing should be consistent, and if one is updated, it should be updated everywhere. When the development team receives the design, however, it can be quite hard to realize which parts just happen to have the same values, and which ones are identical because they follow the same design rule. By specifying design rules explicitly and having names for those that can be seen when selecting the design component, we can avoid this guessing game.
Designers can also share which improvements they would like to see from the developer team over projects: animations, parallax, visual effects... should have time invested in them because they could be reused in other projects. One of those mechanics we worked on is having a parallax effect on the website. Another one was animating a 3D scene on scrolling or creating a slide effect while scrolling.
Aligning goals and reevaluating the results of our current efforts is essential to define our priorities. For example, we wanted to create a library internally so that we would be able to reuse components created in previous projects. After starting this project, however, it was obvious that it was not suited to our agency’s workflow for numerous reasons. One is that we take our learnings from previous projects into the new ones, which means the library would need to be constantly updated with them (which is challenging knowing that we’re only 2 developers in the agency). Another one is that our design team likes to have a high degree of customization available, which is perfectly reasonable, knowing that it’s also our client’s expectations, but it makes it more challenging to create very flexible components.
Another point that was discussed was how to improve communication during projects. We then defined which tool worked best for what (messages in Figma for comments on the design that are not urgent, tickets in ClickUp for tasks that need to be done, and notifications in Discord when we want to make sure that someone is aware of an update).
More recently, we have also held a workshop to improve the team’s skills on accessibility. Due to the client demand, the developer team has decided to improve its knowledge on the topic. However, having only one part of the team trying to improve accessibility does not make sense, as most issues can be solved during the planning phase of the project.
By holding workshops, we can maximize our learning efficiency, since we need fewer people in the team for the research and then we can prioritize which knowledge we gained is relevant to our projects. This also helps develop solutions for some common issues: for example, some projects we worked on had more accessible designs than others. By collecting the ones that worked well and those that did not, we can not only facilitate learning accessibility but also create a library of styles that can be reused throughout projects or serve as inspiration and therefore, create accessible designs while not augmenting the time needed to design them.
We will also have a workshop on testing websites. Indeed, the entire team must be knowledgeable on how to test projects, since generally, the more people look at a website, the more likely they are to spot bugs. Our team already does manual testing, but there are tools (like Lighthouse) that could improve the testing quality if we make sure we use them more consistently.