Article Importer
Creating a smooth set-up experience
I lead the design process for a feature that allowed new customers to import their existing articles from Google Drive into a Zendesk Help Center article-format.
Zendesk
Product Designer
Serious companies have a help centre to help their customers self-service. Setting up a help centre can turn out quite tedious, though. This fact was obvious at Guide, Zendesk's knowledge base and help centre solution.
Data showed that new customers often had content stored elsewhere before trying Guide. For new customers, that meant manually copying and pasting content into Guide. When dealing with +100 articles it could quickly turn out a messy process. The friction to get up and running meant some customers dropped Guide during the trial. To get avoid a pure copy-paste-hell, Guide wanted to provide an easier onboarding experience.
As I started the process, I wanted to get a better understanding of the problem space. I defined the business purpose and product vision with product management. I got a grasp of the technical constraints by talking to engineering. Finally, I looped in with sales representatives - Sales representatives are great. They're in daily contact with potential and current customers. They keep a log of customer needs and requests and help me with valuable insights.
From these talks, I learned customers often had their help content stored elsewhere before joining Guide. And I learned that getting that content into Guide caused a point of friction, unnecessarily hurting the business and the user experience. From an engineering standpoint, I learned that building an import feature meant hooking up Guide to external API's. That could turn out time-consuming.
For the first feature iteration, I decided with product management we'd only focus on connecting with one platform. But what platform? To find that out, I made a survey and sent it to +300 beta-users. The results showed that Guide users stored their content in Google Drive before using Guide. Okay, so now we know which technology to focus on.
Now, we needed to determine a feature flow.
Designing software products can be a venture into unknown territory. You're balancing business requirements and technical limitations to meet a customer need. To avoid an unnecessarily messy process, it takes team alignment from the get-go. Needless to say, communication and a shared understanding are key requirements.
I wanted to get everybody on the same page on the feature. And I wanted to get as many ideas and concerns on the table as possible. Therefore, I gathered product management, the engineering team and sales for a User Story Mapping workshop. With pens and post-its in hand, everybody got together and mapped out the full feature flow. We mapped out each individual task users need to do achieve the desired outcome. With each step, we discussed which technical constraints that might obstruct the user in their flow. The resulting map served as a north star for the project.
With the map in hand, I was ready to start exploring concrete designs
In my UI explorations, I played around with different approaches. But I wasn't sure which UI pattern would be optimal. To find out, I did rounds of internal feedback sessions with designers from my team and engineers. Also, I looped in designers from our design systems team. Through iterations and feedback, I landed on two promising approaches. Both were variations and a step-wizard setup.
To test which of these approaches that would suit the users best, I built two prototypes to test with users. I wrote a couple of user tasks and scenarios according. The tests showed that both approaches worked as intended and that users found them both intuitive. However, users preferred one approach over the other, as it gave them a better overview of their progress through the feature.
Animations are powerful tools, for better or worse. If well-crafted, animations can enforce usability of the product by guiding user actions. Otherwise, animations can end up hurting the user experience.
I chose to focus on animating the user's progression through the steps. Also, I wanted to let the feature animation showcase how the feature worked.
I initially sketched out my ideas before diving into Framer. Using Framer to power my interaction ideas helped get a feel for UI behavior. I used the tool to animate different variations on a few key sequences. My design team, as well as our motion designers, were helpful providing necessary feedback. After some (meaning a lot of) of failed tries, we settled on a pattern that made sense. Throughout the process, I kept the engineers engaged to gauge technical constraints.
During development, I kept a close dialogue with the engineering team. We'd have daily sync to ensure the feature was developed according to the design vision
I set up a work session with the front-end engineer to make sure the interactions would turn out as intended. Also, we had a few minor tweaks to make before testing the first live version with customers.
The feature was initially released in to a closed group of beta users who would experiment with the feature and provide feedback in a dedicated forum.
Spent the last 2 days experimenting with the Google Docs Beta and definitely love the concept. It's exciting to see something like this coming around as it would make our content creation much easier. The importing process was simple, straightforward and a breeze!
I'm loving the functionality so far. It's been really smooth and I like that the articles are pushed straight to a draft status. I also love that I can pre-place them in a specific section ahead of time.
The importer wasn't optimal, though. It still suffered from bugs and technical issues, especially when converting Google Docs into Zendesk's proprietary format. From a design perspective, only minor changes were called for.
After a couple of months of smashing technical bugs and optimising, the Article Importer had it's public release
