Based on feedback from customers, ScaleGrowth understood that the lack of a main community portal was a problem for end users. Currently, when a community member logs into their community platform hosted on ScaleGrowth, they are taken to their user profile. There is no home page for community members to view interactive elements of their community, such as upcoming events, forum posts, or recently-joined members.
Because of this, community members felt confused on what to start out with, and community founders felt that they were not seeing as high engagement numbers from their members as they would like to achieve. In fact, one customer switched to a competitor's platform for these reasons, saying that while the functionality in ScaleGrowth was more powerful and useful for the owners, the UX failed to meet the level of experience they wanted to provide to their members. Such feedback made the redesign of the ScaleGrowth product's end user interface extremely important.
In this project, I created a design for ScaleGrowth's end user dashboard, a new feature that aims to show users recommended content from their community based on their interests. I also updated the design of their product's UI to follow an established design language, and bring a more modern feel to the product itself. Although the new design hasn't yet been implemented on the live product, it is in use in demos, the company's website, and their investor pitch desk.
I was brought on as a product designer to work on this project for ScaleGrowth. The project took about one month, and I was the sole designer on this project. I collaborated with the founders of ScaleGrowth, their front-end engineer, and their UX advisor. My role included taking feedback from customers and synthesizing that feedback in a direction to take the product, and then creating wireframes and prototypes to showcase the UI/UX improvements and hand them off to the developers.
When I initially started working on the UI redesign and end user home feed for ScaleGrowth, I proposed the process below:
Assess customer feedback
Identify common themes within feedback from customers, and use these as starting points to dig deeper into functionality problems UX can address. From there, define priorities on what to implement immediately to grow customer retention.
Revise visual design
Identify elements of visual design that customers prefer, then create several options of mid-fidelity wireframes based on inspiration images from customers. Collaborate with the team to select preferred designs and iterate on those for high-fidelity wireframes. Build reusable master components of common UI elements in Figma that can be used in high-fidelity site-wide prototypes. Hand off visual design and cosmetic changes to front-end engineers for implementation into the live product.
Propose UX functionality updates
Deep-dive into the problems stemming from product complexity and assess where users become confused. Focus on identifying ways to streamline the site architecture and finding intuitive locations for features.
However, as I was working in a rapidly-shifting startup environment, where priorities could change on a moment's notice, my actual process during this project was more like this:
RESEARCH: Assess customer feedback; review inspiration images, competitor products, and industry-wide best (or at least common) practices
IDEATE: Create low-fidelity sketches and present to team to discuss initial design direction
REFINE: Take team feedback and implement it in first version of high-fidelity prototypes
REVISE: Update high-fidelity prototypes based on iterative rounds of team feedback, often focusing on one element or feature per round
HAND-OFF: Reach a design state that the team is happy with, pass it on to front-end engineering, organize Figma for future iterations and new features, and document process
For this project, I used Figma to create high-fidelity prototypes of the product redesign. I also drew out preliminary ideas by hand as low-fidelity sketches. My process was highly iterative, as I wanted to involve the team I was working with and get feedback from the company's founders on what direction they would like the product to go. Whenever I completed a new design, I would create multiple options, present their pros and cons to the team, and open a discussion on which option was preferred by the team. Using the feedback from those discussions, I would move the design to the next step, repeating the process as needed.
The very first part of the process was a research phase, in which I reviewed feedback from customers and looked into competing product offers. My goals here were to understand pain points that customers and users were facing with ScaleGrowth, and then use that information to identify solutions that would solve user problems. It was also important for me to understand what ScaleGrowth's competitors were doing and compare areas in which ScaleGrowth fell short versus areas in which they out-performed their competition. Finally, I looked at commonly used design paradigms from popular products with huge userbases, so that I could determine what design choices may best support ScaleGrowth's goals for creating the end user feed and overhauling their UI design. All this information, once synthesized, would affect the direction of the UI redesign and end user feed.
Many customers were happy to be very open and blunt about where they wanted to see improvements, with one community providing a Pinterest board of UI inspiration to show how they wanted ScaleGrowth's platform to feel. Others mentioned products besides ScaleGrowth that they had used in the past, which formed a valuable baseline of comparison, especially when learning about features and elements that users liked or disliked.
Some of the inspiration images provided by customers — most are from Dribbble and Pinterest. From these, I was able to get a more clear understanding of what customers envisioned when they said they wanted the product to feel "modern" and "appealing". Many of the inspiration images feature copious use of negative space, cheerful colors, and rounded edges for a friendlier feel.
NOTE
Customers and users are not necessarily the same groups of people!
In ScaleGrowth's business model, customers are typically people who run a community or network - they pay for ScaleGrowth's services in order to host their community online, run events, manage networking, and more. In contrast, users can be community owners, but most end users are only members of the communities hosted on ScaleGrowth. It's important to note that the user experience for these groups (owners vs. members) is also different on ScaleGrowth, as owners have access to a host of administrative tools that members don't see.
In addition to gathering information about customer preferences and competitor offerings, I studied well-known products by successful tech companies (e.g. Facebook, LinkedIn, YouTube, Instagram) that utilized the style of feed that customers wanted to see and that the ScaleGrowth leadership team was interested in implementing. From looking at these products, I was able to reflect on commonly used design paradigms, and incorporate those ideas into suggestions I presented to the team and into the overall home feed design for ScaleGrowth. I was particularly interested in how feeds display content to users and encourage user engagement with that content, especially when the content's types are non-uniform. For example, LinkedIn has many different content types that are all presented in its home feed: events, connection recommendations, new job posts, discussions from other LinkedIn members, and so on. Similarly, Facebook has status updates, marketplace posts, events, videos, and more — but all the different content types are presented in a uniform way to optimize user's familiarity with the platform.
Screenshots I took of Facebook, LinkedIn, and YouTube while researching scrollable feeds and comment interactions. I was especially interested in the ways that Facebook and LinkedIn presented content, as discussed earlier, since those platforms effectively integrate different types of content into a unified, easy-to-use format.
Overall, this part of the project was smooth — while there were no overt problems, in retrospect I would have liked to have slightly more extensive user interviews with more end users (community members) rather than only customers (community owners). While I did create an end user survey, it was not circulated to end users due to the rapid pace of the project and the urgency of the UI redesign. I also was not live on any customer calls, but was able to get enough data to work with through recordings and call transcripts that were provided to me. With the information that I was able to gather in this step, I was able to begin working on low-fidelity sketches.
After the research phase was complete, I had enough material to begin ideating on the UI redesign and direction for the end user home feed. Some main points that stuck out from my background research were as follows:
Visual polish was a huge pain point for both community owners and community members. While community owners were pleased with the powerful tools ScaleGrowth offers, they felt that the overall user experience was not meeting their expectations for the type of experience they wanted to provide to their community members. Similarly, community members felt the UI was lacking compared to competitors, and further had nowhere to see all of their community's updates in a single place — the default view a community member would see upon logging in was their own profile, not something to do with the community itself.
Community owners wanted to increase user engagement with their communities by making it easy for their community members to find and access community content.
Community owners often commented about the complexity of the product and the confusion they faced when using it. Some parts of the product were not clear to them in terms of functionality and impact on their community platform, while others were just hard to locate or worked in un-intuitive ways.
The first two points were certainly addressable by this project, and the problems presented here could be effectively solved by implementing an end user home feed and updating the visual polish to be consistent with customer demands. The last point was more complex, and could not entirely be covered by the scope of this project — when considering customer feedback and available engineering resources, visual polish was prioritized over functionality and information architecture changes. However, in improving the UI design of some existing features of the product, I was sometimes able to make information architecture changes as well, although in terms of engineering effort these changes are more time-consuming to implement.
Given this understanding, plus my research data, I began creating low-fidelity sketches that conveyed my idea for a home feed design that would:
Provide easy-to-find CTAs to get community members more deeply engaged in their community
Present ScaleGrowth's product as modern and sleek by improving the visual UI design to utilize contemporary visual styles and familiar UI patterns
Allow users to easily discover new content featured by their community
My main proposal at this point was a horizontal-scrolling selection of featured content, which could potentially be controlled either automatically by an algorithm or manually by community owners. This would be followed by a content discovery feed that pulled content from a member's personalized interests within a community to show things like upcoming events, recommended network connections, forum discussions on relevant topics, and so forth. I also wanted to make sure the same sort of paradigm would work on mobile, so I started thinking about the problem from a mobile-first perspective, knowing that horizontal-scrolling is a commonly-used design paradigm for showing more content types on small screen sizes.
An example of an initial sketch I used to convey an idea for the structure of the end user home feed on desktop and mobile. During my lo-fi ideation process, I also identified some design goals, listed features that the team wanted to prioritize for the home feed design, and wrote out questions I wanted to work through with the team.
I took my sketches and a number of clarifications to my team, and had a discussion on the ideas I presented. Some particularly useful feedback I received included:
Creating multiple feed options to explore how featured content could be integrated into the feed more directly, without horizontal scrolling, in order to decrease interaction types and reduce engineering effort needed to implement a carousel element
Adding CTAs directly to content cards in the feed
Making content card types visually distinguishable from each other in order to remove the type badge (e.g. instead of labeling a card "event" or "forum", make event cards look completely different from forum cards)
Taking the feedback from the team, I updated my sketches, then got to work building high-fidelity prototypes that would be true to the product. An few interesting consideration I had to keep in mind through this process was the fact that community owners can change their platform's color, which meant my designs had to work well with any accent color, not one we preselected.
I took the UI design methodologically, first applying the new design language to the mockups in Figma, and then making UI/UX improvements where needed, such as to define a new CTA or highlight a particular feature. For each improvement I suggested, I also provided alternative designs, to show how different versions of the UI would look as elements changed positions, colors, and so on. This iterative, option-heavy process allowed me to easily collect asynchronous feedback from the team, and quickly incorporate that feedback into the designs I was actively working on.
Variants of the Events page cards that I created during iterative cycles between the ideate and refine phases of the project. The final version is in the bottom right corner.
Variants of the Events page cards that would be shown in the end user home feed, rather than on the main Events page.
After getting feedback from the team on the various elements and their variations, I was able to pull together the different components in Figma and define the set of interactive elements that would be used throughout the whole site. Using those elements, I created high-fidelity mockups of the pages that were the focus of this redesign project: the end user home feed, forums, events, and resources.
Again, I shared my designs with the team, and made adjustments according to the feedback I received. Once the designs were approved, I finalized the high-fidelity designs for the desired screens.
These are the completed high-fidelity wireframes for the end user home feed, event page, resources page, and forums page.
After finalizing the designs, I prepared the high-fidelity mocks to be used by the front-end developers at ScaleGrowth, and called a meeting with the team to go over the final designs and give everyone a chance to ask questions. Additionally, I organized the Figma file to demonstrate which UI elements were the finalized versions, while keeping the alternate versions available for future reference. This file structure now provides the basis of a design methodology at ScaleGrowth, which can be replicated when exploring new designs for other features of the product. Finally, to improve reusability when creating new mockups, I placed the finalized elements in a master component library in Figma for everyone to use.
New Figma file structure -- UI element explorations and iterations are done below the product page screenshots. Once a UI element version has been selected as the version that will be used on the live site, it is moved to the top of the file and placed in the appropriate grid cell depending on its use case (e.g. mobile vs. desktop, and main page vs. feed content vs. featured content). The full page wireframes are high-fidelity product screenshots showing how the site will look with the finalized UI elements in use.
I gained valuable experience working in an environment where priorities often shifted in response to new information and feedback from customers, and found myself able to quickly adapt to new goals and requirements. For example, as mentioned earlier, the design process I initially proposed ended up not being the process that I followed in practice, which was a result of the need for rapid iteration cycles and agile design.
Of course, as a result of this, some considerations from the beginning of the project no longer applied by the end; however, the objectives defined by ScaleGrowth's founders were met, and they were very happy with the designs I made.
During the course of this project, I ran into several challenges, the most notable of which I have listed below:
Remote environment and time zone differences
Because the engineering team is based in Australia, all meetings took place in the evenings (US time). Accordingly, to get feedback on design iterations, the team heavily relied asynchronous messaging via Slack. On one hand, there were delays in getting everyone's feedback due to these constraints; however, there were several benefits to almost exclusively using Slack for design conversations: all feedback was documented, Slack thread links were easy to add to design and engineering Kanban boards on Trello, and votes could be easily collected in one place. Whenever Slack wasn't enough, despite the time zone differences, it was relatively easy to set up a team meeting over Zoom to share screens and have a face-to-face discussion to get feedback or decide on next steps.
Rapid priority changes
Due to startup environment and small team size, priorities constantly changed quite quickly. Customer feedback and needs had a heavy influence over what features and requirements were being actively worked on each week, and projects could fluctuate or change scope in a short amount of time. While sometimes challenging in terms of planning, I liked this aspect as I was always doing something that was important and directly impacted both the team and the users.
Sole designer at ScaleGrowth
This was another challenge that I liked; while being the only designer on the team meant that I had an intensive workload, I enjoyed having full creative control over design (within constraints such as the design library that I helped develop), and having the flexibility to explore new ideas in the context of real user problems. ScaleGrowth has an UX advisor that consults for the company, so I was able to get feedback from a much more experienced UX designer as well -- because of this, I learned many new processes and techniques, and was able to experiment with new design systems and methodologies.
Revisiting this project, I would like to more heavily focus on information architecture and the way users actually interact with the site. The current version of this project was more of a visual refresh for the product, plus design of a completely new feature. However, based on feedback from multiple customers, we know that complexity of the product is an issue, and that there are numerous places where usability can be improved and the copy-writing and text of the product can be simplified. I originally was brought on to the team to help solve that problem, but it was deprioritized due to the loss of a customer citing that UI/UX and visual design needed improvements. I would be very excited to return to working on the overall usability and intuitiveness of the product, in addition to fine-tuning the visual design to bring in a more modern feel. Additionally, I would want to test these wireframes with actual end users and get more feedback from customers on what they want to see in their community platform feed.