Roadmunk is a web-based application built for product managers to be able to quickly and efficiently create roadmaps for their company. At a high level, a roadmap defines the strategic plan and goals for the organization. The roadmap is a document that can help achieve alignment among various stakeholders, both internal and external to the company, as well as indicate what projects must be completed and which milestones met in order for a business to meet its objectives.

My recent internship at Roadmunk had me designing the company’s most challenging and highly-requested feature: creating a two-way integration between Roadmunk and JIRA, such that data flows easily between the two systems in an intuitive way.

Note: This is quite the long post, but details the process I follow on large, extensive projects such as this one.

What’s the Problem?

The process of roadmapping is not isolated in a product manager’s workflow, and a roadmap is not a static document. Priorities and timelines change, and unexpected problems occur that must be fixed before other work can continue. Such changes would be documented in a tactical tool, where engineers are frequently updating tickets assigned to them. These changes should bubble up to the roadmap level so that product managers and executives are aware of the changes.

At the moment, however, Roadmunk is poorly integrated with other tools, and data on a roadmap is not connected to data in other systems. This results in the product manager having to take the data from one system and manually import or update it in Roadmunk whenever a change is made elsewhere. The product manager is thus undertaking a massive amount of work to keep Roadmunk and another system in sync, especially when small changes occur very regularly.


The goal of a two-way integration with JIRA is to ensure that the two systems are kept in sync without manual work, so that stakeholders involved with either system always have up-to-date information with minimal data loss and errors.


I acted as the only product designer on this project, working alongside a Technical Product Manager and a developer to understand what was technically possible with this integration, and how technical architecture design would affect the user experience. I communicated with the CEO, CTO, and Head of Sales throughout the process, as this project was of high value to the company and one that everyone wanted to see succeed. When my internship at Roadmunk was complete, I passed the project to a fellow designer.


This project required a variety of work to complete, and involved collaboration with several departments within the company. As it stands, this project has yet to be released to the market, and as such, many of the artifacts produced as part of this project remain confidential to Roadmunk.

1. User Research

Before I began this project, I heard a number of descriptions from co-workers about how different companies use Roadmunk and JIRA, and how they expect them to work together. It seemed that everyone expected the system to work differently. From this, it became clear that I would need to speak to customers and conduct user research to determine how the system should be built.

To begin this process, I read through all tickets related to JIRA that have been filed in Roadmunk’s customer support system (Intercom), over the past two years. This gave me a broad overview of where people are currently experiencing frustration, and gave me some visibility into the types of features customers are requesting. Reading these tickets also made me realize that the lack of this integration resulted in people choosing a competitor over Roadmunk.

I gathered a list of customers who had made requests of complaints related to JIRA, and contacted them, asking if they would be interested in participating in an interview aimed at better understanding how they use JIRA. I composed a set of questions aimed at trying to understand their mental model of JIRA, Roadmunk and how data should flow between the two systems. I interviewed users at companies of various sizes, and through this, realized that organizations, particularly when different in size, use the two systems very differently. The integration would need to be able to accommodate this.

2. Competitive Analysis

My next step was to complete a competitive analysis of 2-way JIRA integrations included in other similar products on the market. Five competitor products were examined and tested against eight criteria to attempt to understand how each system works, why it was designed in such a way to meet a user need, as well as any pain points experienced throughout the process. After using each of the products, a set of overall takeaways and an understanding of how the market is currently attempting to solve the problem was documented, to be acted upon in the design stage.

3. Synthesizing All the Information

This part of the project is where I invested significant time trying to understand how JIRA works and how to best integrate it with Roadmunk, as well as developing a high-level user flows to help guide future designs. A lot of this work was handwritten, as I find that writing on a notepad helps my thoughts flow, and that putting all this information into diagrams and sentences helps me convey my message.

I started by differentiating between the types of users in Roadmunk (admins, collaborators who can edit, and reviewers who have view-only permission), and the different abilities and permissions they should have when it comes to interacting with JIRA functionality. This allowed me to identify what level of permission should be enabled for each user, and also prompted me to think about what errors might occur as a result of limiting permissions and functionality by user type. All of these errors would need to be addressed in the final design of the integration.

Roadmunk JIRA Different Users and their Permissions

