Read Time
5 mins
Main Content Focus
Project Management
My Roles
Assigned to oversee community-related features, I regularly sit with key stakeholders to align business goals with users’ needs, breaking down holistic strategies into feasible milestones. I guide and help other UX designers work on sub-features, ensuring each is separate and modular, yet able to be assembled into a unified platform.
Anything aimed at bonding players on the site is treated as a community feature. All of them are unique selling points that differentiate our site from others. The following diagram roughly shows what is included in community so far.
The disoriented team
When I was assigned to look after the community from a UX perspective, I found the technical team rather disoriented. It was a small team of 2 technical leads, 8 developers, and 2 QAs. With no product owner in place, they had no strategy for what to build or when it was best to build it. Since community was not the only area I was responsible for, I didn’t have the time to pick up all the project details. I flagged this problem to the Chief Product Owner at the time, and my request eventually went through — we finally got a Product Owner for the product.
To start with, the product owner and I identified the main pain points users had and some major bugs that needed fixing. Quickly fixing those issues first not only gave us an instant improvement in overall user experience, but also bought us time to draw up a proper vision for where the product should be heading. We documented the urgent issues and jointly presented them to the board, since we needed the business’s consensus. For a quarter, we focused on dealing with those niggling issues.
Setting up quantified goals for intangibles
Meanwhile, we thought it would be better to define a set of measurable Key Performance Indicators (KPIs) so we could track our progress going forward. This was a difficult task, mainly because we had no objective figures representing the value and impact of the community features — it’s hard to isolate their impact on revenue. So we weighed a set of options and eventually settled on sentiment measurement.
Widely used in social media, sentiment analysis seemed like a good way to quantify users’ general opinions of our chat rooms. It might not be the best engagement metric yet, but we’re hoping to start tracking positive and negative attitudes toward our community, and over time gain more insight to support future development.
On which features to build first
Once we had clear goals, we could move on to figuring out what to build to achieve them. We arranged a brainstorming day out, inviting all stakeholders to a location well away from the office. An unusual setting helps participants step outside their routine, distractions, and comfort zone, making them more likely to think outside the box and stay open to new ideas.
For the day out preparation, I documented all the ideas previously gathered from stakeholders and the backlog. Visualising 70 ideas as rough wireframes helped participants picture the concepts, and printing the ideas out proved useful — it ensured every small detail got discussed and kept the conversation focused on the agenda. By the end of the day, everyone had three stickers to vote for the ideas they thought we should focus on over the next few quarters. Sticker voting seemed democratic and efficient, but after trying it, I wondered whether the selected ideas were really the best fit for the product strategy. I later came across an article suggesting that sticker voting isn’t necessarily the best tool for feature prioritization, since the results can be skewed by confirmation bias and irrational tendencies — people may vote for whatever is easy to build rather than what’s best long-term. I learnt that sticker voting works best when voters are asked to explain why certain features matter; used that way, it becomes a tool for understanding stakeholders’ rationale rather than a decision-maker on its own. The ideas still need plenty of validation to forecast their impact.
Moving parts
There are a lot of dependencies on other teams. Our video and chat games need to be loaded by the game studio or wrapper team, so a good understanding of how the technical layers are structured is crucial. Most importantly, good communication with these teams plays a big part in my role — there’s little point building something other teams aren’t ready to load. Good communication, and sometimes even persuasion, helps get features live as soon as possible.
What I learnt
I feel lucky to have had the chance to work with some great seniors on this project. From them I learnt a lot about business strategy and advanced time management, and how to get things done in a large corporation. But specific to UX, the key lessons were:
1.Tools like sticky votes and Gantt charts are well known and widely used, but they may have been designed for very different situations or problems. When applying them to our own case, we should always check whether they actually add value to the process.
2.There’s always a struggle between choosing a custom UI and using well-known patterns. In these situations, I’ve learnt to drop the designer ego and the fear of being seen as a copycat — it’s often right to use an established design pattern instead of reinventing the wheel, since it helps meet users’ expectations.
3.Communication between teams is key in a large corporation. Find ways to simplify complicated situations so everyone is on the same page — it improves efficiency.