nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Timeline prototypes - we need your feedback 💬

Hanna_el4c06

Hi everyone 👋🏻

We hear from you how important it is to visualize product plans in a time-based view, which you can communicate to your stakeholders or teams.

We have 2 early ideas that we want to get your feedback on.

We would appreciate it if you could spend ~30 min testing 2 Figma prototypes with simple tasks to complete and leave the feedback and suggestions under this post or reach me directly at hsazonava@atlassian.com.

Option 1
https://www.figma.com/proto/Fksheulxlc3sQFumXrFE9M/Timeline-testing?page-id=31%3A8403&node-id=31%3A16636&viewport=306%2C322%2C0.05&scaling=min-zoom&starting-point-node-id=31%3A16636

Option 2
https://www.figma.com/proto/Fksheulxlc3sQFumXrFE9M/Timeline-testing?page-id=4%3A14274&node-id=33%3A23859&viewport=2290%2C202%2C0.19&scaling=min-zoom&starting-point-node-id=33%3A23859

⏰ No time to click prototypes? No worries, here are 2 screens representing the ideas.

Option 1

Hero 1.png

Option 2

The feedback I'm looking for:

When doing tasks what was unclear in the flow and wouldn't work for you using it in your work? What worked and you'd be using it?
Which option (option 1 or 2, or specific parts of both options) resonates more with you? Why?
What is crucial for you in a such view (which might not be presented in the prototypes)? Why?
Any other feedback and suggestions that you might have 🙂

The prototype has the instructions to follow, and you can always ask questions here or directly.

Thanks in advance for your participation!

Accepted answers

All comments

LAL_i6rck1

I have seen no use for roadmaps/timelines and been wondering why Atlassian is putting so much effort in them? All our project managers ask "Does it have excel functionality?" and thats the end of discussion.

Oriol Fàbregas Pujol

FYI - in my case, Figma links get stuck in the loading page (using Firefox)

Sophie Tessier

For some projects, I need to plan by months (date), Q or by sprints. it's interesting to give flexibility on the timeframe.

Jeremy West_omqybm

Option 2 is probably my preferred, the ability to extend the idea time from the timeline view is much more intuitive and inline with competing product capabilities.

The only thing that would make this feature more valuable is a read-only publicly sharable view/link that can be distributed to interested stakeholders, customers etc.

In saying that, I have no issue with the current roadmap presentation options and probably wouldn't use this view much, as above, a public roadmap is much higher on my list of features.

Sophie Tessier

I agree. Sharing option is a must

Hanna_el4c06

Hi @Oriol Fàbregas Pujol

Sorry to hear it doesn't load. I've checked Firefox and it's loading, but maybe something is on the Figma side.

Could you please try again and if it doesn't work then open the attached images?

Hanna_el4c06

Hi @LAL

Thanks for sharing this! Could you expand on what "excel functionality" they value?

Tanguy Crusson

Hi there, some clarification: we have 2 projects starting at the same time:

Timeline view - which is one of our top requested features - 👉 that's where this post fits 👈
Sharing views with non-Jira users (internal to the company, external) - don't worry we already know people want this, it's the top requested feature 🚀 It is going to take a while to solve though, as it's quite complex technically

In both projects we're starting with a spike to understand what is doable technically and also how we should design them.

We'll start other threads to discuss the "sharing" project when we're ready to seek input from the community!

LAL_i6rck1

@Hanna Its the abdundance of controls/options that excel offers in addition to look and feel theyve grown accustomed to. Our roadmaps/timelines (Release schedules) are usually part of other documentation and since roadmaps/timelines on Atlassian products only serve one purpose (In addition to differing depending on Jira/Confluence and platform) these are seen as cumbersome with no additional benefits compared to tools like excel.

One concrete feature that our project managers insist on is watermarks/background images. Our roadmaps/documentation need sometimes to be plastered with our client's watermarks.

I tried suggesting just exporting roadmaps to images that they could add to any document they desire and edit afterwards but this was rejected outright as too difficult.

