How to deal with a Non-Design-Driven Work Environment

Design-Driven doesn't mean that the CEO should be a former designer or that the PMs must have a hands-on design background. Instead, it’s important that every team member contributes to shaping the product in some way or another, as the end user's experience is everyone’s responsibility. 

Design-driven concepts refer to companies that not only understand and take advantage of the impact of design at a business level, but also the organizations that incorporate design-like mindsets and processes across the board.

However, don't be deceived by appearances,  as this isn't an exclusive problem of non-tech-first companies or older established organizations. This is an underestimated condition that also affects many brand-new startups and development studios across all industries.

Diagnosing a non-design-driven context

If you recognize at least 3 of the following at your current job, chances are you're working in a "non-design-driven environment", and the more you recognize the severe the condition could be:

• You (or your design team) operate under the Engineering umbrella.
• PM means "Project Management" instead of "Product Management".
• You (or your design team) aren't involved enough in  ideation and definition discussions.
• There's no such a thing as a Researcher in your team or company.
• You're not able to do much user-research work to inform your design decisions.
• Experiment, hypothesis, A/B testing, etc, aren't normal words at your project meetings.
• You normally design based on requirements already collected and processed by others.
• You are iterating based on internal stakeholders' feedback and requests.
• User testing isn't a normal practice to validate or pivot your design assumptions.
• Design-QA over Staging and/or Production isn't a normal part of your team processes.
• Quantitative data is not a common topic of analysis and discussion within your team.
• There's no Design System in place or that type of work has never been prioritized.

You can probably relate to some of these circumstances at least a few times in your journey as a designer. And maybe you just concluded that your current working environment isn't design-minded enough for you. 

However, wait, do not resign just yet. These challenging environments can be great places to work if you're willing to do what it takes to make a tangible impact at a cultural level, while also making a name for yourself as a transformation generator within.

Quick tips before jumping into the actual work 

• Stop blaming your company for not being a design-driven one, and take some actions.
• Don't ask for permission upfront, start as small and low-risk as possible.
• Find some close strategic allies for each initiative to help you support your intrapreneurial storytelling.
• Take ownership of your own proposals while removing as much friction as possible for the rest of the team to collaborate.
• Make sure you communicate your progress and learnings all along the way no matter how small they could look. 
• Resistance to change is in human nature, so don't give up if on the first try you don't get the expected outcomes, reactions, or feedback.
• Be proactive, flexible, resilient, and keep learning while pushing things forward.

6 easy recommendations for each area of pain

Since I began mentoring designers on ADPList, this issue is one of the most common issues some folks are facing out there. Normally it turns into a good excuse to leave a company, so I wanted to put some simple day-to-day recommendations together in this article with the hope of helping someone out.

Please keep in mind that there's no silver bullet to eradicate this problem quickly and forever, so take this endeavor as a long-term and never-ending journey. Also, be aware that at the very beginning it will require lots of persistence, resilience, and small doses of some of the following medicine recommendations:

Pain 1: Not being included or listened to in product definition discussions

Regardless of how well-developed the tech industry is, it's common to exclude design from the initial conversations. In this context, most new product ideas regularly come from top-down and are directly added into the roadmaps without much evidence. This leads to endless iterative and reactive-design work.

So, instead of just running in recurrent discussions while just gathering requirements, we have the power to become design-process facilitators for the rest of the team and unleash creativity while opening decision-making for everyone else.

Fortunately, we have the tools and the cultural background that already spread thanks to the rise of some great concepts like Design Thinking, Design Sprint, Product Discovery, Continuous Discovery, Dual Track Agile, etc. But, be careful when starting with this as it's easy to fall in love with books and follow them literally. Just avoid the fanatic trap.

So, rather than just talking a lot about ideas, start by taking action. Find the smallest workshop artifact that you can run within an hour meeting to start off with, and demonstrate its value. Then consistently continue running more and more of these co-creation activities to put everyone on the same page, make decisions, and brainstorm new ideas.

I recommend reading "The Workshopper Playbook" by Jonathan Courtney to get started with the backbone of a workshop structure and the facilitation aspects. Also, get familiarized with your online-whiteboard tool of preference: Miro, Mural, FIGJAM, Freehand, are some I recommend.

Pain 2: Not being able to inform your design decisions with user-research insights

The design work needs input data mostly from the users' perspective, but it isn't easy to get the buy-in or have the structure to perform user-research type work. It’s even more difficult in early-stage startups and development studios. On the other hand, some team-mates from Product, Marketing, etc, will from time to time ask for the end-products of research work, such as User Personas, User Journeys, Empathy Maps, etc.

If you don't have any of these, I recommend starting from the end by generating them collectively. Back to point 1, you can facilitate collaborative sessions with the team to generate Stakeholders Maps, Proto-Personas, User Journeys, etc. I know it isn't ideal, because in a perfect world we could craft all of these assets using actual data. But remember the goal is to gain some buy-in for more profound research work.

Empower yourself because you don't need permission to do your job, and keep in mind that, it's our duty as designers to dig deeper and learn more from the user's needs and context. Get started as simple and cheap as creating some remote-sync initiatives to deliver to users via email or any easy channel.

This could be as simple as an "Exploratory Survey" to understand potential users' needs and context, which could be easily crafted using Typeform or SurveyMonkey. You could also do a "Card Sorting" exercise to answer information architecture questions using Optimal Workshop, or User Zoom.

