Manga Rock CMS 2.0


For Manga Rock’s content executives who need to ensure the quality of its catalog of 20,000+ fan-based and upcoming legitimate titles, Manga Rock CMS 2.0 is the next iteration of the content management system that allows them to effectively onboard, manage, and sell their content.

Unlike the first version, the second version features a user-friendly interface and tighter workflows to ensure that quality is maintained throughout the publishing process.

My Contribution

Product Strategy
Concepts & Ideation
Information Architecture
Enterprise UI/UX Design


1 designer
1 product manager



History of Manga Rock CMS

Up until December of 2016, Manga Rock had been just an aggregator, pulling manga from more than 20 different sources all over the internet, across multiple languages. It focused on the mobile reading experience and the convenience of switching between sources. In essence, it was categorized as a utility or a tool.

Also, from a maker’s POV, we did not want to just keep operating in an illegitimate way, stealing content, or being a part of the stealing process. We knew that it was harmful to the creators, to the industry, and was just plain wrong.

So, in 2017, we decided to tackle the discovery part, first by introducing our own source and improved the discovery experience of our users. That was how Sapporo started. Sapporo included a new discover tab, new color scheme, collections, better source picking… and a new official Manga Rock source, as well as a Manga Rock web app.

Case Study: Manga Rock iOS 4.0 & Android 3.0

How we improved the content availability and accessibility of Manga Rock app through project Sapporo.

We were pretty new to the business of managing content by ourselves. Thus, we hit a couple of obstacles during our two-year effort to stock up content for Manga Rock source.

First, we attempted to hire an outsource company to do data inputting for more than 16,000 manga titles, using our internal CMS. When we received their work, it was a complete mess, so we paid them one more time to go in and fix their mistakes, and everything still ended in a mess.

Therefore, we gave up on relying on external help and attempted to build our own in-house content team. We struggled a lot through the process of managing all this content while figuring out the way to fetch the latest chapters in the quickest way. It was very hectic, a lot of experiments were taken on CMS, hacks were implemented, the system is a tangled mess, no one was confident enough to jump in to fix it.

During our struggle, the biggest problem was that when there’s a problem, there was no way to pinpoint who was responsible for the problem and whether the considerable cost that we were paying for all the freelancers to maintain CMS was worth it or not? Work was delegated verbally, relied heavily on human-to-human communication and interaction. There was hardly any permission control, everyone had admin rights. The whole thing was messy, and on top of that, nothing was documented. The Issue System turned into a task delegation system, where tasks would come in and got done by whoever was present at the shift, and accountability went down the drain.

In one last-ditch effort, we tried to integrate CMS with Jira, introduced changelog, licenses, and sourcing,… with the hope of wrangling control back to the top-level person.

Although the Manga Rock CMS was a mess at the time, without it, we could not have arrived at this moment.

Shift Focus to Selling Content

We discovered that if we were to remain as a fan-based content aggregator, there was a ceiling to the amount of value that we can deliver to the readers. If we want our readers to truly have an amazing reading experience, and be able to access all the titles they want to read, we really need to acquire legitimate content.

However, legitimate content does not come cheap, so we needed a way to sustain ourselves while delivering them to our users. It was the only way forward. The problem was, how can we make users pay, when they don’t want to? The answer was no, they would not, not in our current state.

The challenge is: How can we make a piece of content worth paying for? How can we make it so that users don’t think that they have to pay for it, but actually want to pay for it? And it was not about being deceptive or greedy, because what we want was the best for the users.

What we wanted was to be able to sell legitimate content in an effective way. And to sell content, what do we need? We need to make it desirable. We agreed that we need to focus on the quality and attractiveness of the content instead of quantity and speed. We needed to make the readers fall in love with the content at the first sight. The current CMS could not do that.

