For the founders and product leaders who work to reduce their churn rate by optimizing their customer onboarding, or by planning content-driven customer-journey, or by revising their SaaS pricing strategy and positioning on the pricing page, or by redoing their Help Center as a strategic business asset, they do not really care whether I was working with them as a content strategist, or a UX manager, or the PM. This is because I try to work with them for their systems.
What are we fixing
Talking about my work in content strategy or design, I get a feeling that I have been battling the same kinds of battles for far too long, raising the same types of questions among the same or similar type of product teams who have similar working frameworks, leading to similar results.
Some of them could scale and they are doing well, a few are growing, and a few others are closed by now. However in a new contract even in 2021, the education cycle has not changed much — why content for design and onboarding, and why the design-centric product culture.
If there are gaps on the interface to onboard new customers, it is a product problem first and a design or content problem later. Fixing content as if we are fixing content or fixing design as if we are fixing design is such a patchwork way of doing things.
So, let’s fix the real thing.
Rather than fixing our CMS, or interface content, or the Figma files, or the style guide, or the customer journey mapping, let’s see why and where something breaks.
In our work, sure we are giving our best shot, and so many people in the other teams are doing their best in planning and designing products, for the investments in research, architecture, positioning, and making it work for the organization. It is safe to assume that every team is committed to make things better, to make the process more streamlined and useful for every one towards the business bottom line. If this is true, why is it that so many digital experiences are immature or broken around us? Or if we are improving, isn’t the progress too slow? I find it slow because we talked about the silos, designing faceted search best practices, the content ROI, the CMS, and structured content, in 2010, and in 2015, and we are talking about many of these in 2021 too at the content and design conferences.
The introduction of the ‘content design’ and ‘UX writing’ roles or practices is not a transition or a progress from ‘content strategy’ and ‘microcopy’ respectively. These are just a sign of changes in how we see things in our work, and not necessarily for how we plan or fix things.
The struggle of ‘versus’
Since we have our own goals, and frameworks, and evaluation criteria for how we measure our work and the team’s success, it makes different teams see the “clear and urgent” goals, differently. Since I plan to talk about content supply chain, let me explain it in the language of supply chain.
In the technology organization, there is a struggle between the urgency of processing versus delivery, between serving the business versus customers or sometimes serving business versus customers versus teams, between standards versus shipping date, and between business versus self. To plan content while living in this struggle is patchwork. Imagine that we design an omnichannel customer journey mapping while looking at this struggle as an icon that is pinned in our dock or taskbar?
To expect that the stakeholders will understand why you need to update the design system to include content standards, is patchwork. To expect approvals for a Marketo or Hubspot because your spreadsheets validate this need, is patchwork. To try to plan or fix the leaking the content supply chain while staying in this constant struggle is patchwork.
In June 2018, SDL commissioned Forrester Consulting to evaluate enterprise content supply chains. I cannot find the report online now ever since SDL URLs point me to RWS but you can try this original URL. The report shared many useful findings that highlight the content gaps in the organizations, for example—”The department decision makers report that they are heavily involved in content areas owned by others (for example, 56% of marketers and 44% of customer support professionals say they help deliver product information). They need content in different formats which means that they recreate content in the format to suit their need.”
Our choices
How do we start a new project? One or two meetings to discuss the org goals, product goals, product vision, a quick reference to the market, the role of design and content in these goals, designing a team or being part of a product team, and the kickoff meeting.
The modern organizations are structured around different teams which are internally designed for specific functions. In spite of our work and relative success in establishing shared understanding of common goals, in design systems, and the stakeholders mapping driven brand narrative workshops, these teams or departments within the same organization depend on each other for the flow of digital assets and information and sometimes the control. Since they have the choice to interpret, process, and use the assets and the information independently, these behave and operate as different subsystems within the org system.
When we want to change something in one team or function such as how the content is or should be planned for the interface, or for the interface onboarding specifically, it calls for structural changes in other functions.
- Does the marketing team use the same vocabulary
- Does the landing page make the same promise?
- Does it comply with our design systems?
- Is the message in the sales demo in sync with the onboarding content?
- Do we have the right approvals?
It asks questions that are not always welcome because it raises structural conflicts because we are not wired for new questions because the orgs are designed to resist change, because that is the only way to operate they know.
The choices exercised by each subsystem within the larger system and the outcome of their decisions tend to create a mess, explicit or hidden, and that is why business design or business architecture, or organization design sit somewhere at the heart of the current and emerging concept of systems-driven thinking.
Systems
While I was studying computers in the college, I studied Chandigarh’s architecture as a leisure activity and I got to know the story behind what we see as one of India’s most well-planned and modern cities. The city’s grid-like structure (much before the bootstrap layout became our preferred front-end framework) facilitates proximity to essential services for mobility and access, and by considering the sunlight, the directions of wind at different times, and to neutralize and absorb the industrial pollution for the city residents by planning a mango belt with almost 5000 mango trees which does not allow the industrial pollution to enter the city in the evening hours (source).
Designing Chandigarh is not only a subject of city design, it is a great reference in system design as well.
We need to discuss content and design in the language of systems. In the book, Systems Thinking: Managing Chaos and Complexity, the author Jamshid Gharajedaghi writes:
In The Design of Inquiring Systems (1971), Churchman demonstrated that the best way to learn a system is to design it. Later, in A Prologue to National Development Planning (1985), Gharajedaghi and Ackoff use design as the main vehicle of social development. The design model explicitly recognized that choice is at the heart of human development. Development is the enhancement of the capacity to choose; design is a vehicle for enhancement of choice and holistic thinkingDesigners whether they are org designers, interface designers, or system designers, or culture designers, need to invest in their own learning and unlearning to know how designing one part of a system impacts the other parts and it means that designers need to understand the interactions among the subsystems.
The path
How well a system succeeds and scales inclusively, depends on the nature of interactions between its parts for the identified parameters such as synchronization, timeliness, and mutual respect when there are dependencies. In social systems such as in technology organizations where we see that a CMS is virtually implanted in the Ops as if a dental surgeon would implant an artificial tooth in a mouth wide open, it gets even more important because of the subjectivity involved and because of the individual choices involved.
Aristotle said — “The whole is greater than the sum of its parts.” Look at a few sports teams, for example the New Zealand cricket team. Whenever they do well, especially in the last few years, they are able to challenge better and more fancied teams because they are such a perfect example of system thinking at work—they don’t depend on individual brilliance but they give their everything as a team, and as a system.
If design systems were an answer to the bigger problems, the objective was to solve the design problems in context of the product. It may not necessarily mean that they are solving these in context of the organization—certainly not for the organization as a system. There is a difference.
At best even if we widen the design systems’ scope for their sphere of influence, these are still a means to systemize the design, as Jina Anne raises it here and not to systemize the system itself.
Before we discuss what makes systems, lets understand what breaks systems and the supply chain.
There are many examples of cascading failures where in a system, the parts are so closely interlinked and interdependent that failure of one part impacts or limits the usefulness or the performance of another part, and then another part, and so on. Here are a few examples. The power blackouts are the classic examples of cascading failures where an unexpected load on one power grid triggers an overload in other areas and then more areas, and it causes the blackout. In our world, the classical example is of Gmail going down for 18 minutes in 2012 because of a logical error in Chrome’s synch operation (source). Food chains are so crucial for the ecological balance in nature, or the domino effect (example).
In a story, if a frog is suddenly dropped into boiling water, it immediately jumps out because it feels the heat. You might have heard of this boiling frog mental model way of explaining org changes. However, if you put the same frog in warm water and then heat the water gradually, the frog boils to death. With the gradual rise in temperature, the frog adapts and learns to stay in water. We see the same behavior in a lot of social systems—in the organizations around us. The capacity to adapt gradually to their own environment can lead to a disaster if they are not responding to the right variables. By the time they notice the problem, it is already late or they need to reinvent a lot of things causing massive debt that we call technical debt.
Orgs who continue working towards short-term goals for their quarterly or half-yearly goals may never think that they need to invest in bigger and longer-term goals towards sustainability, beyond survival. They write code or content for their ‘today’ and when the org scales, they need to redo a lot of things, causing a lot of waste of time, energy, and money for everyone—the people, as well as the org. So often, this tech debt piles up leaving the org with zero or too little reserves of energy.
This is why inducing the right change sentiment to the right team, at the right time, even if with low or minimum results is so important.
The early steps
Let’s have a quick recap and refresh what are our common challenges in the broader sense.
- Selling the value of content
- Designing omnichannel experiences and planning an inclusive customer journey that is evidence based
- Establishing content standards across different functions in the organization
- Aligning the taxonomy-driven product information with the GTM strategy
- Matching content for the velocity in product life cycle, which means intersection with DesignOps, DevOps, ContentOps, RevOps, CEOOps, and so it is an intriguing intersection of content vision, org goals, and the people and tools working together to take it forward.
I would not propose any of these as we see it. I will not redraw a checkout form to increase conversions because it smells of a solution that might work till Tuesday next week.
A systems-driven content supply chain is possible when you design a system or when you advocate to co-design a system. What happens to our work in two years or in five years from today? Who cares for the file that is available in six different versions on SharePoint?
Unless we fix the systems, the content supply chain is a patchwork.
As I said earlier, the teams in the modern organizations are empowered to make their own decisions because they have choices, though often within the organization’s decision models and frameworks. Systems-driven digital assets supply chain ensures that these teams exercise the choice with more contextual awareness of the interconnectedness with other subsystems, and the interdependent variables that determine the overall success of the org. This content supply chain is the lifeblood of the customer experience.
Rather than working as the for-hire architects where we design a building and hand it over to the people for whom it is designed, we need to plan for beyond the interface, beyond a sale, beyond the deliverables, and beyond the spreadsheets.
We need new frameworks that help us to plan content and design both—independently and collectively, for the systems and not only for the product. To do that we need to unpin or hide the default struggle icon in the dock or taskbar—the icon of the struggle of versus.
The pretense debt
We as content and design practitioners are so uniquely positioned to use our experience as informed system thinking practitioners to build the systems that survive, and not only survive but grow and mature for the real use, by eliminating waste—the waste not in the MVP sense but waste in the massive tech debt, the management debt, the cognitive debt, and sometimes the pretense debt because we get into the habit of staying in the pretense.
If we continue to overlook the systems, the debt grows to become the guilt debt.
Be difficult
It is time to get out of the aesthetic arguments of fixing the CMS. Really. It is perfectly fine if we are seen as difficult thinkers, or someone who is difficult to work with. This is our job, just as army persons are—sometimes difficult or oftentimes difficult but to guard something. Imagine how someone campaigns for ocean cleaning, or to arrest forest fires. Are our challenges bigger than theirs?
Keeping in mind the pace with which we have got access to many work optimization tools whether it is Notion, or Miro, or markup utilities, or collaboration tools, if we continue to do the patchwork which cannot ensure a timely, and in-context content supply chain for an organization for its entire system and for long enough, it is a sign of our weakness or our failure because we owe so much to the people, to the community, and to the network of network of the people who try to use the products that we design and ship.
Aren’t we stronger than what we think we are? We are.
Photo credits Unsplash
PS: Systems have a life. They are a network of lives. Beyond a lifespan.
Sources
- Systems Thinking: Managing Chaos and Complexity, by Jamshid Gharajedaghi
- Super Thinking: The Big Book of Mental Models, by Gabriel Weinberg, Lauren McCann
- Lots of conversations on Twitter, and in my work communities
- PS: I am speaking on this topic at the OmnichannelX 2021. Join me there to discuss.
