UX / UI / Frontend: The benefits and challenges of designing and coding
Being a designer at Whitesmith is a position relatively uncommon, considering the industry standards. I’m being purposefully ambiguous when I simply say “designer”, because that’s part of the reason. All of us are proficient in UX and UI design. Not only that, but we also do frontend development. In lack of a short name to identify our role, we came up with one: Devigner.
Devigner? But why?
To be fair, all designers at Whitesmith have always been able to design and code. Initially it wasn’t something necessarily planned, but eventually we realised the advantages of that when organising internal teams. Usually with every new project, we do an initial discovery phase, to better understand the problem(s) we need to solve. The team we gather to work on it is in most cases composed of a project manager, a developer and a devigner. With a small team like this, the communication and work pace are more agile and efficient, while having the concentrated knowledge in all product development areas. When the discovery phase concludes and a development cycle starts, based on the conclusions taken from said discovery, usually it’s that same team who will work on that, bypassing any need for context acquisition.
Juggling between design and code
One of the biggest challenges of being a devigner is structuring the workflow to execute all the different design stages and frontend development in tandem with the backend development. For that, the help from the whole team, and in particular, the project manager, is essential. Together we define the roadmap of the features to be implemented, sorted by priority. Instead of designing everything at once before any development happens, the process is structured on a feature by feature basis. Although, some UI design work must be done initially, to create a foundation (as in, a styleguide) in which those features will be designed. With that out of the way, each feature is approached more or less like a mini sprint: it starts with low fidelity wireframes, followed by UI mockups and concludes with the frontend implementation. By far the big advantage of this approach is the efficiency of the frontend development. Having the knowledge across the areas enable us to do the UX and UI work already having in mind the most practical solutions for the frontend, without compromising on the quality of the product. Another beneficial aspect of tackling all that is the fact of being able to address feedback changes more autonomously, making that process quicker.
So, what’s the catch?
While this multifaceted position has its advantages, it comes with an inherent risk of turning us into “jack of all trades, master of none”. It’s indeed unrealistic to think that someone can achieve true expertise in all these distinct areas. That’s why all us devigners have the opportunity to pursue our own expertise, like frontend logic or UI development, to name a few. We are pretty much like any sports team: we all play the same game, but each one has its own strengths.
How we Devigners work together
So far I only gave the perspective of a single devigner in a project, but we actually collaborate with each other quite often. There are cases where some projects with a bigger scope demand more workforce. Then, the different tasks can be split across multiple devigners, in a way where we can take advantage of our areas of expertise. Even when that is not the case, there is always some degree of collaboration. For every project there is a fellow devigner assigned to review others’ code. Beside that, every 2 weeks we all gather together to share what we are currently doing and ask for feedback, or do a brainstorm session on some specific issue, if needed.
And that’s it! While the devigner position is very nuanced and in constant evolution, in simple terms, this is pretty much how we work . Do you have any thoughts on our approach to UX/UI design and frontend development? Let us know @whitesmithco