When I think of my last couple of contracts at work, I am trying to understand how and where we build the product intelligence.
Whether we are doing quick mockups for the discovery calls with customers, or designing the journey or a service blueprint, or the interactions, or the content and the message architecture, or the search experience, we build a lot of product intelligence in team discussions.
If you see a few example designs below.
This is taken from a B2B EdTech product. We anticipate what the users might need to create a new class, what kind of questions they might have, where they are likely to find the right information, the right interactions, and how we can build the education and their confidence to take the first steps. If there are users who are already somewhere in this journey, how we can show them the progress, and take it forward.
To anticipate different scenarios of how the customers might respond to certain situations and the planning an interface and to build their confidence—this is product intelligence.
For example when we had multiple rounds of discussions and iterations in the designs for the user’s actions and their success criteria to take their journey forward—we were invariably thinking about how the message and the micro-interactions contribute to the bigger conversion-onboarding-retention-advocacy (CORA) cycle (see a related LinkedIn post).
—How to make the users feel comfortable, guided, and confident enough. How to address their uncertainty if any, and how to handle it whether the users are already aware of what they need to do, or whether they may not be sure how to move forward.
—Building the confidence in the right language, in the right structure, and keeps them focused on their primary goal of being here.
These are not about using Flutter or ReactJS, or Figma or a design system—we build this capacity, the judgement, and this awareness, by our own experience.
See a couple of more examples from my recent works.
What information could be useful for the users in the list view? How we can design it for their specific information consumption behavior or patterns. How do they process their thoughts and feel informed about taking different actions.
Product intelligence in design
We build a lot of product intelligence in design. Design takes care of how and where customer success intersects with the organization goals and the business success—how this intersection looks like, how it serves the business model, what could be the divergence points, and we document the trade-offs.
I can say that almost all the product intelligence is taken care of in the design—and it actually serves well for the engineering because they can apply the technology intelligence far more confidently and accurately in such cases.
Here is another example of where I see a lot of product intelligence in the design itself.
See how design makes it so easy for the users to make sense of what they want to see, to do, and to make a decision. The structure, the message, and the hierarchy of actions for the possible answers to their questions—how it serves their goal and the organization goal as well.
(My associate in my last contract had designed the above story with a lot of domain-driven-product-intelligence. She might have an argument here about my statements on product intelligence in design but I will take that as a separate story, on another day. ☺️)
In one of the related discussions in a Slack group, a participant wondered how engineering work such as the architecture and DevOps are not product intelligence.
Well, we rarely design the journey points or customer success criteria and their success moments in the code. The whole architecture is derived from the design—design deliverables, design discussions, design arguments, and design synthesis. Imagine if engineers are writing the code while thinking of new user stories, or adjacent possibilities within the designed user stories or job stories—they will go back to the design team to find the intelligence—what enables customer success in those stories.
If design takes care of the product intelligence, it serves for the right engineering practices to enable the experience of how design becomes a reality in the user screens.
A CTO in our discussion had a counter-opinion that to enable design via code is also product intelligence (mix of product judgment, product sense, product thinking, product awareness, and all derivates of product strategy). This is not an engineer’s job and neither their core skills to plan the customer journey and write the code for the experience. It is a good idea if the organization’s culture and the vibes encourage the engineers to learn the craft and if their engineers are good enough to think about the hierarchy of interactions and the information on an interface but more often than not—such products are likely to be an ordinary experience to use.
Engineers bring the right technology intelligence in the digital products but designers bring the right domain-driven-product intelligence in the products. You need both of these.
PS: This post is an extension to my LinkedIn post on product intelligence in design.
