Cernel Insights

User insights

Cognitive pressure - where did it stem from?

Cernel had been running feedback sessions with customers before I entered the picture. As the product matured more and more customers were onboarded and with them followed new insights into our core user’s SEO habits & expectations.

When I joined, the general consensus was that users were either dropping off, or hibernating, as soon as we stopped physically guiding them. When asked, the users typically stated being confused or unaware of what to do next — a core issue that forked from a build up of several smaller pain points.

Through interviews done with both prospecting and recurring users, we found that our product’s generated content, while being quite good, always lacked fundamental pieces of information and/or elements that users requested. When left to their own devices, our users simply didn’t fully like the texts we generated for them — and because they didn’t know how to tweak & fix the texts to their liking, tended to wait for catch-up meetings to report their problems and request fixes.

After seeing a general pattern in this behaviour, we chose to label it as a “cognitive pressure”, stemming from a feeling of too many tiny hindrances weighing on your mind, making the user feel unsure of what steps should be taken to keep going.

A paradoxical behaviour we observed, was that user’s commonly requested higher customizability while also wanting a fully automated production process, making it difficult to choose a priority for new features as both requests were quite equally valid.

Note on this subject: The real UX task (had I continued working as Cernel’s UX designer) would have been to follow user behaviour; To find when and where users want to immerse themselves in customization, and when they are satisfied with their tweaks and comfortably hand the reins to have Cernel automate future content generation.

Customer onboarding

Why were customers getting frustrated?

Using the customer’s movement through our platform, I made a condensed map of all the checkpoints that a typical customer would go through during onboarding. This was really just a sitemap of the platform and any off-shoots that would take the user to their own ecommerce site.

What turned out to be the most interesting though, was looking at the time it took for a user to go through each step of the onboarding, and overlaying how much new information they had to take in as they went along.

Most noteworthy was: While generating new content, a large amount of knowledge was needed to understand how and when to see the results — and a huge point of confusion/misinterpretation was analysing the actual generated text, and comparing it to the original text.

Because Cernel uses much of the contextual understanding of a user’s own site, new content would in some cases be quite indistinguishable if they had already used tools like Chat-GPT to help write content for their products and product categories — as you’re essentially doing the same thing, just in a fraction of the time spent coaxing Chat-GPT.

Sometimes, minor technical errors would lead to confusion about new texts actually being written at all — as the quality of newly generated texts depends on Cernel’s understanding of your site.

As such, the user would often move between platform and site, causing large build-ups of confusion — and ultimately leading to frustration with themselves for not knowing what to do, or with Cernel for not doing what’s advertised.

Expert knowledge

Why did customers need access to experts?

While working at Cernel, I got the pleasure of working with highly talented people, working at the forefront of the SEO writing industry using different AI models in combination with ecommerce API integrations. This was both a blessing and a curse — nothing gets to be entirely easy.

Our customers usually came to us with a certain “stereotype” deeply engrained in their mind: “We’ve tried using ‘AI’ before to do this exact task, and it’s been quite lacklustre. We’ve grown tired of trying, and this is probably going to be just as compromised by AI hallucinations as everything else.”

The blame for this was partially Cernel’s to bear; We simply hadn’t been able to concisely visualise why our platform could do so much more. As a result, once we were able to talk face-to-face with prospecting customers, they were almost always overjoyed with the selling point. This, however, masked a fatal flaw of the onboarding experience: Customers became quite attached to our developers in order to use the product, and only wanted to keep using it once we’d cleared all their hurdles.

In order to grow the platform, we had to siphon that expert knowledge into the product itself and make it available for the end user. Otherwise, the business would drown in customer calls, and all our experts would be spending more time filling up the proverbial tank with fuel — never seeing the hole at the bottom of the engine, leaking fuel everywhere & becoming a major hazard.

Personalisation structure

What made the iterative project structure useful?

Digging into user requests was a difficult spider’s web of wants and requirements. There was a moment during this project’s development where we’d have to lock in a sensible amount of features, so the scope wouldn’t balloon out of control.

While I was combining user insights with engineering advancements and limitations, developments were made to test feature possibilities. We found that the resources we had available to us limited our ability to lock in features, and so decided on an iterative development style.

Doing this comes with it’s ups and downs. For our development, it resulted in streamlining our decision making whenever features were being prioritised, which ultimately became a crucial part of the way we communicated changes in ever-increasing levels of detail that threatened to derail the project. It also meant gambling on a vision which we weren’t 100% certain of — trusting our instincts and gut feelings.

To facilitate the iterating nature of this project, we grouped features into configurations that could be changed more flexibly. By breaking features into Global- / Products- / & Categories, all user insights could be funnelled into each their respective feature — and any changes made to a given feature would be limited to the group.

Feature needs

How did we plan the project?

Once all the gears started getting into motion, things quickly went from manageable to disorganised. We were a small business, where everyone had a part to play and something to say. As such, I took it upon myself to organise all requests, tasks and features into a combined document.

Note on this subject: Looking back on the process, this was the moment in time where tools like Notion would have made the process much simpler. Notion however, wasn’t a strong part of our company culture, and we were about to phase it out entirely. The task management of that application would have been a strong help, whereas Cernel would instead come to rely on an unorthodox combination of planning tools.

For this project I chose to construct a document where we’d also keep everything else: Our Figma project. My colleagues were often dropping in and out of the project, and having just a single place to point each person to for clarification made the process “manageable” for everyone involved.

Still, this document full of feature needs was quite the challenge to keep updated, as I was running several job posts at the same time, and our iterative nature meant big changes were still happening quite late in the process. The project as a whole however, would most likely have taken much longer if we’d had more of a rigid planning & meeting structure. Being part of a startup means moving fast, and you often have to compromise on the luxury of clear and concise project structure in favour of using all your available resources and staying competitive.