⏱ Estimated reading time: 13 minutes

Table of Contents

Creating a Design culture in a Product/Tech org

By Simon Letellier, Head of Design @ Legalstart

Striking where it counts

Methods that would naively respond to the title of this talk are plenty. Suggesting changes rarely hits: “I don’t have time for this”, “it falls outside my scope”. It is hard taking a step back when your job requires diving head straight in for hours on end. When you want ideas to land, you need to strike strategically: what can cause growth, sales, or KPIs to go up and to the right? Also, who should you talk to?

First comes Marketing. Designers are the most relevant there with regards to how information is presented, architected, how customers are acquired, converted, kept happy, grow revenue. Designers are knowledgeable about cognitive biases and how to make landing pages just right. Quick wins that demonstrate the various impacts of graphical design can convince of its importance.

Second comes Data. Indeed, rather that receiving information from data analysts and reflecting them visually, why can’t designers trace the information back to the source, learn to read it even if just basically and to contextualize it? This requires learning about new tools such as Mixpanel.

Being proactive is key: invite yourself to meetings, show your work, intercept and challenge roadmaps and help people work together! To that effect, you can add context to the work because you know the users and can communicate the right tone and insights to the right teams.

Questions and Answers

Where should intuition fit in Data, when the inputs are of insifficient quality?

Data scientists will tell you that the quality of the output is limited by the quality of the input. Contributing to the quality and quantity of input data is the first thing that you should do.

Have you ever faced a conflict with a colleague who does not listen or act?

Any response should depend on the colleague you are facing. Sometimes you will have to lower your expectations, sometimes you must experiment, come up with responses or try again later.

What is the place of UX research in the context of UI design?

Before their Design revolution, the Design team was short-staffed and wasn’t conducting user research or interviews. They could only use what was present at the time. Now, research and data are at the epicenter of product design. Research definitely takes time, though.

The Design team must always prove their insights verify the collected data. Over time, this improves the personas and makes them valuable to other teams such as matketing.

Is the design team’s situation ever indefinitely acquired?

No… well that depends on the design team. Junior people cannot always tackle business subjects and constant pressure must be applied against Product people such as PMs and the CPO.

How cross-organizational roles efficiently cooperate with dev teams

By Émilie Duciel, Product Research & User Insights @ Dataiku

Whatever your role in the organization is, there are three tenets to improving cooperation: understanding each other well, a strong and continuous communication and opening up. These tenets must be complemented with adequate tooling, whatever it is: Slack, Notion, Miro, Confluence, Mixpanel, Dovetail, Airtable, Figma and so on.

Understanding each other

Each tenet applies as much to dev teams as to between any two teams in your organization. This one has got to be the most critical. Understanding each other means having shared context and making sure that each shared context is as close to the truth and identical as possible. Thereafter, each interpretation will yield more consistent and better integrated results, which ultimately strenghten the final product, positively impacting user experience.

Among the most common practices, you will find the following:

  • Align on objectives across hierarchies, skills and business units. You may use visual boards to agree on responsibilities, risks, objectives and so on;
  • Share constraints so that everyone can agree on structural decisions, then document the results and enable everyone to ask questions by setting up different channels such as “business hours” events, Slack channels or a hotline;
  • Grant resources unconditionally. You may want to gate UI design tooling to just UI designers, but that may be a mistake; training curious POs and developers to UI and UX ideas can benefit everyone. Use visual boards like Slack canvases to share your context and ease access to your resources with chatbots or guided tours.

Communication

There’s no secret: communication is at the same time critical and hard. Too much and the message gets lots under layers of unnecessary verbiage. Too little and nobody can tell what you are doing and where you are headed. Each individual, team and organization is different, therefore this point is not about tooling but about how to make communication effective cross-organizationally.

  • Communicate regularly: whether by text or by open meetings, make sure each scope, project and initiative has regular occurrences where other people in the organization can collect information about your progress. You may also segment your communicatiobn by project phase (discovery, delivery) if your work is highly parallel and phase-dependent;
  • Communicate asynchronously because not everybody can be on the same page at the same time. Prefer written and visual communication that can be picked up or resumed at any time. This will also benefit teams scattered across time zones. Create dedicated channels per project, scope, theme, feature and clean messages up regularly by archiving them. Never delete any message!
  • Making work visible outside of your team is essential. Any way will do: public channels, intranet and internal events to name a few.

Opening up to developers

If your company produces software, knowing how it is produced and how to integrate with the production chain is valuable. It turns out that doing so without increasing the complexity of the work is not necessarily difficult, only unconventional at best.

  • Invite developers to the user research phase. They don’t need to participate to interviews but they could, otherwise they can be granted access to debriefings, private livestreams or replays. If you plan on inviting developers then make sure to inform then early enough to avoid disrupting their production flow;
  • Join established rituals. If the engineering team conducts regular load test sessions, designers can use this opportunity to discover user experience pain points;
  • Share positive feedbacks, not just tasks, bugs and critiques. If the development team helps you achieve your goals, let them know that they did good and encourage them!