If you're a bit more advanced in research but your company doesn't have the structure and process, you can use some help from services like User Interviews, or Lookback. If you haven't already, I recommend reading "Just Enough Research", by Erika Hall. Great book.

Pain 3: Not being able to validate/pivot your design assumptions through user-testing

Unfortunately, in most companies, it's hard to implement a user-testing process because delivering a feature seems the only important goal. We're constantly constrained by short deadlines which leads us to validate everything internally.

It can be hard to see the dimension of the difference between an advanced user of tech products (everyone in the team) that normally don't have the same problems, and an actual user of the product. For that simple but strong reason, user-testing is hard to get started but needed in our design process, especially before writing a line of code. 

So, if you're not getting the time and budget to do old-fashion user-testing via interviewing users, I recommend using a more async and unmoderated approach, such as prototyping your design in Figma, Sketch, or XD, as usual. Then run a "Usability Testing" initiative using Maze, Useberry, User Testing, or any similar tool. By doing this, you can collect usage statistics data and possibly ask questions while they complete the tasks.

Pain 4: Not having a Design System culture already in place

Design Systems are often misunderstood as another designer-specific thing, moreover many engineers don't see this as a tech debt, so it is normally minimized as a Style Guideline doc or a UI kit. Advocating for Design Systems isn't an easy task, in fact, this is one of the most difficult things to get internal buy-in for.

Within the normal rush of the roadmap, it's never a good time to kickstart this cross-functional project, because a design system is actually a parallel product with no end date, and at some point will require its own roadmap and governance processes.

Before jumping in, take a couple of deep breaths, and visualize this mission as the creation and promotion of a community vegetable garden. Yes, it sounds weird, but hear me out, because with Design Systems, as with the communal garden, you'll need to recruit some close neighborhood allies, and everyone involved should share a long-term vision while committing to the hard work.

It’s dangerous to go alone, so find your partners within the right areas of the org such as Branding, Marketing, and Engineering. Take this seriously as an internal project by defining an MVP and a tentative roadmap. Then hijack a project to apply the first version of the design system. Finally, you'll be in a good place to start promoting the solution for other teams or areas of the product.

I always recommend starting talking about the Design System work at every meeting that makes sense and sharing progress and links in every related company channel. Yes, you should become a salesperson by promoting this product consistently, and a good way to do that is by having strong documentation from the beginning, like the ones you can build using a tool like Zeroheigth in a symbiotic relationship, and something like Storybook from code side of things.

Pain 5: Being unable to ensure UX/UI quality within the implementation of actual end product

As designers, it's easy to get lost in the weeds of our own design files, prototypes, and docs, while forgetting about the user experience we're so dedicated to, which is actually happening in another dimension. The dimension that engineers usually call "Production" refers to the actual thing our users are using in their own devices and contexts. 

Without a specific process or structure to take care of this dimension, we’re exploring the actual product and reporting that misalignment everyone knows is there, and that report got lost in Slack. It's our duty as designers to put together a process that allows us to regularly check the public version of the product and find opportunities for improvement. 

I normally recommend three different combinable solutions for this issue:

1. Ask your development team for ideas on how to add a "Design Review" step within the development process before the feature or the change is shipped. This is normally materialized as a new column in their agile board to make sure every task that involves UI is approved by a designer before moving forward.
2. Schedule some time for yourself each week/sprint to review a different flow in the development environment while adding improvement recommendations in their backlog. 
3. Perform a general UX audit (twice a year minimum) to make sure you're always aware of how the actual product looks and feels, but more importantly, how it works while holistically finding improvement opportunities.

Pain 6: Not being able to get insights from product quantitative data analysis

No matter how obvious it seems, it's not that simple to access comprehensive quantitative information on the product performance to help answer some key questions, while also sparking improvements and new projects. This company debt is sometimes under prioritized as it takes a lot of work not only from engineering to implement tracking, but most importantly it will also require a good Data Analysis structure, processes, and at least one dedicated person.

We as designers should incorporate the data analysis task as a healthy habit within our own processes. It could be as simple as reserving some time maybe monthly in your calendar to jump into Google Analytics, MixPanel, HotJar, or whatever tool available to you. If there's no similar tool already collecting some kind of data, please ask and push hard to connect something similar to the actual product.

When starting with data, it's really easy to get overwhelmed, surprised, and confused all at the same time. Make sure you always formulate relevant questions related to the key product concerns, and the company’s objectives such as User Acquisition, Engagement, Retention, Conversion, etc., before jumping into the data platform. Then, find your way across the data visualization and filters to get the answers you're looking for, and always communicate your findings with your team.

Once the value of this practice has been demonstrated and spread across areas, you can start pushing for some more in-depth tracking instrumentation like measuring step by step a specific flow you're designing for. The easiest way is to start is by adding notes within your design files next to each screen/component, specifying all the individual user events you want to track across the flow.

Then, you can start elaborating more complex learning initiatives, like experiments, by forming a concrete growth hypothesis, and describing all the tracking implementation needed to measure the actual impact of a change or new feature.

Conclusion

There's a lot we can do from our current position, and as designers, it’s up to us. We could be that annoying person who is usually in the back claiming for better work to be done, always advocating for the best practices and processes while never taking action.

Maybe we could jump around from company to company looking for that ideal place to work. Remember: when your client is outsourcing web design, they are doing so for a reason so be prepared to take the lead and be the change-generators that grow with the context we're striving to improve.