How to design tools for journalists (and other product management lessons)
Perhaps one day we’ll find the perfect algorithms to stop fake news, but companies like Meedan are developing solutions to bridge that gap.
My product management apprenticeship at Meedan, a local social software company headquartered in San Francisco, recently ended in a blur of UX designs, market research, presentations and a touch of holiday festivities. On top of getting the opportunity to work with an eclectic, mission-driven global team, I got to participate in tackling challenges such as training machine-learning modules to determine information credibility (i.e. identifying some common forms of misinformation with AI), developing a business model for a recently acquired product, and conceptualizing, sketching out and designing features for a new technology tool.
Working with Meedan’s flagship software Check, my key lesson was that debunking “fake news” has no easy solution. Many people, myself included, have assumed content distributors and platforms have the technology to detect and block false articles and social media posts, but recent political controversies in the United States have demonstrated the opposite. In fact, news verification remains manual and labor-intensive.
Perhaps one day we will figure out the perfect algorithms to stop misinformation in its tracks. In the meantime, companies like Meedan are developing solutions to bridge that gap. Meedan harnesses good old reporting and fact-checking skills, offering its flagship software Check as a workbench for journalists and human rights activists to collaborate online to investigate media reports.
During my time at Meedan, I designed the user experience (UX) for a key component of an upcoming new tech feature. The new Task Pack builder will allow editors and Check team leaders to craft a template of questions that would be asked for all items in a given project. In other words, when an editor assigns reporters to investigate an item, such as something a politician said during an election run-up or a tweet that needs fact checking, the editor can plug in the same questions for every item in the project, thus saving time and boosting productivity.
I learned a few lessons during this process, both technical and practical. Here were my key takeaways:
There are an infinite number of ways I might reimagine the way Check is designed, but product development is a progression limited by the constraints of time and coding hands. There is a high cost of reinventing the wheel or building out features that might not catch on.
In reaching that compromise, consider the viability, desirability and feasibility of it.
The Meedan team does that with impact-effort matrices, which measure the cost-benefit and necessity of any product development.
Some high-effort tasks such as fixing bugs cannot be avoided. But the more substantial the effort, such as developing new products, the more it pays off to ideate and iterate to avoid those high-cost fixes.
I shared with my peers at Medill’s media innovation and entrepreneurship program the process of how I designed this new Task Pack tool. These lessons can be applied to product design for any software feature.
How to design a product feature
The product development process is defined by designing the strategy, the interactions, and the actual interface. After the initial strategy was defined by the Meedan team, I got to work on ideating and prototyping the tool using a range of accessible tools including Sketch, InVision, Balsamiq, and a good old whiteboard.
Step 1: Creative brief
Time needed: ½ day + feedback and iteration
Materials: Google Docs
Once we decided to pursue the development of the Task Pack, the first step is putting thoughts into words. In a creative brief, the objective is to describe the scenario of how the user would interact with this tool. Most importantly, it is a space to explain “why” we want to design certain features and how they solve a user’s problems.
The benefit of a creative brief is that it’s easy to write up, share, get feedback, and iterate before putting too much sweat into it. All you need is Google Docs. But because everyone reads and visualizes differently, there might be misunderstandings. The next steps help to create a concrete picture of how the product will work.
Step 2: Task flow (user flow)
Time needed: 1 day + feedback and iteration
Materials: whiteboard, pencil and paper, or flow.io
The task flow is the step-by-step storyboard of the user experience. As a product designer, you map out how a user navigates from A to Z in your product experience, forcing you to imagine all the scenarios. It’s like building a Choose Your Own Adventure book, including all the different entry and exit points. It helps you define the wins, the recurring actions, and the number of pages you’ll have to design.
But it’s easy to get lost in all the possibilities, so it’s important to define your project parameters and minimize the number of possible scenarios through careful planning.
For my task flow chart, I whiteboarded a scrappy set of scenarios on Northwestern University SF’s whiteboard wall, spanning 6 feet tall and 10 feet wide. Here are snapshots of my step-by-step process:
Step 3: Wireframe & prototype
Time needed: 2–3 days
Materials: Balsamiq or Sketch (Mac), Material.io, InVision
After the task flow has helped you map out the number of pages and interactions needed, the wireframe process brings the whole front-end experience to life. Tools like InVision or Sketch’s built-in prototyping function allow you to link the pages on the button hot spots to simulate the feature’s basic navigation.
Because Check uses material design (Material.io), the style guide, aka all the buttons, icons and other elements, are well specified by the pros. That lets me focus on designing the experience rather than the minute details of typefaces and proportions.
This is the most labor-intensive part of the ideation process. Designers often let their creativity roam and add more frills — but as you’ll see in the next steps, those are not always possible in the actual build.
I had the advantage of bringing a fresh set of eyes to the software — my perspective as a journalist and editor with newsroom and management experience, particularly in high-pressure, time-sensitive situations — so I designed with the philosophy of helping the editor absorb as much information as possible at once and creating maximum utility with the fewest clicks. This is in slight contrast with Check’s current design, which is simpler on the eye as well as simpler to build.
For the Task Packs, I built the basic functions in a six-page process on Balsamiq for Windows. When I had access to the office’s Mac, I jammed out and converted the wireframes to Sketch artboards — which had a pleasing resemblance to the look and feel of the real software.
Using Sketch’s Craft plugin, one of many useful integrations, I synced the artboards to InVision so others can walk through the product’s flow from their own machines. You can view it here (with an InVision account).
Step 4: Present & defend
Time needed: 20–40 minutes per interview
Materials: screen share on Hangouts/Slack, or record screen-share video on Keynote/QuickTime.
Demo time! With wireframes designed and linked, I could show it to stakeholders. I demonstrated my wireframe walk-through to product managers, developers and potential users to get their feedback.
Real-world feedback is a critical part of the iteration process. Getting more feedback in the beginning reduces the adjustments needed once the product is built, and helps prove the product’s feasibility for developers and desirability to users.
The response was generally positive (and hopefully not just because they were being nice). All interviewees said the design concepts addressed longstanding problems, while addressing relevant concerns.
For example, I proposed that suggested locations be based on the IP address of the person who posted the article, but a product manager brought up the concerns over privacy particularly in sensitive projects like human rights investigations.
Feedback is also an opportunity to assess the three main factors that should be considered in concept development: viability, desirability and feasibility. Will this help Meedan (and its clients) make money and/or be more productive? Do users actually want and need these features?
Developers are generally more conservative about new product designs, as they are the ones who have to write the code. More complexity also runs the risk of reducing stability, so starting with a simpler product, testing it out and building on that success increases durability in the long run.
In a conversation about introducing tags as a feature to help categorize Task Packs to help searchability as well as a tool to help suggest appropriate question tasks for the Task Pack creator, the lead developer questioned the need for such tags considering Check’s limited user base and the fact that we don’t even know how users will respond to the idea. He also brought up that this “magical algorithm” to suggest tags is feasible, but a lot of work for a very small sample set. It might be best, he said, to deploy a minimum viable product and consider the other bells and whistles once the Task Pack concept is adopted and used by Check’s teams.
In a normal scenario, I would continue working with the developer to achieve the right balance between ideal and feasible. But given our time constraints, I left the lofty features on the designs for future consideration and called it a day.
Step 5: Ship to builders
Time needed: 10 minutes
Materials: Export as PNG files in .zip folder.
My part is done — once all the final tweaks were made, I exported the Sketch artboards as a .zip folder of PNG files to the development team. It’s now out of my hands, and the dev team will turn those concepts (at least, a scaled-back version) into reality.
What’s next: Development
The dirty work gets done by Meedan’s loyal crew of developers around the world. In the first half of 2019, Meedan devs will:
- Break down design into individual tickets
- Decide what to keep, toss, iterate on (based on impact, effort and feasibility)
- Prioritize tickets & build in 2019
- Test, iterate & deploy! (Repeat)
The work is never over. Managing a product is an ongoing process, and the Task Packs will be iterated on several times after deployment. Maybe one day, as the product’s usage grows, they will tack on my fancy bells and whistles like category tags and algorithm-based task suggestions.
What product management means for journalism
My indirect takeaway from this experience is that the world of journalism requires many hands — and tech-driven innovation in this industry introduces a wealth of new roles. As the news gets more digital, we must stop believing that the only jobs left in journalism are the ones with bylines.
I am proud of several stories I’ve penned over the years, but the most rewarding accomplishments in my career did not even carry my byline. Bringing a great story idea to life is a collaborative effort that requires not only editors, reporters, photographers and illustrators — today’s great stories are told on interactive platforms where the design and distribution are half the experience.
In journalism, much like many digitally native fields, product management is increasingly crucial for bringing our ideas to life, whether that’s building a story told in VR or creating a tool for journalists to collaborate on news verification. Those who embrace this early have the greatest chances of not only surviving, but thriving.
This article was cross published on Medill School of Journalism’s Media Innovation and Entrepreneurship page on Medium.
