Creating the company's first end-to-end editing platform to support the needs of small businesses.
WEBVELOPER/BIZWISE—SUMMER 2020 INTERNSHIP
Timeline— May to August 2020 Role— Lead Product Designer alongside Jennifer Ngo, another intern
Webveloper is a Bay area startup that aims to become the backbone for small service businesses. After identifying a gap in the needs of those from more traditional backgrounds, the company wanted to provide an array of web tools that would allow small business owners to easily host a website and manage their day-to-day operations. Over four months, we designed the company’s first client-facing website editor. This editor would allow the business’ clients to easily change, remove, or add content to their website.
An overview of our process:
Due to a series of unpredictable events, our design team of originally three members was cut down to two; Consisting of one other intern and myself. Having no mentor for the bulk of our internship meant that we leaned heavily on the Design Thinking process to build the editor from start to finish. Notably, the engineering and product teams had already previously scoped out the project in terms of its functionality and general user flow. Being a small and fast-paced startup, the objective was to finish the editor within three months. This meant that the majority of our time was spent ideating, prototyping, testing. The graphic below pictures the steps we embarked upon.
PHASE 1: EMPATHY
Investigating user and business gaps
While Shopify, Squarespace, and Wix are all website editing platforms that allow businesses to grow their online presence, these products are geared towards e-commerce entities and users who are tech-savvy. While a young entrepreneur might be able to design and build a modern looking website on Squarespace, a fifty year old barber shop owner will probably have a lot more trouble doing so. This is the user gap we’re aiming to fill.
On the business end, having employees manually respond to edit requests from clients is time-consuming and not a scalable model. The business would benefit a lot more if their workers dedicated their time to building new modules and features that our clients have been asking for, instead of doing mundane manual tasks that can be automated.
PHASE 2: DEFINE
Defining product and business goals
Based on the user and business gaps addressed above, and having further conversations with product and engineering, we were able to define our main goals for this project:
Product goal: Create an an intuitive editing tool so that even Tom, the fifty year old barber shop owner, can easily create and maintain a website that is cleanly designed and functional.
Business goal: Create an efficient and scalable editing tool that can automate current manual tasks, give users more interdependence and freedom, lower customer service costs, and increase user engagement.
These goals will be used as our guiding principles for decision-making, and can be used as metrics to later track our success.
PHASE 3: UNDERSTAND
Understanding the webveloper ecosystem
Taking a step back, it was important for us to understand how the editor fits within the Webveloper ecosystem. In other words, the editor was only a system within a system of systems, and we needed to understand how these systems were connected. To do this, we used insights from the product and engineering teams to build an information architecture and visualize this complex ecosystem.
Creating an information architecture played an important role in developing our understanding of the following:
What parts in the editor (if any) are dependent on parts outside of the editor?
What parts outside of the editor (if any) will be dependent on parts in the editor?
What does the user journey look like before getting to the editor?
When will users likely need to use an editor in their workflow?
Understanding users' priorities and compartmentalization
To collect quantitative research from our users and better understand their needs, we created a spreadsheet of edit requests made by clients from January 2020 to April 2020. Here were some of our key insights which we would use throughout our design process:
Most requested edits (expected): Plain text edits, adding/removing links, adding/removing pages, adding/removing a service or product, administrative changes
Most requested edits (unexpected): Adding global pop-ups and banners, payment and chatbot integrations, Search Engine Optimization (SEO)
These insights helped us to identify the tasks and features that should be prioritized for the MVP whereas others could be put on the back-burner for future iterations.
Outside of identifying user's editing priorities, another big question was how users compartmentalized sections and features. To ensure that we were able to group sections within the editor in a way that made sense to our users, we conducted a card sorting exercise. In this exercise, we wrote down the different editing sections on sticky notes, and asked users to group sections in a way that matched their mental model. This would become the base of how we would group features within the editor.
PHASE 3/4/5: IDEATE, PROTOTYPE, TEST, REPEAT
Structure for the remaining of this case study
For the remaining portion of this case study, I’ll be explaining the design decisions made based off of the following hierarchy. First, addressing high level decisions in regards to the framework of the editor, then describing into decisions made on specific editing flows, and finally elaborating on interactions. While there were many iterations and screens made throughout this process, I’ll only be covering some of our key insights.
Decisions on editor framework
EDITOR DASHBOARD VS. EDITOR HOME
In the beginning, the product team had spec'd out a layout in which the editor also had an editor dashboard. In other words, a two-step process to get to the actual editing flow. While this decision made sense when thinking about scale, it did not align with the user data we had collected. After many iterations, we decided that the best option was to lean back on our users. We decided to remove the editor dashboard and focus on designing the editor home screen following the compartmentalization of our users.
Here’s an overview of how we got to that decision:
Designing the flow for categorization
For each section of the client’s website, our job was to design an editing flow that would consider functionality, feasibility, and scale, all while continuing to advocate for our users. Over the course of our internship, we designed and iterated upon 46 different user flows for each section of the editor. These range from simple tasks such as editing a short text section to more complex actions such as creating a categorized menu or list of services. In this case study, I’ll only be showcasing the steps we took to finalize one of the most complicated flows; categorization.
Albeit not a particular website section, categorization is a common flow used throughout multiple editing flows; Some of which include the menu, event calendar, service list, and products sections. The purpose of having a categorization feature is to give clients more flexibility with how they wanted to organize their products and services. That said, more flexibility also comes with the tradeoff of being more complex or difficult for users users that aren't tech savvy. Thus, our role was to craft a flow that made the categorization experience seamlessandintuitive.
THE VERDICT: LET'S GO WITH OPTION 2
After conducting a series of A/B tests with members of the internal team as well as potential users, it was clear to us that option 2 was the more intuitive flow. During our testing, 90% of users told us that they enjoyed seeing the categorization done on a new page because it allowed them to preview their changes as they were editing.
Decisions on visuals and interactions
Alongside creating the editor user flows, we were also in charge of birthing the company’s new style guide for their rebrand. Creating a strong visual language through branding was important as it creates an identity that fosters a cohesiveness throughout the business. Despite not having too much time in scope dedicated to branding, we chose our colours based on the four pillars of Webveloper’s vision: Simple, friendly, professional, and accessible.
KEY FEATURES AND INTERACTIONS
Throughout our user testing, we found that the biggest issue clients had with our prototypes was their lack of knowledge on website vocabulary and editing. When testing the user flow of adding a hero banner to their website, the first thing that most people asked us was "What's a hero banner?" To accommodate for these pain points, we created a number of key features and interactions to teach our users how to use our product as they're editing.
Throughout the editor experience, we made sure to provide as much context as possible, while straying away from overcrowding the screen.
An optional feature designed to allow users to learn more about CTAs, vocabulary, and website terms by hovering their cursor.
Despite not having the feasibility to edit directly on the preview, users can still hover over sections of their website to reveal the name of the section and jump to a specific editing flow. This allows our clients to get familiar with terms used throughout the editor, and removes the hassle of trying find the target section amongst a long list.
The final product
Wow! Can you believe you made it to the end of this case study? Whether you read up on the entire process or simply skimmed through, here's a walkthrough of how users would use the editor to change their hero banner.
Invest time into testing our high fidelity prototypes with more users of our target demographic. Given that our internship was coming to an end, the company was not able to acquire many participants to test with, and needed the product to be shipped immediately. Thus, there are likely pain points and perspectives that we may have missed in our current design. Another next step would be to identify key metrics post-launch, to measure usability and success. This can help us validate or challenge some of the assumptions made during the process.
Don't just rely on the process. Instead, lean in on your toolbox. In school, we're always taught to follow a process when designing. While this isn't wrong, designing the editor taught me how the process is rarely linear. Are these methods and techniques for design processes still helpful? Yes, they are. But are they the only way to solve a problem? No, they're not. As a designer, it's really important to be flexible and be able to pull the right tools from your toolbox at any stage.
Advocating for design in a small startup. It's not uncommon to see small companies brush over the user experience of a product when they feel that they don't have the budget or time to invest in good design. This was my case, especially because the design team consisted of two interns. Looking back, there are things that I would have done differently. I would have pushed for more user research and for alternative features because it better aligned with our data. But while I have these regrets, I also know that I will carry on these learnings into my future work. Through this internship, I realized just how important it is to advocate for the user as a designer. Because if we don't, sometimes no one will.