Looking for a definition of Full Stack Design that makes sense
(And why Full Stack Designers are not necessarily designers who code)
TLDR: This is the story of how exploring what ‘Full Stack Design’ could mean led me to define and visualize the unique Design Stack of the design team at Icalia Labs, with very interesting results. And how, from this perspective, I ended up thinking that ‘designers who code’ are more suited to be defined as ‘multi-stack designers’.
Why write about Full Stack Design, in the first place?
I’ve always been what some people consider a ‘hybrid’ or ‘unicorn’ designer, meaning that I know how to design AND how to code (by the way, there are several issues with the term ‘unicorn’, but other designers already wrote about that). In 2017, when I joined Icalia Labs as leader of the Design Team, Icalia’s CEO Eduardo Lopez De Leon discussed with me how every member of the design team at the time was able to code and design, and referred to this as a ‘Full Stack’ practice of design.
I had previously heard the term, dismissing it as one more buzzword, but at that time I got more interested in the concept. My initial reaction was that something was wrong with the term, or at least the way it was understood: I was not sure that multi-disciplinary skills should be considered a ‘Stack’ on their own. Particularly because I love Design and its richness, and I was sure that something like ‘Full Stack Design’ would not necessarily imply coding skills. After all, Design has its own identity, and a multitude of methodologies, tools and approaches, right?
Full Stack what?
If you haven’t heard before the concept ‘Full Stack’, consider that:
A) This comes from the world of engineering, and
B) the simplest way to understand it is this: it refers to an engineer that is proficient developing for the back end, as well as the front end of an application.
Of course, nothing is ever so simple, and you can find a lot of definitions of a Full Stack Developer out there (some of them even moving away from an exclusive engineering skillset, like this SpaceX job posting). Usually this helps to differentiate an otherwise specialized role (for instance, a Front End Engineer) with roles that are able to touch different parts of the application (databases, back end, front end, etc.) with a good degree of confidence.
Hopefully, reading this oversimplified definition of Full Stack Development helps you understand why I was concerned with the idea of a Full Stack Designer being someone who ‘design and codes’. Isn’t coding part of a developer’s stack? Even one step back, how does a Design Stack possibly look like?
How does the concept of Full Stack applies to a (UX) Designer?
Before you continue reading, I hope you already got that I’m talking about product / UX designers; if not, I’m making that disclaimer right now. So when I write ‘Full Stack Designer’ I’m most definitely meaning ‘Full Stack User Experience Designer’.
With that being clarified, it’s easier for me to point you towards the work of Jesse James Garrett (co-founder of Adaptative Path): ‘The Elements of User Experience’, published in 2002, as a way to provide a big picture of how practitioners make decisions regarding the experience of a user. This basic framework is widely used to describe the skills and practice of Product and User Experience Designers; from research and strategy, to execution and complex interaction design.
I became familiar with it early on my career as a Designer, and followed it as a reference when developing my skillset. For that reason, I used it as a ‘baseline’ for my first approach trying to define a Design Full Stack for my team at Icalia.
Defining the Stack from within a local context
I didn’t know at the time the quintessencial definition of Full Stack Design (nor do I know it now!). So I focused on a smaller scope: the Stack that we needed as a team to perform successfully at Icalia Labs at the time. These were our challenges as a design team:
- Participating in strategic workshops with Icalia’s customers to help define scope of work for design and software development contracts
- Executing Design Sprints (following the GV recipe) to generate validated UI/UX for short development projects
- Collaborating directly with the developers in our team to bring our designs to fully functional ‘MVPs’ for our customers
Looking at these challenges, you can imagine that if you wanted to be part of the team, it was not going to be enough to have very good graphic and UI skills; you would need good strategic skills, as well as basic understanding of dealing with stakeholders and facilitating innovation. That was a very primitive draft of our own definition of Full Stack Designers!
* Note how, for our specific team, design specialists made no sense. The search of a ‘full stack’ derived from a real need of balanced designers capable of tackling various aspects of the design process.
With the Elements of User Experience as a baseline, I defined several key skills and tools relevant to how we executed projects as a team:
Measuring and visualizing the Stack
For each individual skill, I defined 4 levels of proficiency: None, Low, Medium and High. Proficiency in this context means level of competency:
- None: The designer has no relevant knowledge or domain on the subject
- Low: The designer is able to execute the skill, but might have had suboptimal results in the past, and requires coaching and / or supervision
- Medium: The designer is able to execute the skill with satisfactory results, with low levels of supervision, but is not equipped to deal with edge cases
- High: The designer feels extremely confident executing the skill, and is capable of maneuvering in case of edge cases
(In retrospective, I feel I should have added the ‘Master’ level, where a designer is able to teach the skill and coach other designers, as well as objectively evaluate performance on that skill — but for now, let’s stick to those 4.)
Once we have a good skill set in place (i.e. our ‘Design Full Stack’) I surveyed every design team member, asking them to make an objective self-evaluation using the proficiency scale provided. This was matched with my own evaluation as Team Lead, and opened really interesting discussions with the members of my team during one-on-ones exclusively dedicated to this topic.
For the sake of picturing better what we just measured, I created a simple ‘punch card’ with the scores, resulting in a sort of ‘visual DNA’ of the unique skillsets of each team member:
Benefits of creating our own definition of Full Stack Designers
The Stack enables better fitting between designers & projects. Being able to visualize every team member’s proficiency with the skills in our stack allows the design manager to assign people to projects more efficiently, based on the projects unique demands. It also helps every team member understand how they add to each other’s unique skillset!
The Stack allows individuals & managers to define better Career Paths and Personal Development Roadmaps. Of course, once you measure something, you can start controlling it! This applies perfectly to the individual path every designer is trying to follow: should they continue specializing on the skills they’re strong at? or improve the areas where they have low proficiency? Looking at the visualized stack, these decisions become better informed and easier to track.
Evaluating and providing feedback to designers becomes less subjective. Providing and receiving feedback is always a core function of a healthy team. But sometimes it can get a little bit subjective, and could be detrimental to the morale of some designers. Having a common baseline of what skills are important to develop as a team, feedback becomes more objective and meaningful; and the benchmark becomes more transparent because every team member is evaluated the same way.
The team celebrates their unique skillset DNA. Measuring and visualizing the skillset is less about focusing on what skills ‘you don’t excel at’, and more about the unique skill set you provide to the team. Understanding that no one can master every single aspect of the trade, the visualized stack increases the value of the unique way in which every designer excels at specific aspects of his or her work.
Some words of caution while you read this
Keep in mind that this is a story about a very specific use of the concept of ‘Full Stack Design’. Don’t take this as a universal definition of what Full Stack Design is or should be; I invite you to instead think of the concept of the Stack in terms of your team’s unique challenges and characteristics.
Also, the Design Stack is only a piece of the puzzle: it does not cover how soft skills and other aspects influence the unique work of every designer.
Considering that we live in a moment in which many other disciplines are trying to be more design-oriented, it is our responsibility to make some introspection and define, discuss, and celebrate our identity as designers — as well as the skill sets that make every designer unique.
Wait! what about designers who code?
Hopefully you now believe, as I do, that a designer can develop his or her own ‘Full Stack’ inside of the boundaries of our discipline. But what about those brave designers that go further and learn how to code?
Enter the multi-stack. Out of better words to describe it, I consider that a ‘multi-stack’ practice better describes what words like ‘hybrid’ or ‘unicorn’ attempt to do.
On the first part of this post I tried to provide a simple definition of ‘Full Stack Development’. I should have said this as well: the concept of Full Stack doesn’t mean you’ve mastered everything. It means that someone is able to work on both sides and understand what is going on when building an application.
So, for me, taking the journey to the stack of other disciplines opens the gate for a more efficient and empathetic collaboration, and a state of flow and understanding that benefits cross-disciplinary teams tackling complex challenges.
As an exercise, I discussed with my team at that time how could our Design Full Stack benefit from everyone’s knowledge about front end coding (part of the Dev stack), and we tried to ‘pull’ those skills to our existing framework. Remember the Full Stack Graph I showed you earlier? This is how it looks when you ‘overlay’ the skills obtained from front end coding:
Being aware of our own stack as designers helped us to better understand how the skills obtained from the development stack amplified our chances to execute better as a team, and reach the goals of the team and the organization!
Final comments
If you take something away from this, I hope it is the idea that it is always valid to take a break from everything out there, and all the definitions of ‘what designers should be doing and learning in 2019’ — and just think of what is relevant to your craft and your goals as part of a team (or your ‘solo’ project).
Taking that as ‘square one’, you can define your own stack, and start rich conversations about your level of proficiency in those areas; as well as how this benefits or limits your current execution as a designer.
Feel free to drop a line if anything on this post made sense to you, and you would like to start a conversation!
Thank you notes
Thanks to Eduardo Lopez De Leon and Abraham Kuri for fostering my interest in this really interesting topic, and thanks to all the designers at the Icalia design team that helped to shape this amazing initiative. I know these efforts are in good hands now that I left the company 💪
Also, big thanks to Will Funk for providing feedback on the initial drafts of this post 🙌
