Working with product developers

Controversial theories, but this is something that just might work!

I have been working as a product designer for a little longer than 10 years. I understand the importance of design and why it is an essential step for the product designers to be included early on in the process of software PLM. Designers are the advocates of the users and hence, the early inclusion of designers on the journey will allow the stakeholders to build amazing products.

The next line you are going to read could hurt a lot of designers, who have been working really hard. The most prevalent belief in the Tech industry about designers is: “highly paid, arrogant folk, who don’t do much!”. Most of the muggles won’t say it out loud in the shared workspaces, but this is what they have been thinking (don’t deny it. You know who you are. and guess what.. You are right from your POV). The opinion got formed over the years and the reason is simple. Designers go through a lot of research, validate their concepts, find the best fit, create visual strategies and wireframes, weave them into meaningful prototypes, conduct user testing and then present the final output. This output is just the tip of the iceberg. Despite being the extract of months of effort, this final output is fairly easy to criticize. Design is very subjective and each one who comments on the output has their own set of preferences. Now if the design produced does not conform to the set ideas in the individual’s mind, that person (let’s call her Karen) does not like the way design looks. This creates a bias in Karen’s mind within the first few seconds of the review and from that point onwards Karen will always look at the solution with a hater’s lens. Many developers and other managers are yet to understand the importance of the design process in software PLC. Even though they might encourage the enthusiastic approach the designers come up with, secretly, they have been wondering, “why did this person take so much time to come up with this?” Or “that’s it? All this time and they come up with something that cannot be made, in the last two weeks?”

I went on hunting why this opinion got formed in the first place. Lack of awareness of the design process among developers? Sure. Poor souls do not know how many concepts get rejected within the design team before the final 2/3 are presented in the final meetings. Not seeing results with the pre-defined timelines? Absolutely! Expecting something revolutionary yet technically feasible? Maybe! Remaining firm on a feature because it is best for the users but not so easy to develop? a hundred percent! And then I figured out that the problem is… Deadlines!

When it comes to SaaS products, the story is slightly different. As a product designer, you are responsible for the whole product(if you are dealing with a small product, or a full feature of a huge product) with tight deadlines. The deadlines are essentially to beat the competition and hence, there is always a critical balance between early mover advantage with limited functions vs great products to beat the competition. This is not taught in the design colleges, but believe it folks, that is the reality. The intricate balance between making things perfect and making them fast has to be balanced.  We see a lot of products today getting released with a not so great UI and then getting a facelift and enhanced usability 3/4 months down the line. Jitter, a simplified animation tool comes to mind as an example. 

So after a lot of consideration, (throughout my career, to be frank), I have come to a conclusion that there are two approaches to designing SaaS products.

When it comes to SaaS products, the story is slightly different. As a product designer, you are responsible for the whole product(if you are dealing with a small product, or a full feature of a huge product) with tight deadlines. The deadlines are essentially to beat the competition and hence, there is always a critical balance between early mover advantage with limited functions vs great products to beat the competition. This is not taught in the design colleges, but believe it folks, that is the reality. The intricate balance between making things perfect and making them fast has to be balanced.  We see a lot of products today getting released with a not so great UI and then getting a facelift and enhanced usability 3/4 months down the line. Jitter, a simplified animation tool comes to mind as an example. 

So after a lot of consideration, (throughout my career, to be frank), I have come to a conclusion that there are two approaches to designing SaaS products.

The correct option is to create solid deadlines, conduct a ton of research, involve stakeholders in the discussions, generate a ton of concepts, reject three quarters of them, start solidifying a few winners and eventually land on a couple of winners to present during the stakeholder meeting. This is the ideal way, but I have never seen it work. The sales team and the leadership (with a full blown panic attack, increasing in intensity with each feature released by the competition) keep tightening the deadlines. Till the design team releases the concepts, the dev team keeps analyzing the requirements from the tech architecture point of view. There is pressure everywhere. The deadline is approaching (it happens like a week into the project) and the developers have no idea what they are supposed to be building. Hence the dev team tries to find the fastest way to construct the feature within given constraints and budget and keeps it documented as EPICs in Jira. If it is a big feature, they shortlist and finalize an open source product to get, customize, and integrate with the core product at a moment's notice. The dev team has already started falling in love with the concept, while they are waiting for the designers to come up with something better! As we all know, time is never enough for designers, since we always can do a bit more! this on the other hand pushes the dev team to the edge of the cliff.

and then the day of the stakeholder meeting arrives. The design leader presents the concepts to the stakeholders and stakeholders are impressed! Meanwhile, the tech lead sitting in the audience starts getting uneasy. The moment the design leader asks, “Any questions?”, the tech leads pounce. What they are looking at is not what they are already in love with! 

And so begins the era of long fights between the designer and the developers. The compromises, the bias and everything around it. Since the developer team is the one that makes the ideas tangible, they win this fight! happens even if your CEO is a designer at heart! And this is where the misunderstandings mentioned in paragraph 2 began in the first place. The engineering team can say, and which is a hundred percent true, that designers wasted 25% of the time in creating something that cannot be built!