Prior to this project, Roadmunk had an “Import from JIRA” feature, in which issues could be pulled from JIRA into Roadmunk manually. This was termed the “1-way integration”. For some of the organizations I spoke to, the existing 1-way import served their major use cases (though they were looking for automatic rather than manual syncing). As such, it was important to maintain (and enhance) existing functionality, in addition to the new 2-way integration. I compiled a list of functionality that should be available in each, which helped highlight differences between the two features. Below is my initial iteration of the features to be included in each. This evolved over the course of the project, but I maintained and updated a similar table in order to distinguish the two – the Sales team loved this, as it allowed them to better understand how they will sell the two features based on customer needs.

Roadmunk JIRA Differences between 1 and 2-way Integrations

Next, I spent time thinking about all the various ways that an integration with JIRA might be able to be modified after the initial setup, and the repercussions of each of these modifications. There are many, many ways that changes can occur, and at different points in the integration, such as at the integration configuration stage, the integration import/sync, or even deleting the integration.

Roadmunk JIRA Potential Modifications

I then spent extensive time researching the numerous errors that can result from integrating with JIRA, from the perspective of the various types of users and the modifications they are able to make. This was invaluable work, as it provided me with an understanding of where I would need to design for errors, as well as better communicate with the development team about how each of the errors can be handled from a technical perspective. My research into errors was one aspect of this project that was highly applauded by the CEO and CTO, and something that I believe will help the Roadmunk-JIRA integration stand above its competitors.

Finally, with all this information, I devised flow charts to indicate how a user might move through and navigate the integration. Given that admins and collaborators had different levels of permission (and different expectations from a setup perspective), I created flows for both types of user. These documents helped enormously when it came time to create mockups, as it provided me with a clear indications of which screens would need design work, and allowed me to quickly create the interactive prototype.

First, the admin flows. These include both an integration setup portion (first page), in which the admin creates a link between Roadmunk and JIRA, and is a precursor to being able to select, import and sync issues, which is displayed in the second page below. (TV = Table View, TL = Timeline – two different visualizations of data within the Roadmunk app)

Roadmunk JIRA Admin Setup Flow Roadmunk JIRA Admin Setup Flow

Second, the collaborator flow. This details how an editor is able to import/sync items and use JIRA issues on a roadmap.

Roadmunk JIRA Admin Setup Flow

4. Mockup Stage

With the information from my previous work, I composed a “Comprehensive Summary” of JIRA as it relates to Roadmunk, and began working with a technical project manager to move forward to designing flows and screens. Based on different system architectures, a set of wireframes were drawn up to demonstrate the implications of such architectures on the user. Once a final architecture was selected by the technical team, I took the wireframes and elevated them to high-fidelity mockups that were stitched into a prototype using InVision.

Using the prototype, customers were shown the proposed flows for integrating JIRA and Roadmunk, with the purpose of gathering feedback and iterating on the design to eliminate usability issues. Comments were generally positive, and people had little difficulty determining how to progress through a flow. Changes were made in response to the feedback, and this feature is now in development.

Final Flow Mockups

The following PDFs display the final mockups I generated as part of this process. The individual screens displayed were linked into an interactive prototype using InVision to show customers for feedback, as well as for better communication with the developers on this project.

The JIRA Instance Setup requires an admin on the account to create a connection between Roadmunk and the company’s particular JIRA server. After much debate and significant exploration, I determined that although requiring that a JIRA admin create the integration could cause some friction, as those without admin privileges would need to wait for this setup to be completed. However, the flexibility and increased customization of an integration made possible by having were worth the tradeoff. View JIRA Instance Setup Flow →

Roadmunk JIRA Instance Setup

Once an admin has established the connection between Roadmunk and JIRA, all users in the Roadmunk account are able to import JIRA issues, stories, epics, etc. into Roadmunk, using the Roadmap Setup flow. This is the stage at which data is actually synced between the systems, and it was important to indicate to the user how many issues are being imported, and to provide the ability to select whether they want automatic updates, or more control over when issues are updated between the systems. View JIRA Roadmap Setup →

Roadmunk JIRA Roadmap Setup

Responding to Support Tickets

Throughout this process, I was able to develop a very good understanding of the types of problems users were likely to encounter with the existing 1-way JIRA integration – I became the JIRA + Roadmunk expert! I put this knowledge to good use by responding to a variety of JIRA-related support tickets and user questions, and this effort was greatly appreciated by the Support team.