I recently completed an internship at Roadmunk, in which I acted as the lead product designer, owning the user experience and helping define the future of the product. It has been an incredible opportunity to take on the responsibility of laying the foundation for building a strong design team, and I have the superb team at Roadmunk to thank for helping me make it a successful undertaking and a rewarding experience.

While there, I produced a large volume of wireframes, mockups and prototypes to help push out features for a major project that will be released in a couple weeks (stay tuned!). I also helped create and implement a process for documenting design decisions to make them readily accessible for all stakeholders. This was in an attempt to improve clarity into reasoning, and to show what other options were considered before a final design was selected for any given number of reasons.

One of my major tasks at Roadmunk was to develop the information architecture that will define the future of the application as the organization grows to serve enterprise clients.

What is Roadmunk?

Roadmunk is a web-based application for product managers, allowing them to quickly create visualizations for their product’s roadmap. Roadmunk currently has clients ranging in size from single product managers within smaller organizations, all the way to enterprise clients with upwards of 200 product managers currently using the software.

Current Pains

Roadmunk is, at present, best-suited to serve small-to-medium-sized product teams. Like many SaaS applications, each person on a team has an account, which belongs to a digital team, all within an organization. Resources within the company’s account are available to be shared, at the discretion of their respective owners. All resources, in this case roadmaps, live at one level of hierarchy and are differentiated by name. For smaller teams, this works just fine – when someone joins the team, or needs access to a resource, the owner can manually locate it and share it. This, however, does not scale to enterprise-level accounts, where hierarchy prevails both in terms of the structure of the organization and a need for files in a system to mimic this hierarchy in order for files to be found without difficulty, and for permissions to be easily assigned.

The product team came to the conclusion that a folder structure would be necessary for organizational purposes, and the repercussions on all other aspects of the product had to be examined.

Goal

The goal of this project was to look at all major features, both existing and planned, and determine how implementation of a folder structure would impact their functionality and usability, and as a result, make recommendations for future direction of the product, and ensure that shorter-term development efforts are aligned.

Tools Used

  • Whiteboard, pen & paper for communication
  • Sketch, for making higher fidelity wireframes

Understanding Clients’ Organizations

To begin this project, I spent time investigating how existing enterprise clients structure their product teams in an effort to understand what a “typical” product team might be. I sat in on calls with the sales team, and spoke at length with our head of Product about her understanding of the structure of client companies. Through this research, I determined that the majority of teams using Roadmunk fit into the organizational structure pictured below. The product team is divided by department, and within the department, there exist several teams, typically responsible for a product or product line depending on the size of the organization. Each product team is responsible for maintaining at least one product roadmap (RM). I printed this chart in large format and brought it to meetings, where it really helped keep everyone on the same page, and allow us to provide very concrete examples for what might otherwise be difficult to explain.

Client Org Structure

With this organizational structure in hand, I moved onto trying to explore the implications of a folder structure to organize roadmaps and other resources within Roadmunk.

Proposing a Folder Structure

Developing a folder structure does not seem overly complicated from the outside; however Roadmunk is built on the principle that elements of one roadmap can be shared with many others, which creates a chain of dependencies that becomes even more complicated when permission systems are involved. To begin, I made the wireframe below, which shows several layers of folders, and files within them. This wireframe was not intended to convey anything in terms of the UI, but rather to make concrete what would otherwise be very abstract. In the image below, there is a company level folder, in which all the company’s resources would live, and the structure branches from there. Within each of the folders, there is a set of milestones, typically important dates that the team, department or company are adhering to, and a master, which is a rollup or aggregate of smaller roadmaps into one larger one.

Folder Structure with Roadmaps

At each level, there is likely a manager in charge of aligning the teams or departments beneath, and as such, this person should be able to control and access all of the resources within the folder he or she manages. However, there could arise certain situations where the manager makes a change to an item on the aggregate, master roadmap, but does not understand that this will have repercussions at lower levels.

The main challenge comes in that the power of Roadmunk is the ability to freely manipulate items on a roadmap to achieve a desired visualization, as well as remaining aware that changes made in one location might have far-reaching impacts elsewhere in the software, and thus affect others in the organization. It is a matter of balancing the right level of permission such that a manager can align his or her team, but still give the autonomy to team leads to execute more low-level planning that ultimately leads to an overarching goal.

To solve this problem, we determined that a good path forward would be to start by providing the lowest level of permission to a user, based on what team they work on. In addition to this, the creation of a hierarchical structure within Roadmunk would likely be necessary in order to easily assign permission to a user, by essentially “dropping” them into their corresponding position on the organizational chart. The majority of users would be able to complete their work with no issue when given access to the resources in their team’s folder. In the event that users require information from further up the tree, they would be to request access to a given resource, and the owner of that folder or particular resource could grant access (either read-only or edit permission).

With this in hand, the next step was to develop a basic UI for how a user might interact with folders, and access resources within them. Roadmunk does not currently have a simple way for a user to see all roadmaps they own, all that are shared with them, or roadmaps that were recently viewed. We decided to combine all of these elements into a feature called “Home”. I began by sketching some possible options for a homepage, displayed in the image below.

Home Sketches

The homepage also allows for actions such as quick sharing, renaming and deleting of a roadmap; to perform these actions today, a user must load up each roadmap to select the settings, and this has caused some frustration on the part of users. I took my sketches and converted them to a higher fidelity mockup in list view.

Home Higher Fidelity

We took the wireframes I developed to clients and asked how they might use the software differently if they were able to organize resources into folders, and the response was overwhelmingly positive. Users were excited to see changes and a new UI, and the consensus was that with a better way to organize within Roadmunk, the number of product managers using the software within their organization would increase.