Remember we are all humans

Larger organizations tend to specialize their structure and communication. The message gets diluted, the lede buried and a diverse set of people must learn to cooperate and hone their skills on an ever changing set of practices and tools. Growth always comes with a learning curve and key amongst them is the fact that we are all humans.

For one, sometimes people just don’t want to work together and will actively prevent that. So be it! Avoid wasting too much energy on them and focus on productive relationships that lead to fruition. Always strive to make cooperation across the organization smoother as noted earlier, though!

We swim in a sea of tools, both internal and SaaS. As makers, we know that our scope grows over time. Comes a point when multiple tools implement roughly the same features. Similarly, you will have mastered the set of tools you have been using and will be in search of something that extends your reach. Think again: it may happen that your organization has got a solution lying around that might suit you, or a SaaS plan change could avoid integrating another provider, or a small favour from a development team might save hours of negotiating a contract. Only request new toys if there is no alternative.

Questions and Answers

What did you get from developers following user research invitations?

It turns out the feedback from developers was positive! Following the session livestreams, developers understood designers decisions better and adhered more and closer to the intent of their tasks. They also grew more curious, which unlocked new ways of interacting and growing with the team.

How much time does it take to implement these practices?

It didn’t take too long if you consider the tools and people are already present. This is about implementing practices one at a time and scaling them up whenever their effects are positive. Creating document templates did take a bit more time but it’s worth it due to their low maintenance requirements.

Who implements those solutions?

Anyone with enough initiative, really. Bottom-up implementations don’t succeed in every organization, though.

Strategy: invisible yet essential to any good design

By Chloé Mackie, Chief Product Officer @ ExplorationX

For any organization, staying still is a risk that leads to its slow and painful death. Everything changes and everything must follow the change or at times lead the way: technoloigical progress, disruption, user needs, the market. We talk a lot about Artificial Intelligence nowadays. Learning how it can contribute to internal and customer success is a great deal when it comes to competitivity. This requires sharing a vision and commiting the means to achieve it or, to put it differently, a strategy.

First, let’s define what a strategy is not:

  • Objectives and metrics: a strategy is more than what you are trying to achieve and how to track it;
  • Roadmaps and plans: these lay out actions, alone they don’t represent a strategy;
  • Product features: they stem from the strategy.

A good strategy is a commitment resulting from a series of decisions. Choices made about the users, the market and even elements outside of the scope of the product! Refusing to implement features is part of what makes a strategy good.

The components of a strategy

A good strategy involves six pillars:

  1. An audience and a target, basically defining the who and their context;
  2. User pain points, their problems and what is being solved exactly;
  3. The value proposition of the product;
  4. Differenciation versus the rest of the market and positioning;
  5. User reach, as even the best product does not magically reach its target;
  6. A solid business model to become profitable before the investments run out.

The Design team is best positioned to contribute to the first three of these pillars, as their responsibilities extend to user research, experience and product design. Moreover, a good strategy focuses on the customer and their needs. The purpose of the remaining three pillars, the alignment between the product and the needs, is the Product Market Fit.

While execution is important, a good strategy will lay out the foundation for the medium to long term. To achieve a flywheel effect, there must exist a feedback loop that feeds back results into the strategy and since the strategy is user-centered, it will incessantly cater to the user. Bringing more value to the user leads to more revenue in the form of better user retention, margins or increased value per user. This revenue helps in developing a strategy that further differentiates the product from the market, enables the organization to take more risks without tanking their product, increase revenue and improve and innovate.

Understanding the problems, needs and objectives well is the keystone.

Questions and Answers

We see a lot of AI integration into products. Is is really that much of a differentiator?

AI is a tool, not a response! The user must always be in control and the AI integration must be here to assist and accelerate the user in whatever they wish to accomplish with your product. AI by itself has no value and is not a “vision”.

How should I bring light to a problem when the team is focused on developing solutions?

Data is both qualitative and quantitative. Both attributes must be used when conducting user research. The echo between the data and observations gathered from user research is what validates and defines the problem at hand for the people who develop solutions.

When must product strategy pivot?

It depends on the product stage. Get feedback from your users early and often if not constantly, analyze it and derive decisions. Do you have a value or a discoverability problem? Don’t forget you can sunset products that don’t work at all.

Does it happen that a company must switch from product design to designing for growth?

You must define how the product will reach its target early in the development. Marketing and Design teams must work together on product experience from the first time a user engages with your brand, from whatever channel they chose.