Id like them to start using roadmaps/timelines found on any Atlassian product (We use BitBucket/Jira/Confluence), but i havent figured out any selling point for these. We cannot allow our clients to access our systems and all delivered documentation needs 3 signatures (Release schedules included) which means basic image export is not sufficient on its own.

David_ij6mqo

Is the idea of a timeline specific to the product discovery? What I mean is, when a timeline is set, does it represent the time spent during discovery, or is it meant to reflect the time up to delivery? Part of the reason I ask is because I'm not sure if there is a discovery roadmap/timeline that is separate from our development roadmap/timeline. These change so often for us that trying to keep them up to date is a chore so I wouldn't want to have to manage multiple timeline/roadmaps or create confusion about what each represents.

Based on what I'm seeing right now, I'm not sure I would use these feature. My struggles with product discovery are in organizing, reviewing and prioritizing many ideas. At this stage, I don't have a concept of a timeframe. I'm simply trying to go through the ideas, weed out the bad, add more information to the good ones in hopes of figuring out which ideas we should move forward with.

Hanna_el4c06

Thanks for this context!

We also plan to allow for:

Sharing views with non-Jira users (internal to the company, external), hopefully, it will help you with sharing it with clients without them accessing the system.

The case with signatures is a unique one. In your company are Project Managers responsible for building roadmaps?

Andrej Freeze greenique

I can absolutely relate and agree to this. When it comes to ideas, I need a pool to collect them, which would be Jira Product Discovery. Finetuning that idea, getting some additional information and finding out "hey this is actually a product worth developing" is something i have never had to put on a timeline.

I'm afraid that the more features like this are coming, the more duplicates will be exist compared to other Jira Editions. E.g. Subtasks to track what's left to do in an idea, or to split responsibilities, iterations that they can be planned to for better timelines and timeboxes that they will be put into to plan ahead how we want to improve the idea.

This makes it very difficult for me to understand, why I should not simply use a Jira Software Project for Ideas and add calculated fields to it, that are displayed nicely.

Paul Newell_cjeqab

I think it would be helpful to have it more clearly defined in the original post what the AC differences where for these two prototypes, to me the feel really similar and I am not sure exactly what I am looking for.

A few notes:

Dynamic groupings is a great idea, if/when this timeline view becomes sharable we would likely need to be able to preselect this so that external users see it in a certain way
Agreed that dragging the Idea directly on the timeline is the better experience, but I always prefer having both options in cases where I want to be more exact I might prefer to manually enter the start end
Customizing whether the timeline Y axis is quarter, year, month is tablestakes IMO

Dave Perini

I shared some thoughts on the purpose of a timeline view in Tanguy's thread, but here's my feedback on your prototypes! Thanks for sharing with us.

I like how easy it is to add a timeline view from the sidebar, add ideas, and drag idea card edges to increase/decrease their length. I agree with Paul Newell's point that having both precise and loose controls to set length is valuable.
It was easier for me to immediately understand prototype 1 because it defaulted to a common time scale that was easy to change (e.g. weeks vs. months vs. quarters). I was initially confused in prototype 2 with choosing a field to base the timeline upon, but I did like the flexibility that provides once I understood the concept. Maybe you could prompt users to choose between time-based or custom field during creation?
I like how easy it is to create groupings and can certainly see using them to represent different workstreams.

Dave Perini

I like this set of visualization tools better than Jira's existing roadmap functionality, but agree that I wouldn't want two separate roadmaps within the same ecosystem.

It raises a good question about Product Discovery's market position: is it intended only to address capturing and evaluating ideas ahead of their development, or a product manager's toolkit throughout the product lifecycle?

I've been using it more as the latter, and use the Delivery links to monitor and report on the delivery progress of ideas well after they have been planned and passed to the engineering team for implementation.

Jonathan Hau_z7minn

Perhaps it's because I've spent 50+ hours in a competitor tool called ProductBoard that I find the similarity to these prototypes oddly familiar and easy to use.

When doing tasks what was unclear in the flow and wouldn't work for you using it in your work? What worked and you'd be using it?