So the question is, is it worth working on a design with all your heart and soul, backed by a tonne of research just to see it being shelved? or is there a practical way to make it a win-win situation for all?

This is where the controversial theory starts. This is where speed matters. This is the method where the conversations happen. This is the way, both compromise, but as a team, both win! This method has worked for me in shipping a full scale product, multiple of its features, redesigns, as well as multiple websites. Might sound like I have given up the control, but hear me out. This is especially true for the problems that have been solved.

STEP 1: Shorten the deadline for tech

Not that way. The moment tech leads walk away from the requirement meeting, their brains start working towards remembering a similar pattern. They might know it yet, but tech leaders are the ones who try a lot of tools and programs for fun and they keep forming subconscious connections through patterns. Also, once they like a tool that agrees with their style of working, that becomes their favorite. So when the requirement shows a similar pattern, they immediately go to their mental repository and start analyzing how they can fit the requirement in their favorite tool! So once the deadlines are decided, which are mostly ASAP, ask this question:

“If you were to ship this feature in 1 month instead of 3, what would you use?”

and just patiently listen while the tech wizards take you through a series of sites listing a bunch of different tools with their relative advantages and disadvantages. There are three benefits of doing this in my experience. First, you overhear a bunch of names and you also understand the source the dev team is leaning towards. Second, you form a deeper connection with the tech lead just by listening to them talk about what drives them. ( Tech leads are tech leads because they are passionate. Otherwise, they choose the path of Engineering Managers) and the third advantage is that as a designer you get a springboard to your concept generation, where you already know what tools exist in the world, their rankings by popularity and their relative disadvantages

STEP 2: Run parallel research.

While the dev team solidifies their research on what can be used as a platform to build a feature, the design team conducts their own research regarding parallels. You can also include the tools mentioned by the tech leads and test them for usability by replicating them in prototyping tools like figma (Plugin: HTML to design). Do all the design research and to all the necessary concepts sketching around the shortlisted tools. It is important to keep an open line of communication with the dev team to keep the design team updated about the shortlisting process. The concepts however should be rendered in the theme of the existing product or based on the branding, whichever is available at that stage in development. 

at the end of this phase, if the dev team decides to build it inhouse, then the deadline gets extended (obviously) and then the design team too can get more time to deep dive into research, conceptualisation and testing

STEP 3: Present

During the stakeholder meeting, which was supposed to feature the finished well tested UI of the feature, present the concepts. Mention the name of the products upon which the concepts are based. this has the following advantages:

• You are still in the good books with the dev team since you have shown that you value their opinion right from the beginning. They are more perceptive towards what you have to say.

• This saves testing efforts, since the open source tools are widely used and the experience problems are mostly weeded out through contributions from literally every subscriber. 

• Designers can use the tools as the springboards and can juggle multiple, viable and profound concepts

• The concept presentation meeting can be moved up, by a LOT, making stakeholders happier with the progress (and willing to invest more if needed)

STEP 4: check the wiggle room

Now begins the span of healthy discussions. The designers can argue that the idea IA cannot be fully mapped to the selected concept. but remember, you still have the tech leads as your partners. All the designers need to hear is “let me check what we can do!” 

During this course, both teams decide upon the boundaries. What needs tobe changed, what could be changed and what cannot be touched is finalized. and then both teams walk out of the meeting with a win. The dev team knows that they don't have to make something from scratch, while the designer knows that their designs are going to get built much similar to the way they imagined. The reason is simple, designers too start falling in love with the concepts!

and remember, this meeting happens way early in the PLC and everyone is happy.

and then the design team can unleash their creativity in the small area. If the org has a design system, the efforts are even reduced further. The dev team creates the basic structure and then they plug in the custom designs created by the design team. Overall, the product / feature starts shaping up.. and fast.

In conclusion, the entire development process gets a piggyback ride on top of a source code that has been tested by thousands of users and has been contributed to by more designers than your design team. The concepts have been tested and perfected and have stood a trail of time. This makes the overall dev process smoother, faster, and more efficient. This also leaves enough time for stress testing and UATs, making the released version more stable and robust. 

This process has some disadvantages too. Firstly, the final output might not be the best in terms of usability or sometimes, even looks. Secondly, there your competitors could be using the same platform, but that’s where the creativity shines, isn’t it? What can you do with all the constraints really tests the creative streaks of the designers, while the constant validation of the concepts forges a deeper bond. As Steve Jobs said, it is all about how it works. Once a stable version goes out, the design and dev team can come together, have a success party and then plan on the next steps. This is where, when the entire team has breathing space, the designers can put forth what it could have been. I have seen this method work with very talented (and obsessed) tech leads, while both of us were shipping features on the platform under tremendous pressure. I cannot guarantee success…

However, it is always better to control what can be built, instead of pouring your heart and soul into a concept that does not see the light of the day!