The design can make or break any project. Be it from usability and general attractiveness, feasibility, or ease of development standpoint. If the designer drops the ball early in the process, the entire development process can be derailed, and with that budgets increase, the quality of the final product decreases, and the relationship can quickly…
The design can make or break any project. Be it from usability and general attractiveness, feasibility, or ease of development standpoint. If the designer drops the ball early in the process, the entire development process can be derailed, and with that budgets increase, the quality of the final product decreases, and the relationship can quickly be strained.
That’s why it’s crucial that the designer working on any given project has a technical understanding of what’s possible, what’s feasible, and what are the better alternatives, noted Opus’s lead designer Sven Kristjansen. In addition to that, he highlighted the importance of open and worry-free communication between the developers and the design team – developers need to be able to request changes from the designer and the designer needs the option to consult with developers on what approach to take.
“It’s not rare for a designer to draw something up, thinking it works well, but in reality, it’ll take the developers hours to implement, because the design team has opted for a non-standard option,” explained Kristjansen. “However, more often than not it’s done so not because the designer thinks it is the only right option, but because they did not know that it’ll be difficult to implement in practice. Had they known, they would have happily offered an alternative that’s easier for the development team and in the end leads to the same result.”
This is the reason why having robust practices in place to mitigate such issues is important for any development project. Whilst experienced designers may know most of the potential pitfalls, their main focus is on design and usability, not the technical aspects of the development process. If developers lack the option to request appropriate changes or flag potential issues, the amount of time being spent on things that could have easily been avoided can quickly rack up.
However, even though developers might have the channels to voice their concerns, in an ideal world these issues wouldn’t creep up in the first place. That’s where the design teams’ experience, technical know-how, and rational thinking come into play. Kristjansen notes that whilst all projects need to be unique, the underlying logic is mostly the same – an e-commerce project is an e-commerce project and something built on Magento is something that’s built on Magento.
“Having worked in some area for a while, a designer gets a feel for how things are done. Whilst every digital storefront is different, there are some common characteristics that are shared amongst most of them. These are the solutions that the customers expect and what the development team can use readily available resources for, without needing to spend hours to reinvent the wheel,” he said.
“Same goes for platforms. For example, Opus builds most of its e-commerce projects on top of Magento 2 and React, giving me the option to get well acquainted with what’s achievable and what’s not. This means that I can avoid alignments, animations, or whatever else might be difficult to achieve with the tools at our disposal, instead opting for solutions that have the same effect in the end, but utilize solutions that are easier to implement,” the designer added.
Every designer wants to be creative, and every client wants their new product, site, or tool to feel unique and tailored to their needs. This is something that each custom development project offers, but Kristjansen notes that being overly creative without keeping in mind the end goal can often be disastrous for the budget, development timeline, and the end result.
“There’s a fine line between creativity and just being over the top. Does the client or end-user really care so much about what the shopping cart icon’s wheels look like, that a designer needs to draw a new one from scratch, forcing the developer to opt-out from using pre-made icon sets, and with that increase the time spent on something that doesn’t have any real effect on the final product?” he said.
Often these kinds of “mistakes” happen due to the designer’s ego, or just because they do not understand the amount of work it takes to implement their out-of-the-box ideas. Of course, if the client specifically asks for these solutions, it’s the way to go, but according to Kristjansen, stakeholders can often be baffled when they are billed for hours of work on some unimportant aspect of the final product that they really don’t care about and where a standard solution was more than enough.
As such it should be every designer’s goal to achieve the desired results whilst keeping in mind what’s important and what’s not. This also applies to fonts, colors, animations, and other aspects of the design process. Oftentimes, instead of opting for a custom solution, the same result can be achieved with a nearly identical option – e.g. a slightly different loading animation – which is faster to implement and gives off the same vibe the designer was originally going for.
“The trend today is also to opt for the less-is-more approach, meaning that the number of different elements, fonts, and animations is cut to a more reasonable level. When possible, standard fonts are also used, meaning they do not need to be loaded in from elsewhere, making the product much snappier as well,” Kristjansen added. “Same goes for various elements – when possible, we should use standard and uniform components where applicable, cutting down on clutter, confusion, and the number of different things a developer needs to code up.”
Kristjansen noted that it often seems that many companies have fenced off the creative team from the technical team, meaning that the design and development are totally separate from one another. However, based on Opus’ experience, this can lead to a situation where the developers take the designers’ work as gospel and do not have the courage to make minor changes or ask for alternatives.
“Sure, with some projects there are no alternatives. When the client is set that a button needs to be exactly where it was initially drawn, moving it a pixel here or there is not an option. However, mostly there is a degree of flexibility, and the developers need to have the freedom to make minor adjustments on their own or if needed, ask for other options,” he said.
He explained that at Opus, for example, developers will often unify font sizes or carry out smaller changes on their own, based on their own knowledge and expertise. Also, should a developer discover that placing a button an inch to the right or to the left would save them hours of work, the designer is always consulted and in most cases, a compromise is quickly found that keeps the design intact, but allows the developer to utilize options the previous version did not offer.
“Experience, open communication, and technical know-how are the aspects that help to deliver successful projects. Here at Opus they are key, and the results speak for themselves,” he added.
Want to join our team? Take a look at our open positions. We’re looking forward to hearing from you!
Can we help you as well? Get in touch with us! We’d love to talk.