All of the tasks felt easy to use and familiar. I will likely use both options 1 and 2 for different purposes. I'd use "Group by Team" for example to let my own team within a domain (group of teams) see cross functional work in parallel across multiple quarters. While, using option 2 "Based on" for the purpose of doing more granular (segmented) work.

Which option (option 1 or 2, or specific parts of both options) resonates more with you? Why?

Given the nature that work efforts / initiatives at my company often span more than 1 quarter, Option 1 feels more valuable to me. The challenge with either of these views is what is represented by the bars? Does it represent when work begins? or when discovery / investigation begins? Does it represent when it's done / code complete / marketing has completed announcing it to the world?

To me, these are always high-level estimations, which always mean there are caveats.

What is crucial for you in a such view (which might not be presented in the prototypes)? Why?

What is crucial is adding notes, asterisks, and/or other nuances (disclaimers, safe harbour act, etc). These visual roadmaps almost always means sales / customers will come back to us and say, "you committed to this, why isn't it delivered yet". So, we want to ensure we communicate that these are estimations that don't account for unpredictability in delivery.

Any other feedback and suggestions that you might have

Context is crucial when viewing any roadmap like this. I find that even in small companies the person creating this view must explain everything upfront, otherwise stakeholders viewing a board like this doesn't understand what it's meant to represent. If there is a way to overlay a 5 second modal that is customizable by the editor of the board, it would help provide a viewer contextual information about what is being represented by a roadmap view.

Many of my colleagues will also ask, how is this any different from Jira Advanced Roadmaps (Plans), Miro Boards, or a spreadsheet? The difference is that this is a "Product-driven" view of a forecast into the future by quarters. This means, these are high-level estimates not meant to be commitments by engineering teams on delivery.

Nate Dame

Option 1 was slightly more clear - however, I like the "more composable" nature of option 2, where the timeline is dependent on a field options can create/edit (and fully control).

(Disclaimer: I only took a quick look )

Hanna_el4c06

Hi @Paul Newell

Thanks for this feedback and notes on the options! Indeed the options have a slight difference and a bit of clarification could help 🙂

The first option represents an approach with time units and date/month/quarter picker. Where it's possible to give an exact date when plans are defined and a bit more vague range like Q3, when things are not defined yet.

The second option represents the idea of using a select/multi-select field to create any value that will represent a "time" unit. It's up to you to decide if you build a timeline based on quarters or months or releases, but it requires a field with values.

Hanna_el4c06

Hi @Dave Perini

Thank you for sharing the feedback with us!

Did I get it right that you imagine these 2 options can live together in the product? Could you share when or why would you use the time-based and custom field option?

Maybe you could prompt users to choose between time-based or custom field during creation?

Hanna_el4c06

Hi @Jonathan Hau

Thank you for sharing! I followed up in the email.

Hanna_el4c06

Hi David,

Thank you for sharing your feedback!
Jira Product Discovery wants to help PMs to communicate their plans with stakeholders and in the future do it externally, with customers or users, for example. Jira Software has many details that such a target audience doesn't want to interact with.

We know that it's a pain to maintain and keep it up-to-date 😔. If you could think of what can help you with that feel free to share your ideas with us.

These change so often for us that trying to keep them up to date is a chore so I wouldn't want to have to manage multiple timeline/roadmaps or create confusion about what each represents.

Dave Perini

Yep! I think there are use cases for both options. For example, in the past I have created separate roadmap versions for different stakeholders:

One that represents works in Quarters or Months for higher-level stakeholders
One that represents work in Releases or Sprints for delivery teams

I'd prefer not to have to create custom fields to represent universal time concepts like Week, Month, or even Quarter (though some companies may differ on when quarters start/end). But a custom field would be very helpful if I'm using a proprietary time range like Sprint or Release.

Hanna_el4c06

Thanks @Dave Perini

It's very helpful for us!

Pieter Bezuijen

Hi @Hanna

Really nice that we can think along on this feature!

Option 1 feels like a more intuitive approach for me personally. Currently I also use the 'Plans' feature within Jira to play around with timelines and roadmaps. And this feature feels like it's going the same directions.

