Audio & Video Submission Site
web app redesign
web app redesign
For years, The Journal of Bone & Joint Surgery (JBJS) used a bespoke web application, called the Video Submission Site (or VSS), for their authors to submit video content related to scientific articles. This application was 10 years old and needed updating. The new web app, the Audio & Video Submission Site (or AVS), brings a modern design, a more user-friendly interface, and time-saving automation.
1 advisor, 1 product manager (me), 1 freelance web developer, and 7 stakeholders from the Editorial and Production departments.
I served as the project lead, conducting user research, and defining the problems to be solved. I drafted solutions, and delineated the project requirements. I directed the freelance web developer in building the site, and led a small team of internal stakeholders in testing the product.
We had a budget for the freelance developer, but not for any research or testing with external users. All the internal users testing the web app also had to manage their own regular workloads.
January – August 2023
I was not involved with video production work, so while it was great to be able to step in with fresh eyes, I also had to familiarize myself with a web app and workflows that were new to me. Therefore, it was important to interview each of my colleagues from the Editorial and Production teams that interacted with video. A long list of problems emerged.
The Video Submission Site (VSS) uses a “playlist ID” for access rather than a login process, which means the data is unprotected.
Authors have trouble with the “playlist ID” user interface (UI).
They lose their IDs, or create a new submission instead of updating an existing one.
Editorial Assistants often have to look up the playlist ID for the author, or end up doing the upload for them.
The historical process has a lot of work done outside the VSS, with a lot of moving parts and multiple files.
Lots of manual data entry, work, and email routing, means room for error.
The VSS cannot handle files larger than 1 GB.
Video metadata entered into the VSS doesn't feed into our video repository, Brightcove, along with the videos, and needs to be added by staff later.
I requested a document containing the complete video workflows for each of our products from the managers of the Editorial and Production teams, which I then translated into an Excel file so I could compare each workflow and map out the common steps, since we'd need to build a one-size-fits-all solution. I then went through the combined workflows, asking for clarification as needed, streamlining as much as possible, removing some steps, and editing others for an updated system.
Based on the problems uncovered during interviews, and my analysis of the workflows, I planned out the key features of a new web app that could replace the VSS.
A login portal to replace the playlist ID, which would also protect our data
3-step system
1. Users (authors) upload video
2. JBJS staff (admins) can edit metadata within the system
3. Deliver/recommit a final version of videos and metadata to Brightcove
Metadata
Collect more metadata from the authors, which will enhance search engine optimization (SEO) on our site once the videos are published
Video titles, playlists, and reference IDs should be updated to JBJS naming conventions automatically, eliminating the need for manual entry and reducing opportunities for user error
Metadata delivers to BC automatically
I wrote up a detailed Product Requirements Document, which was approved by my manager, who was serving as advisor on the project.
I presented the plan in a meeting with the internal stakeholders and the web developer who had built the original VSS 10 years previously, who still did freelance work for JBJS. He submitted a Statement of Work (SOW), and my manager approved it. And just like that, our project, which we called VSS 2.0, was funded and underway!
Around the same time that I was doing the research for VSS 2.0, our Editor-in-Chief was thinking about launching a new audio product, inspired by StoryCorps. OrthoCorps would feature orthopaedic surgeons either solo or in interviews, talking about their lives and experiences.
Just as we were beginning to work on VSS 2.0, we got word that OrthoCorps would be moving forward, and it would need a submission system. Also, the Editor-in-Chief wanted the site to be ready in time for a conference in April.
In discussion with our developer, we agreed we could use the same infrastructure we were planning for VSS 2.0, along with a few tweaks. He thought he could do it within the same amount of time allotted by the original SOW, so the budget did not expand.
And so, the VSS 2.0 project became AVS project – the Audio & Video Submission Site.
Given the change in scope, and OrthoCorps' deadline, my team first began working on the OrthoCorps submission half of the AVS site. I had drawn some very rough mockups to convey the idea of what I wanted, and our developer took it from there to design the site.
We met with our developer weekly, and he updated us on his progress. We discussed questions that arose and gave feedback.
When he had a test site set up, the team and I tested rigorously, looking for bugs, but also carefully checking the user flow for our authors who would be submitting content, and JBJS staff who would be doing admin work.
The OrthoCorps portion of the AVS site launched in April 2023, in time for the conference. Here are some highlights:
With OrthoCorps complete, we turned our attention to the site's original intended purpose, video related to article submissions. The building process was the same: meetings, feedback, testing, etc.
The Article-related video portion of the AVS site launched in August 2023. Here are some highlights:
JBJS staff have admin privileges, which give them access to additional features on the site.
I thought my part would be done after the site was complete, but it turned out to be harder to transition everyone to the new system than I had anticipated. JBJS has a lot of employees that have been at the company for over 10 years, many were uncomfortable with new technology, and it was hard to get used to a new system.
In collaboration with the Editorial team managers, I drafted careful transition notes of how their workflows would change, detailed by each product. I also made a video documenting each step of the workflow, and let everyone know I would be delighted to help anyone who needed it.
Immediately after launch, an Editorial Assistant noticed that the links generated by AVS opened the submission in AVS, rather than just the video. Given that JBJS's journals conduct strict double-blind peer review, it was not good for reviewers to be able to see all authors' names. I contacted our developer immediately, and he was able to fix it quickly so that the peer review links opened the video only.
We had about a month and a half of overlap time before we decommissioned the old VSS site, which my manager was eager to do, as it was the only thing we were still hosting (and paying for) on Rackspace. But when the old site was gone, all the video links to it for older content still undergoing peer review stopped working. I asked our publisher for a list of outstanding video content, and got the team to quickly generate new links and replace them in the peer review portal.
“Isabella ran this development effort as the leader of a cross functional team. She coordinated JBJS personnel within Editorial and Production as well as outside technical vendors. She is an effective leader and kept the team on track and on pretty much on budget. Isabella received very positive feedback from members of the team as well." – my manager
Change is hard, especially when people have been doing the same work using the same systems day to day for many years. It's important to be patient and non-judgmental, and ultimately they will come to appreciate everything the new system offers them.
It's impossible to foresee everything that could possibly go wrong, but as a perfectionist, it's also hard to accept that. The important thing is to acknowledge it, and be able to react quickly without blaming yourself.
It can be hard to get people to do their part when testing products. Everyone has their own regular work that needs to get done, and everyone thinks that there are enough other people testing that one individual hardly matters. But numbers count when it comes to bug testing. My manager shared that in the past he'd offered a small prize (for instance, a gift card) to the person who found the most bugs. I really like this idea, and I think I'd do that next time.
When the scope of my project expanded unexpectedly to include OrthoCorps, the budget did not expand. Because of this, and the fact that we built the OrthoCorps portion first, when we started getting close to the budget ceiling, we had to scrap plans for a few features that the team wanted. In retrospect, I should have cited Parkinson's Law – work expands to fill the time (and budget) available for its completion – and requested an increased budget.
As of January 2024, the new AVS site has been live for 4 months. However, the glacial pace of peer review being what it is, I would wait til it has been in use for around a year, and then do some more user interviews with staff, to see what's working well, and what could be improved. Then we could work on some site enhancements, in addition to the few features that we had to skip in the first release due to budget constraints.