Sitecore Search - The platform for brands and enterprises to manage the content displayed when visitors search on their external websites.
January 2022 - Present • Senior Product Designer
Sitecore Search overview
Sitecore Search is an AI/ML search platform that predicts search intent and personalizes search results on external websites.
I designed a SaaS platform where a customer can write rules that control how items show up in search, view analytics & their content catalog, and create data connectors to ingest the content that is displayed.
I was one of two senior designers who worked with a global team of 20-30 engineers to make this platform operate for some of the biggest e-commerce retailers including
Many times I would work with the sales department to design high-fidelity mock ups to customers. This meant I would inspect a website, learn their design system, and turn around with the prototypes. People are visual, and seeing the end results greatly increased the chances of closing the sale.
Here are examples of what users would see on their website (using their website style).
Here a little video I edited together to illustrate how it all works.
I was one of two senior designers on the platform.
I regularly met with the global design sync team, product management, and the engineering team. Each week we present new work. My process entails doing research, high-fidelity prototyping, and delivering spec to engineers. My goal is to always keep project moving forward every week.
I worked on many parts of the platform from analytics, the catalog, data connectors, and more.
Sitecore's SaaS product suite followed the Blok design system. This ensured there was a consistency across all the products.
Sitecore's SaaS product suite followed the Blok design system. This ensured there was a consistency across all the products.
My goal as a designer is to make the look and feel be clean, consistent, and simple. That meant using Sitecore's Blok design system to promote consistency and providing review videos while going in-depth to get as close to pixel perfect as possible.
The global design team meets multiple times a week where we review each others work and will regularly crit the products. As designers we're assigned products, but we'll periodically use each product and compile our feedback.
Customer feedback has always been extremely important to Sitecore. When we are designing and creating new modules, we will show mockups to existing customers to get immediate feedback.
Every week, I deliver high fidelity clickable prototypes of my work. This way, anybody in the org can get a link and demo it to anyone. Since I work with many cross org teams, my job is not always to deliver screens for engineers but to create prototypes of new ideas.
Additionally, I'll send Loom videos and review all the little details to ensure the implementation looks pixel perfect.
We onboarded through the sales and product led growth.
I designed this onboarding wizard to promote product-led growth. I did a lot of research on wizards and identified common patterns such as a progress indication, title question, and contextual image. I really focused on making it simple and clean.
When it came to the look and feel of the wizard, I'd experiment with various UI layouts. That could mean having a branded background, versus having the content centered or in a 2 panel look.
When designing, I'd take a step back and put myself in a user's shoes who is using the platform for the first time. Does it make sense and is there any confusion with what they're doing on that page?
In the design process, we may offer alternatives to the look and feel. These are examples of other styles I showed to the team.
Once they landed, I experimented with a page with a stepper vs empty cards vs a floating stepper.
Ultimately we landed on a mixture of having a page, but having empty analytics cards that gave the user a preview of what they could get from the platform. This was an upsell in itself that others seemed to like.
After a user was onboarded, we wanted them to have a clear step-by-step guide to setting up the rest of the platform. Since there are aspects of the product that are technical, it would require a developer persona to be involved to set up the beacon on their website, create data sources that ingested the catalog, set up attribute templates, and more. Therefore, it was critical to for me as a designer to surface all those details in guide that was easy to follow.
Brands could write rules and build segments to control how products would show up on their website.
We could algorithmically determine how to show products on a shopping website, or allow the merchandisers to drag and drop and create rules for it. We created a WYSIWYG editor that visually showed all the slots. This was a core feature that we reviewed with customers frequently as it was a key selling point of the product.
Customers could also create segments natively in the platform using this segment builder I designed. Initially the preview was separated by a button click to see it.
We talked to customers who pitched us the idea of having it in one pane. So I redesigned it with a split view that someone was called it "powerful".
When I designed this segment reporting area, I kept in mind that the goal was to help users identify trends and opportunities. From there, they could go back and improve their segments for advanced targeting. The idea was to show top objects (products, keywords, etc.), that helped marketers understand how to write better rules.
Users could use segments from external CDPs to build their own natively in the platform. When designing this, I did a lot of research on query builders. It required learning the patterns of adding conditions, grouping them, and the logic between groups. Additionally, I worked with the back-end team to understand what data we had on segments, and how that could be displayed in real-time.
Customers could view their catalog of content and products in Sitecore Search.
When designing the catalog browser, I looked at e-commerce platforms like Shopify that offered a similar feature. A common pattern i'd see is a table/card view with an ability to filter.
I reused our card pattern from the rules builder for consistency. Additionally, I designed this for multiple entities including products, categories, content, articles, and more.
They all reused the same pattern for consistency.
Since we were always thinking about how we could give opportunities and insights, the datasets tab helped our users learn more. In this example, a user can see the co-bought products within session. To take this a step further, this attribute of co-bought products could be used by in merchandiser writing a rule.
So in other words, if a user is looking at this shoe's product detail page, a merchandiser could write a rule for their "Customers Also Bought" recommendation widget to display these co-bought products within session. It was always about how we could deliver more and more value to merchandisers when they sold products or displayed content on a website.
Analytics is a key selling module for the platform.
I owned the analytics feature. I worked closely with the analytics development team to create the analytics reporting module. We would meet twice a week for design syncs over many years. The goal was to create a feature that rivaled Google Analytics or Mixpanel, but was tailored to e-commerce. This was a key selling module that Sitecore customers loved.
From a UX standpoint, I would think about what opportunities the marketing persona is trying to find. This would influence how they would create rules to determine which products or content would be viewable on their site.
I was always looking at other e-commerce platforms and researching how marketers and merchandisers manage their catalogs. It required talking to customers directly constantly, so we built the reports they wanted.
I spent years designing and working on most of the analytics reporting area. This included features such as scheduling, saving, and much more. I would meet with the analytics engineering team twice a week, as this became a key-selling module.o we built the reports they wanted.
When designing the analytics, we had a common pattern for every page, regardless of whatever reporting area a user was on. We had an overview page, an explorer page to see the entire object list, and a detail page. This created a consistent look and feel.
I also designed our analytics screens for the various screen sizes. A merchandiser or data analyst may want to view analytics from a phone, and not always their desktop. From a UX standpoint, it meant:
Deciding which icons to put under a three dot (...) menu.
Horizontally scrolling data tables.
Redesigning time series plots to show less data points.
I'd have to look at each analytics card and see how that would fare in a different screen size, and create those rules for design and development.
On any report, a user could click on an object to drill into its detail page. So in this screen, if a user clicked on a product, it would go to that products detail page and re-anchor the breadcrumb and left nav to the Product reporting area. We decided not to have the breadcrumb continuously go down many levels (like Google Drive does for example). It would require truncation and storing the path that we collectively decided wouldn't be the right model for us.
In addition to generalized reporting areas, I designed reporting for the data analysts or engineers. In this performance report I designed, a devops or L1/L2 engineer could look at the overall system performance. These type of metrics could be viewed in data warehouse platforms like Snowflake, but exposing it in the Sitecore UI gave a nice value add.
Customers could run A/B tests between widget variations to determine the best merchandising opportunities. I designed the A/B test flow, from setting up the test -> running-> viewing this report seen above. When designing this, I researched how data analysts determine statistical significance, and what they need to see when viewing an A/B test report.
Analytics were provided for multi-locale accounts across the world. I designed the reporting area that looked across all accounts and locales. That meant reports, metrics, and currencies were tailored to the region.
Since this was a technical product, developers needed tools to ensure the system was running.
I worked with our global back-end eng team a lot when designing the configuration of data sources. Although it was very technical, I still wanted to make it simple to understand what a user can do on this page. Additionally when a scan is in progress, it was important to really call it out. The mental model of all our object pages was to put each section in a block, and have all the action icons in the upper right corner.
Users also needed a place to view their source analytics. I designed the reporting area below so users could see an overview, then drill into each source or job to see more.
When designing this page, I wanted to give the users a timeline of events so they can see each stage, and when it was completed. This gave users a view into our back-end a bit. But really, what mattered was the items that were processed.
In the case of this web crawler example, it was the table of URLs indexed, where each URL is an article. Each one of those crawled URLs became a content item in the catalog.
As a SaaS platform with many technical aspects, it was important for developers to see if things went wrong. I designed several modules to assist any devops or L1/L2 engineers:
An event monitor to track that view and click events were working on the end user website.
A log explorer to make sure events in the data pipeline were firing correctly. For this, I looked at log explorers from cloud platforms such as AWS and GCP to identify and use common patterns.
A data validation report that gave a high level indication of issues, with specific diagnostics for a developer to go fix.
The idea here was to use common UX patterns that the developer persona was familiar with. From a business perspective, the goal was the reduction of support tickets.
On the data connection side, I designed this log explorer to highlight events occurring, and if there were any issues. When doing research for this, I looked at event logs from cloud providers such as AWS or GCP. I identified common patterns such as an indication of severity, a timestamp, and then some kind of summary or message that could be expanded further.
We also wanted a feature where users could validate a data connection. The idea was to click a button, have a process run, and then return the results. A user could easily see if there are any issues, and what the diagnostics are.
When designing this, I saw how other diagnostic reports would list them out with error icons, or have some kind of big flashy way of showing when something is wrong. For this, I used a ring. It highlighted when things are good/bad, but also served as a way to section off the important items. Meaning, three rings for all the three sections where the data is validated.the goal was the reduction of support tickets.
Plan management and upsells inside the platform
We wanted customers to have full control over their account and manage their subscription and more. The idea from a busines standpoint was to greatly reduce the creation of support tickets. I tried to make the subscription section clean in this shot. I'll use the squint test sometimes, and I wanted to highlight the plan, the price, and the CTA. I looked at a lot of other SaaS platforms and how they handled subscription for inspiration.
In designing this shot in particular, I really thought about: How can we deliver value in an upsell? In this case, we can employ the idea of showing, not telling, by using actual screenshots. This tells the customer very clearly what they would get if they upgrade.
We also thought about how we could use AI for shopping websites.
With the explosion of AI, we looked at ways we could use it to enhance our platform. I played around with how AI could be used in the end user shopping experience, where the typical facets and filters would be abstracted away, and a user would chat with an AI bot.
Additionally, we considered how AI could be used to give marketers greater insights. When designing this, I thought about:
What a marketer wants to know at a high level (ex. revenue is going up).
Then they may want to know why.
Afterwards, what are the actionable next steps?
Although these haven't gone into production, it was a way for us to explore AI capabilities much further.
Companies who used Sitecore Search & Discover saw lifts with metrics across the board.
We could confirm our results by running A/B tests in the background and our sales department would frequently use these results as case studies. to explore AI capabilities much further.
Sitecore Search continues to grow in sales. It remains a growing platform in the Sitecore suite of SaaS apps that offers enterprise the website search they need.
