Considerations on Full-Stack Product Designers
Across my years working in Digital Design and Product Design fields, one thing I’ve consistently noticed, is how certain topics, not matter the context in which we all live in (more on this tidbit later), we always go back to the same discussions. And that pretty much covers any type of activity (economic activity that is) you can think of. Case in point: my parents have been self employed and have had their own farming business since the 80s. One of the most puzzling struggles for them has been the cost of what they sell. Or I should state, balancing the investment that goes into the crops, maintaining them, making sure they grow solidly, and then finding the resources (manual and automated) to pick them, box them and get them to their clients/buyers. Oh, and balancing all those factors with selling the crops at a price that justifies all that investment, which also allows them to pay everyone they employ including themselves, but also keep the business growing. They’ve always stated that they think what they charge for the output of their crops just doesn’t evolve as rapidly as the cost of everything else (materials, labor). And before someone states “hey, that’s farming for you” or even “no one forces them to do it” or the eternal “maybe they’re doing it wrongly, we know better”, also remember the context in which they operate (remember my article on Context).
My point to this example is that their challenges have not really changed in all the years they’ve been in business. And this leads me to one of the points of this article: what constitutes the role of the Full Stack Product Designer. When I started my career, the role of the Interactive Designer (which now would be classified as a Product Designer, or some may say UX Designer, something I inherently disagree with), included everything from Research, Information Architecture, Content Writing, Visual Design, and of course, Front End Development. The expectation was essentially for the professional to be able to be a “Swiss Army knife” of the Design world. Typically, and I remember interviewing for these roles in 2009/2010, the hiring manager would typically ask me: would you consider yourself a generalist, or do you specialize in particular field. My answer, based on my academic training and professional roles, would be the former. But now that I’ve hired, managed and created Design Teams, here’s some considerations on this topic that I believe to be important.
Aren’t we all just Designers?
Yes, indeed we are. Let me rephrase that. We’re all problem solvers. That’s essentially what Design as a discipline is and aims to do. Wikipedia states: ”A design is expected to have a purpose within a certain context, usually has to satisfy certain goals and constraints, and to take into account aesthetic, functional, economic, environmental or socio-political considerations.” Meaning, Design is not a gratuitous and self-indulgent profession and field, which aims to generate something that is not usable or for that matter useful (and purposeful). When it comes to the Design field and profession, it has evolved as well as it should. Nothing ever stays the same, no matter how hard some people try to hold on to (and if they do, chances are, the world will change all around them, and they’ll be the ones left behind and permanently playing catch up). When I first started in this profession, there were Interactive Designers, most of whom had evolved from a background in Graphic Design (this was in the mid 2000s). Personally, my training was specifically on Interaction Design and Software Design, which included a variety of disciplines targeted for this type of solutions, amongst them Information Architecture, Content Writing, Motion (including Film Making concepts), Interactivity, Digital Publishing, Visual Design, Sound, and also, Front-End Development and Database Connectivity (the latter ones, something of my own volition since I really wanted to compliment my knowledge base, but that included PHP, Javascript, SQL, Actionscript and even Advanced Lingo). The reason I’m stating this, is tied with the fact that an Interactive Designer was expected to be a fully fledged expert across all those fields. There were at the time the “Web Designer” titles which coincided with the Interactive Designer role, but the Web Designer responsibilities actually encompassed professionals who could tackle all the previously listed disciplines, and also function as quasi masterminds (and invariably Helpdesk), to everything that pertained to Digital Products (their scope of responsibilities also included supporting email/newsletter campaigns, setting up email inboxes, maintaining databases, dealing with FTP issues, DHS, Development languages, and the laundry list continues). Suffice to say, it became very clear that there was a gap in available talent for many organizations. I started to notice at the time a tilt towards role specialization, with Interaction Design becoming much more of a particular field, the same going for Information Architecture, and all the ones I listed before.
Towards the end of the 2000s, with the democratization and upward utilization of Design Thinking methodologies, married with the progressively more visible stance of Research, this added a layer of roles and responsibilities within the Product Design arena. The concept of the User Experience Designer emerged, essentially taking over the role of the Information Architect and Interactive Designer, though I still remember interviewing Designers who essentially considered UX to be the creation of Wireframes (reinstating the obvious: it’s not). Now keep in mind, I’m not stating the concept of Experience Design didn’t exist before. I’m stating that the role and this particular label, “User Experience Design”, started to become more prevailing, and it essentially took over everything that typically fell under the responsibility of Interactive Designers and Information Architects (not so much for Visual Designers, since those evolved into UI Designers). This evolution in a way forced a specialization, where organizations suddenly realized they needed to craft solutions that consisted of all encompassing experiences for their clients, and therefore Research, alongside everything else Digital Designers had done in the past was essential for the success of those same solutions.
Full Stack Product Designers.
Many professionals in the Technology/Design world are fully aware of the term “Full Stack”, as it typically associates itself with Engineering domains. Wikipedia defines Full-Stack Engineers/Developers as: “A full-stack developer is expected to be able to work in all the layers of the application (front-end and back-end). A full-stack developer can be defined as a developer or an engineer who works with both the front and back end development of a website, web application or desktop application. This means they can lead platform builds that involve databases, user-facing websites, and working with clients during the planning phase of projects.” Essentially these are professionals who work on the front-end part of the product experience (the interactive aspect, governed by user-driven behaviors, also driven by the user interface), as well as the back-end (the database connectivity, the algorithms, essentially rendering all the information and performing all the tasks that makes the solution actually serve its purpose).
I personally started using this term for Product Designers, originally when I first worked with Startups (going back to 2014). I realized Product Designers were taking upon themselves the strategy and execution of a variety of aspects that could be tackled by an array of specialists under the Product Design mantle. In the example I aforementioned, I was the first Design hire for a Startup, and as such, I had to establish a series of processes, relationships and infrastructure for the maintenance of previously existing solutions and also edification of new output that other Designers were going to come into. In addition, I also had to clarify how other departments and teams were going to relate and interact with when it came to the Design group and its professionals, and the best way to prioritize tasks, understand roadmaps, and making sure clients’ needs were being documented (and met). This meant addressing all the disciplines that I previously listed, with the addition of everything pertaining to Research (something that I had personally developed skills for and learnt in the meantime in my prior experiences in Design Centric Organizations with proper Research professionals and departments). It also meant clearly understanding how we could all collaborate according to Human Centered Design processes, and how less than a handful of Full-Stack Product Designers, could efficiently collaborate with everyone on the Product Design journey, clearly understanding what their roles and expectations for those were. In my particular case and to be perfectly clear, I never expected Full-Stack Product Designers to be developers of any kind. Which is to say, I wouldn’t invalidate someone who is capable of doing so, but in my experience in Startups (and even in prior and much larger organizations), I came to realize that we had Engineers/Developers who were able to tackle those responsibilities and that was in fact part of their scope of responsibilities, whereas the professionals on my team were able to focus on Research (across its many aspects, including Usability Testing, Market Canvasing, Competitive Analysis, Data Analytics, Customer Support Feedback Clustering, User Reviews and Ratings, Qualitative and Quantitative type of studies, to name but a few), Information Architecture, Content Writing, Interaction Design, Visual Design, Rapid Prototyping (which could also include advanced Prototyping), Motion (including micro-animations), QA, and even in many cases, being instrumental for the Branding aspect of the solution itself. All this to say: the Full-Stack Product Designer ends up gobbling the title of a generalist, much like Interaction Designers did in the past, but the responsibilities go much further. Of course some of these professionals are going to have stronger capabilities in some aspects of the Product Design mantle, more so than in others, but that’s where training plays a role in making sure those gaps are addressed, as is the case for teams where talents can and should complement others. But again, and just to reinforce this, expecting these professionals to venture out in Development, be it front-end of even back-end, eventually begs the question: are these professionals able to do what they should be focused on, or are they simply being asked to perform all the tricks of the trade, at the expense of never being really great at any (or for that matter, of derailing productivity and efficiency of the overall process itself). These types of professionals will be able to adjust to many types of organizations, and carry with them a wealth of knowledge that makes them perfect to complement specialists that can also work on Organizations of different dimensions and Design Maturity levels. But it has been a tactic I’ve noticed that Designers respond to with gusto, since it allows them to actively engage with various players in the process, and ultimately provide them (and everyone for that matter), with a deeper sense of ownership of the process and the outcome itself.
One of the questions that invariably bubbles to the surface is cannibalizing other roles, particularly the whole Generalist versus Specialist discussion. As I mentioned in the last point, the opportunity always exists for Generalists to collaborate and for their work to be further complemented with that of a Specialist (and vice-versa). They’re not mutually exclusive. However for organizations whose scale and design maturity is still limited or emergent, considering these types of professionals provides ample solutions for their needs, while setting up the terrain for complementary specialized professionals who will round out the teams, as funding solidifies and as needs evolve. It’s all about being strategic about what you want to do, with what you have, in the context with which you have to operate in.
I’ll finish this article with a quote from Anaïs Nin on growth:
“We do not grow absolutely, chronologically. We grow sometimes in one dimension, and not in another; unevenly. We grow partially. We are relative. We are mature in one realm, childish in another. The past, present, and future mingle and pull us backward, forward, or fix us in the present. We are made up of layers, cells, constellations.”