There is however an additional challenge for me personally. We use the product discovery to document lots of ideas, some quite big and others very small. Our list of ideas is already over growing over 100 ideas. As a product lead, I'm responsible on developing a logical roadmap out of the over 100 ideas for multiple platforms, where some ideas span across multiple pagetypes or even platforms and ideas can contribute to multiple goals.

I'm looking for a way to more easily group multiple ideas into clusters where we can add a cluster to a timeline and break that down to see which ideas we can include in a given timeline.

I'd like to see a pagetype as a 'vertical column' in our online landscape and a 'theme' / 'topic' as a 'horizontal row'. Both would translate in clusters of ideas to pick up which I would like to group in some sort of roadmap or timeline.

Does this make any sense in light of the discovery project type and forming timelines? Thanks!

Oliver Murray_xoraw3

1 - When doing tasks what was unclear in the flow and wouldn't work for you using it in your work? What worked and you'd be using it?

I expected (and would prefer) a drag and drop function to resize on both.
it was unclear what data the "based on FY23" option would pull from. Sounds like I would have to set up values etc somewhere else and that could add more steps to the process or create unexpected upstream/downstream effects.

2 - Which option (option 1 or 2, or specific parts of both options) resonates more with you? Why?

I didn't notice a huge difference but option 1 seemed somewhat more intuitive to me based on how I use JPD now. Partly as it keeps you within the page as per point 2 above.

3 - What is crucial for you in a such view (which might not be presented in the prototypes)? Why?

I would like to be able to share a live view of current progress so anyone can view the board and see what we are working on currently at any point of the sprint.
A job "done" completion ticker would be nice to have. Visual roadmap highlights in sync with workflow status perhaps. Keeps viewers in sync and confirms progress.
As background - I currently I have a "now, next, later" column view per Q but as devs update this field every month, when you get to the last weeks of month 3 of the quarter, the board will look empty showing only "now" tagged tasks (current view filtered to show only Q-X tags - pre the next quarters planning session which I'll make a separate view for). Therefore a simple snapshot of our plans at the start of the quarter seems a safer bet and I'll probably take the data and create that elsewhere for visual synergy + paraphrasing reasons.

4 - Any other feedback and suggestions that you might have

A vertical line showing the current date
I wonder if there could be ways to display the inevitable changes to the timeline (dotted lines perhaps) to show where things have been pushed back? or notify external watchers (a separate new feature req) so I don't have to manually keep every stakeholder up to date. Explanations may be needed for such changes -ideally also pushed to watchers.
Allow external viewers to watch particular items for progress updates. customise notifications they receive and what fields they have access to. EG changes to the end date +explainations as above
As the timeline moves forward it might be useful to update "now, next, later" so they are kept in sync and don't rely on manual updates to custom fields. A simplified view of now next later tailored to a dept or project could then be built and self-managed.
Option to add rules based on the current date and task start / ends.

Hanna_el4c06

Hi @Oliver Murray

Thank you for sharing the feedback with us!

Riku.Kristersson

Looks great! Option 1 was more intuitive but I was wondering what field it is using to get quarter information and is there possibility to choose the field like in option 2.

What is crucial for you in a such view?

Option to see delivery status visually so that entire bar can be changed to look like progress bar.
Hide ideas individually or based on filter (I would like to choose what logic filter is using in other views as well - like "show ideas that have value x and not have value y". Option to use JQL search would be best)
Some way to visualize dependencies (linked issues), example group by linked issues could be one way to create timeline that shows selected links like "depends on".

Gabriella Addonisio

I would like the ability to visually show stakeholders when we plan to start discovery of a project (e.g. we would be reaching out to clarify requirements and do research) and when we tentatively plan on doing execution/delivery of a project. This would also help me do capacity planning/work load balancing between PMs which is something often ignored. We spent so much time capacity planning for developers and not PMs

Nicolo_4d5ba5

So is the team rethinking the retirement of the public view and feedback? The one here.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

feedback

test

roadmap

timeline