It always was
It still surprises me that companies never thought that context was the always moat. That, in some products’ mind, the UX was what was meant to resonate and create product value. A long time ago, I made a blog post that I no longer have on this website called “Products as Shells”.
The idea of that blog post was that products are nothing but just an API and some knowledge within it. And that was a sentiment that I had from 80 years ago when I started working in design. My boss at that time was very clear when we were remaking the product, that we had to start with an API-driven approach. I was maybe a little too naive to understand why at the beginning. But eventually I got it. That API became our way to multiply the power of rejoiner, the email marketing product that we were building, into a tool that could be used along with any other marketing products for e-commerce.
<some code block example here />
What I also learned back then from that job, was that people came to us not because of our UX. They came to us because we offer them advice. We offer them knowledge. Rejoiner back then used to work as an agency for email marketing as well. We set up emails for our customers. We help them create email marketing campaigns. But we listened to them, and we told them exactly how to fix some of their issues, whether they’re email-related or not.
That is what made me a huge believer ever since then that products were shells. You give a product a name by creating a new company, but that new company becomes a repository of knowledge of best practices, setting standards that become so ingrained into how to do X thing in the best possible way, that becomes a value proposition.
Learning about shells
So in this new world, we’re calling that contex. Because when you are a shell, you’re also highly dependent on the data that is given to you. It’s better if you also become a shell that can create data. But most of the time, products are data consumers. So if you can read that data and generate contex, then you’re no longer a shell to become a brain. And that is what most people are buying nowadays. They’re buying a second brain. They’re buying a tool that allows them to think better, to see things that they weren’t seeing before.
And so you’re now probably asking yourself: Why is Karina, a designer, talking about this? Well, that is because it so happens that even though this has been my way of thinking about products for a while, now it’s really changing in both a good and scary way what being a designer is.
I say it’s good because this is a world that I’m familiar with. At Rejoiner I worked in the way that I think design is headed towards. Half my job was listening to customers by being an account manager while also being their customer support agent that will help them solve product issues. A quarter of my job was designing. And the other quarter was helping to understand where the business was going and where we could be. Half of it was very design-centric, right, so UX and strategy. But the other half was in gaining and providing context. And so that is likely where the signers will sit now.
And most likely there will be a split. For those of us who are strong in strategy, we will get closer to the product side. For those of us who are strong in systems, we will get closer to the engineering side. And so you will either build the contex that a business needs to build on by listening to customers. By figuring out, either through actual customer interviews or even looking at chat records, what customers need and want. Very similar roles still to what we currently do, but different because now we may get to task an agent to help us understand things faster and check patterns in those conversations.
And the other part of contex is to build it within the system itself. Train the system. Be in the harness. That means that you have to help train that product to become an expert. And at the same time, train the codebase to understand itself, to build and heal itself. Now this is a part where I’ve started to steer myself towards. Or at least for right now. My job was never to create UI. My job was always to build paradigms for a product, to communicate with a user, for a user to communicate with a product. The job is still the same, but it is widely different because of the new powers and tools that we have with AI. And so this portion is very interesting to me because for the last three years I’ve tried to be as good as possible in developing my UI skills. And now I have to translate everything that I’ve learned to a system so that they can hopefully design better UI than I can.
Here’s how I’ve been doing this.