To effectively sell content, we needed to dedicate yourselves to the title, really understand it as well as the people you’re trying to sell it to, only then can you sell it to the end-users. The current CMS operated in shifts and tasks, and just getting content out there without any specific agenda in mind. The current CMS did not care about how the content was performing after it is released, what kind of readers read this content, what time is the best to publish a chapter, what type of banner works best with this title’s readers…? Without this knowledge, how can we effectively sell? Here, we looked at more opportunities to serve more users or existing users better:

  • Read manga in multiple languages: some titles may only be available in a particular langauge, some times you may want to read a title in your own native language, some users may not be able to read in English… So having titles in multiple languages will definitely enhances the user’s experience of consuming a content. From a business POV it make sense too, because we can establish early dominance in some untapped markets.
  • Users who already reading fan-based chapters:  Those users may be suffering with bad quality images, bad translations, and would really appreciate the ability to read these title in a nice way. Those are the titles they are reading and love and having a real connection with. They just need a little convincing, and nudging. Latest chapters, quality translation, quality image, faster release really make sense for them. From a business POV, it’s better to start replacing the chapters of already popular titles with legit chapters, rather than new title we don’t know anything about


With all the shortcomings of the current CMS Portal, from its unintuitive interface to the myriads of hacks built on top of previous hacks, we could not expect top-quality content to come from the tools ridden with problems. We also could not afford to keep the system as it is right now and keep adding things more things on top of it. We would risk ending up with a bigger mess for ourselves. It was high time that we pay for our technical debts.

This new CMS was going to serve as the official content management system for MR Comics – a new product with a blend of fan-based and legit content living alongside each other. The strategy was simple: observe which fan-based titles were performing well, and try to acquire the legitimate version of it.

Because of this strategy, each title must now have two different sets of chapters, one fan-based and one legit. Hence, one of the requirements of the new CMS portal was that it must be able to manage both fan-based and legitimate titles at the same time.

In the meantime, we would keep the old CMS running. The new CMS would be developed in parts, in a modular and scalable manner. It would mean:

  • Each feature works well on its own
  • Each feature serves a specific purpose for a specific set of users
  • Each feature can be plugged in and out at will, playing well with other features
  • Each feature can be developed concurrently
  • Each feature can be extended in the future


There are two types of users that we want to cater to:

Content executives

They are people in charge of the content management effort. They need to:

  • Perform data entry and packaging
  • Localize title to another language
  • Publish title to specific audience
  • Run marketing campaign for the content
  • View analytics to see how the content perform

From a management point of view, we can’t simply delegate content to an executive and just let him do what he wants with that piece of content, as long as it generates profits. That’s a naive way of thinking. We need to have a quality control type of mechanism that lets a manager effectively oversee the content production process, and really administer it. It’s different from INKR in the way that INKR is all about managing creators, while CMS is about managing content.


External help that content executives employ to assist them with their daily operation. Because of this, content executives also need a way to collaborate effectively, control their permission and accountability.

Apart from the two above users, there were also:

  • System admin
  • Catalog admin
  • Content editor
  • Content publisher
  • Content reviewer

Use cases

Below is the list of use cases that we want to cater to:

  1. Uploading fan-based titles
  2. Uploading legit titles
  3. Previewing titles in specific devices
  4. Publish titles to specific audience
  5. View title performance report
  6. Publisher check report
  7. Conduct experiments on title packaging
  8. Add new users with specific permission to the system
  9. Keep track of publishers on the system

Feature Groups

Below is the list of proposed features that we want to develop:

  1. Search
  2. Home/Dashboard
  3. Titles
  4. Collections
  5. Publishers
  6. Wiki Pages
  7. Analytics
  8. Campaigns
  9. Experiment
  10. Notifications
  11. Admin Tools
    1. User management
    2. Tags management
    3. Editing guidelines
    4. Catalog management
    5. Announcements
    6. Widget management
  12. Account

Design Proposal

Executed in Sketch and Abstract. Using Material Design for the web.


Due to unexpected legal issues circumstances, Manga Rock had to be closed down and all fan-based content must be removed. We pivoted the strategy and turned our effort towards INKR Backstage.