“Design Team of One” in a Team of Devs
I was in the final year of my BA degree in Communication Design when I started sending out CVs for a curricular internship (trainee position) abroad in Norway 🇳🇴. One particular company in Oslo caught my attention — a small girly and friendly digital studio focusing on UX and handcrafting Wordpress web pages and blogs. I had little to no knowledge at all in the UX, web design and development fields, but I was curious and determined that that’s what I wanted to do and so with hard work and persistence, I unexpectedly got my very first experience as the only designer in a team of developers.
I’d never had any experience with coding before, but I quickly became fascinated with how different designing and coding were and how amazing it actually was to build something I designed. After this, it became clear what I really wanted to focus on and so the journey began.
After completing my BA Degree I ran back to Oslo where I got an intern position at Opera Software (YES! 😁 The browser!!!) where I was fortunate enough to have the privilege of working with both a team of developers (where I was the only designer) and a team of designers.
The best about my time at Opera was how much, the way they worked, led to my professionally growth. I was given total trust and autonomy in my work, being given feedback at the end of each project just like any other working employee which kick-started the confidence I built in my abilities and skills.
“Design Team of One” at Evodeck Software
Throughout the years I’ve had quite the journey being the only designer in the companies I’ve worked with, but currently at Evodeck Software where I am once again the only designer in a crazy team of Devs, I have to say this has been by far one of the most if not the most rewarding and fun experience I’ve had. Not just because my colleagues let me *literally* kick their ass 🔫 in CSS styling, but also because I get the opportunity to be taught new technologies like React whenever we have some free minutes in the day. On the other hand, .Net does not seem like something I want to dig into 😨 AHAH.
Anyway, being a “Design Team of One” hasn’t come without its challenges and even though I’ve been the only designer before, I can’t really say the experiences have ever been negative overall (although that’s probably because I’m a “lone wolf” 🐺) but there were a few downsides as well. The way I look at it now, these downsides are what made me grow as a professional and as a human being. They kind of set a clear view for me of what I wanted professionally and where I needed to be, and I can’t say I’m not at that place 😝, but maybe you’ll get to hear more about that some other time!
In the meantime, below, I’ve compiled a list of some of things I have learnt and consider to be important if not fundamental when working as a “Design Team of One”.
Prioritization (Advanced Planning)
For me there are a lot of things which require prioritization like roadmaps, goals, tasks and schedules. But what’s really fundamental about prioritization is that if done right, it allows you to move forward and prevents you from getting stuck in a vicious circle of “improvements”. I say this because as a designer it’s very easy to get stuck in the space available to make improvements and this isn’t necessarily positive or productive. Having a roadmap is an intelligent and clear way of setting goals so you can better understand the project’s needs, thus becoming more consistent at delegating tasks and creating schedules.
At Evodeck we use an Agile Development workflow, and for the first few months I was here, we basically worked on an error and trial system. Now we’ve reached a point which I think we’re all quite happy with. The process starts with JIRA — a project management tool, shared between the whole team where we control what needs to be done, the requirements needed and the progress of it all. Besides JIRA, I use AdobeXD to design the screens, which are then uploaded to ZEPLIN, that also connects with the team and handsoff designs and styleguides with accurate specs. On occasion I will also use INVISION to make prototypes for both the team and the client. (If you’re still curious about this whole process, let us know! We’d be happy to share more about how we work!)
Communication (Ask Questions, Develop Answers)
Communication is key. In all the experiences I’ve had but more specifically so within the UI/UX fields, I’d say the time to discuss user-interface visuals, workflows and UX systems must be taken because you depend on the communication with your team to find product expectations and limitations and on more than one occasion you won’t be the only one who has questions or answers. For me, it’s all about analysing things, talking about them, looking at them from every possible angle, discussing and debating them (let’s just put it out there that you cannot discuss or debate things on your own 😅), then creating a plan to make a solution. Yes sure you can attempt to make a similar process without the discussion and debating part, but the end-result is most definitely not the same. In this case, I stand by the long known proverb that “two heads are better than one” and by this I mean, a whole team is better than a team of one.
In any case, find a system that works for you and your team but nonetheless, communication is key.
Collaboration (Trust Your Team)
When working with teams in general the way I see it, in order for a project to be well succeeded you must collaborate alongside your team, not beside your team, I really mean alongside. Because opinions will differ, and naturally in a team this is bound to happen. Some will be enlightening and others you’ll find they might just be more problems (here at Evodeck we like to call them challenges, not problems ✌), but ultimately if team members collaborate alongside eachother, this shouldn’t become a problem. On a more designer perspective, one of the most frustrating things about being a “Design Team of One” is that you can become very protective of your work. I for one, know that I am a huge advocate of consistency and sometimes it may take awhile until I can come to the realization that I’m just adapting things rather than changing them completely (in my perspective 🙈, I know not my finest of moments, but hey 😅 I’m only human). This is where I have to trust my team (the crazy team of Devs I mentioned above👆🏼) because I won’t have all the answers nor will I be capable of thinking about all possible states or errors of a single screen and that’s where the collaboration alongside your team becomes fundamental as their input, feedback and opinions are valuable.
Conclusion
I’ve found that because in all of my work experiences I had some kind of contact with code, it’s definitely come as an advantage to me in the position I am today.
On a more personal opinion, I find it much easier to design once you understand the limitations of the technologies used in the product. What I mean by this is that it’s not enough that only I understand the designs intent, because I am designing the product, but it is equally important that the developers also understand the designs intent as they are the ones who bring the design to life. In order to create better user-experiences both parties should understand the design ideology and behaviour and be open to the ideas of eachother and cross-collaboration. Just as good design calls out the attention of users, good code ultimately hooks the users to the product.
Therefore, as far as working as a “Design Team of One” in a team of Developers goes, at Evodeck Software I’ve found that it doesn’t feel as if we’re teams apart, but rather that we’re one whole team. So really, it doesn’t matter if you’re a team of one designer and five developers or ten designers and three developers, as long as you communicate and collaborate, I’d say you’re going in the right direction. I call it the 3 C’s — Conversation, Consideration and Collaboration 🤘🏼.
