Building a self-publishing platform from the ground up.
In 2015, there were few roadmaps for the many writers interested in self-publishing. There were lots of options, but few ways to navigate them.
As one of these suppliers, PubLaunch’s founder wanted to create a platform that would empower writers with the information and services they needed in one place. The platform would match them with the right (trustworthy) suppliers, generate automated quotes, and manage the project for them.
I joined the team as its very first member, helping to do whatever was needed to get the platform off the ground. I’ll be sharing the lessons that I learned from the project, how my perspectives have changed, and some of the things I think we got right from the start.
Project Lead: copy writing, wireframes, high-fidelity mockups, sitemaps, policy decisions, and whatever else was needed.
September 2015 - June 2019
1 project lead, 1 business development lead, 3 developers
The goal of the project was to build a platform that would serve a self-publishing writer in need of publication services (for example: editing, proofreading, cover design, etc.) as well as freelance publishing suppliers and readers.
Above all, we sought to address the abundance of untrustworthy suppliers and services on the market by testing and verifying each and every supplier on our site.
We had big goals.
The format of this retrospective
I learned a lot over the course of this project, both about what to do and what not to do (most of which was learned the hard way). To demonstrate this, I'm going to discuss the steps and decisions that were made using two examples, in the form of lessons:
Lesson 1: A simple design is more important than one that works for everybody.
Lesson 2: Understand your users.
Finally, I'll talk about what we got right from the start.
Note: All images and samples of work shown in the retrospective were produced either in collaboration with others or by myself.
We wanted to capitalize on the recent closure of a similar site — Pubslush, a crowdfunding platform dedicated to books — and use the associated limelight to jumpstart our audience. Consequently, there was a lot of pressure to get an initial platform out as quickly as possible.
Everyone informing the project had a background in either publishing or business development. To combat our lack of experience in product development, we worked with a contracted firm during the first stages to help guide our decisions and supply the developers during the initial phases.
Most of the project relied on internal funding, so our budget was tight.
Right from the start of the project, we were overly focused on a site plan that would work for everyone and solve every problem, instead of prioritizing an achievable design.
We envisioned a platform that would serve writers, freelance publishing suppliers, and readers alike. Its features would be split into three primary user types: writers, publishing service suppliers, and readers.
Features would include a step-by-step publishing workflow, a book-themed crowdfunding platform, and a service to hire or become a beta reader (a test reader who provides feedback prior to publication).
When we made a first map of all the site's features, we came up with the document below.
As the MVP (minimum viable product), this was trying to accomplish too much. In retrospect, the external pressure made us hasty, leading us to jump into design and development too early.
Unfortunately, we were all so familiar with the industry that we were trying to create a plan that would serve every type of writer and supplier perfectly while also trying to eliminate any and all potential problems. This led to problems as we moved on to designing the workflow.
Creating a workflow
Next, we drilled down further by creating a workflow to describe the individual steps the user would take on the platform. In so doing, we chose to eliminate readers as a user, conceding that it was out of scope for the MVP.
Our primary concern when working towards a site structure was to provide a lot of control, information, and options to writers of all different experience levels. The workflow below was one of our attempts to do that. It includes four separate streams for writers, each with a unique set of predetermined options depending on the type of writer.
From workflow to sitemap
This concept of separated, predetermined workflows was leading to a number of problems:
1. the multifaceted structure was proving hard to explain, leading to many miscommunications with the developers and more errors in the work,
2. the multiple branching paths were complicating development,
3. and the concept was quickly outgrowing our budget.
Our team was also divided on whether providing more options would prove too confusing or whether fewer options would mean serving too few writers.
Eventually, because of the external pressures of time and money, we realized it was getting impractical to stick with this system. So instead, we came up with a workflow that would work best (if not perfectly) for most people: a simple step-by-step process that would allow experienced writers to skip ahead if they knew what they wanted but with detailed enough instructions that the inexperienced writers could have their hands held if they needed it.
The branching paths were combined into one workflow that would be navigable for beginning writers and easily skipped through for the more experienced. In doing so, we were able to streamline the site’s structure into three primary workflows: crowdfunding, publishing, and supplier signup.
Below you'll see the redesigned sitemap based on our changes, followed by wireframes and mockup for the publishing workflow I described above.
The simpler system also allowed me to design the streamlined sitemap above. In turn, when we passed this version on to developers, the communication errors were suddenly solved. The team was able to be up and running within days, with no questions about site structure.
Ultimately, if we had let go of the fear of edge cases at the beginning and prioritized simplicity overall, we might have saved a lot of time.
We repeated similar mistakes with the dashboards. We got caught up in providing as much information and control to the user as possible without taking enough time to think about usability and simplicity.
Some of the information that the dashboard needed to provide included (for both writers and suppliers):
• incoming messages and notifications
• new and ongoing crowdfunding projects
• new and ongoing project estimates
• payment and bank details
The following are early concepts and wireframes for the dashboard designs, organized chronologically from first iteration to last.
Essentially, we had tried to include every feature we thought might be useful instead of thinking deeply about what are users actually needed. The third picture in the series above, with information overflowing the thumbnails, is a good example of an overcomplicated idea.
Our next idea was an attempt at simplification but, as you can see, we (myself included) were still attached to the idea of thumbnails. Not because they were a great design choice but because they were a popular design choice. We hadn't taken the time to think about what would be easiest and simplest for our dashboard.
By this point in the development process, unlike what we'd come up with so far, we needed a design that would be fast to build.
In response to the pressure for an easy-to-build design, I came up with a pared-down layout that I hoped would maximize information while also allowing for easy state changes. It would simply be a map of relevant links to relevant pages that could be greyed out when not applicable.
Instead of relying on thumbnails, this design simply listed out relevant links and grouped them by topic. It was not the prettiest layout, but it was efficient. It also had the benefit of clearly communicating to writers what the next step in the process would be, simply by greying out unaplicable links.
Below you'll see the wireframes, followed by the high-fidelity mockups of the user dashboards.
Our site vision and structure were trying to tackle a lot and it led to a number of problems in communication and development. To combat this, we could have devised a research plan dedicated to investigating our target user and their needs, rather than following our guts alone and letting enthusiasm and excitement take over.
Finding out more about our prospective users would have allowed us to hone in on specific problems. We would have been able to create a set of agreed-on user personas and use them to intelligently plan a paired down site structure that might have been manageable for our tight schedule.
Because we were so familiar with the industry we were also overly familiar with both common and less common problems. Being too aware of edge cases led to us trying to manage every possible scenario through the platform’s design. Unfortunately, this only led to an overly complicated site structure.
Conducting user research and creating user personas would have addressed this issue. Having a clear set of priorities to look to through user personas, alongside data that puts edge cases into perspective, would have helped us stay on track.
When working with tight teams, budgets, and schedules, it’s vitally important to prioritize simple and achievable designs. Attempting to create a design that addresses every user scenario will only end in overcomplicated work that extends the scope of the project beyond what’s possible.
Having so much experience in the industry, plus a full roster of editors in the room who could test our designs at a moment’s notice, meant that we forgot to test the site outside of our tight-knit circle. Since the majority of our users wouldn't be publishing industry insiders, this oversight led to problems later on.
The Launchroom was conceived of as an extension of the user dashboards. Its function was to help writers with the complicated work of project management by making the process as automated as possible. It also provided a space to work with the supplier team and manage the project's files.
The challenge of the Launchroom was to communicate to writers and suppliers both the entire workflow of the project and the current stage of work all at a glance.
Our first idea was to accomplish this through a dynamic flowchart that would include only tasks applicable to the writer's project. We imagined that the writer would be able to move the project along by clicking on the next relevant step, at which point the relevant supplier would be notified.
This made a lot of sense to people in the office, especially since it perfectly represented every step of a publishing process. But when we showed the flowchart to people without a publishing background, they were very confused. They didn’t know what they were looking at and weren’t sure what it was trying to communicate.
Our next idea was a simple checklist that would show only the relevant services.
The checklist wasn't a perfect representation of the typical publishing process the way the flowchart had been, but the itemized list made it easier to follow for inexperienced writers.
Suppliers would be able to see the updated list, but wouldn’t be able to make changes. We also got rid of the idea to notify suppliers, who would now need to check on the project status themselves. We hoped that the site's internal messaging system would make up for the lost feature.
Below you'll see the wireframes, followed by the high-fidelity mockups.
Similar to the Launchroom, when it was time to design the supplier signup process we didn’t think to talk to all the relevant users. This led to a few backtracks and mishaps down the line.
Being led by a veteran of the publishing industry, as well as having easy access to a community of editors, we were very confident in our knowledge of the publishing industry. Unfortunately, we didn’t realize we had a major blind spot for people outside of the editing sphere. This became an issue when we began work on the supplier signup process.
As part of the signup process, we had to create an automated payment system that needed to be able to charge a fixed price for a service before the work starts. This worked easily for editors and cover designers, but it didn't translate to marketers. When it comes to selling marketing services, there's no easy way to predict how long a project will take ahead of time.
Because we had so many publishing professionals in the room, we dangerously assumed that we already knew enough about marketers to provide a solution to this problem. So, in an effort to exert standardized pricing on marketers, we provided a simple checklist for suppliers of the various services they would offer and asked them to supply a fixed price.
Below you'll see a mockup of the payment system for suppliers, which included a simple dropdown menu of possible services.
Unfortunately, we completely underestimated how badly this system would work. As a result, we ended up with a lot of suppliers who either filled out the services with their hourly (not fixed) price or sent us confused emails. It wasn’t really working.
So, we took a step back and realized the mistake. I ended up talking to a few marketers in depth and asked about their charging practices. I ran some ideas by them and came up with the following solution:
Rather than simply select a service and attach a flat fee to it, we allowed marketers to create a custom package. We kept the original list of marketing services, since these corresponded with what writers saw as available marketing services on the site, but turned them into package services along with a description.
We ran this idea by a few marketers in the field, who agreed that it was a good compromise.
In the meantime, we had to hide marketing as a service from the site altogether until we had the resources to spare to fix the process properly. If we had simply realized that we needed to talk to people before creating designs for them, we might have avoided the mishap.
I think the biggest mistake we made was assuming that industry expertise can replace user research. However, I learned from these experiences that no matter how much expertise you have, your user will always know more than you about their experiences.
If I were working on this project today, I would have made sure to involve every supplier type in the design work at every stage of the process. That way, we might have avoided having to rethink features that had already been released.
We conducted informal usability tests without realizing it – showing changes that had been published on a testing site to friends, family, and other colleagues. However, a formal plan for regularly testing ideas would have been even more effective and would likely have avoided both of the mishaps I discussed.
Although being flexible and open to new ideas is an important part of addressing problems, proper preparation through user research and testing can help avoid these problems in the first place. Nothing replaces in depth conversation and testing with the people who will be using your design.
So far, I’ve talked a lot about what I would do differently or how my perspective has changed, but it’s also worth reflecting on what I think we got right.
My design skills improved as I went along, but it meant that by the time I was designing the Launchroom, I was no longer happy with my work on the publishing workflow. However, leaving the designs the way they were allowed us to have users trying them out, which in turn meant that we were able to identify and fix functionality issues we wouldn't have noticed otherwise. Redoing my work would have meant losing the opportunity to get our product into test users' hands.
Reflecting on this decision (and at times, agonizing over it) has allowed me to see the value in prioritizing time for testing over chasing perfect designs.
Many of the people who informed the design of the PubLaunch platform were editors, which meant that everyone understood the importance of semantic structures. From the beginning we were all working towards designs that were structurally consistent to facilitate easy use and development.
We also worked hard to create specific and consistent terminology around the site and its various features, which helped to easily and quickly communicate its purpose to new and prospective users.
PubLaunch was a huge project and it never would have gotten anywhere without our team's ability to stay organized.
We built robust spreadsheets and kept meticulous track of completed tasks and notes. We ensured that, although there was a lot to do, we knew what we had left and were always making progress.
A team of publishing industry professionals inherently understands the value of a second opinion, for everything from some explanatory text to a button placement.
Although we may not have had a formal understanding of usability testing or the importance of testing a product on the right audience, we did welcome feedback when we got it. Being open to these critiques allowed us to catch mistakes and find opportunities for improvement that otherwise would have been missed.
I came to this project with no prior development experience, and many people on the team were in the same position. Missteps were inevitable and I learned a lot about how to design a product from those experiences. I didn’t know exactly what I was getting myself into, but I was eager find out and get my hands dirty along the way.
Ultimately, I think this attitude itself was the key to learning a lot of important lessons, all of which I’ve taken with me to other projects.
I had the amazing opportunity to build something from scratch, with a chance to voice my opinions at every step of the way and the freedom to make mistakes. It was the best possible way to learn.