When engineers and designers are working together to build products, the issue is the single source of truth for knowing what needs to be built but it is difficult to provide feedback on designs because there may be multiple items of feedback for different areas of each screen or workflow, and it is hard to leave this feedback in the linear discussion thread on the issue.
It would be very helpful to be able to leave point of interest comments on images so that more detailed discussions can occur in more organized fashion.
Target audience
Software Engineers, UX Designers and Product Managers all collaborate and give feedback on designs.
Category:Fuzz Testing
GitLab Ultimate
devops
application security testing
feature flag
frontend
fuzzing
coverage
group
dynamic analysis
missed:14.7
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
missed:14.3
missed:14.4
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Attempting to scheduling this for 11.10 was very optimistic. Given the first iteration is slipping from 11.9 and we have reduced UX capacity this release, 11.11 is the soonest we can do this.
@reprazent How much work do you think this will be on the backend? We'll need to decouple DiffNote from MergeRequest a bit, but since we already support DiffNotes on Commits too, that may not be too difficult. I don't think we support image diff notes on commits, though, and MRs and commits both point to the same repo, which won't be the case here either.
(I've set a weight of 5 in the mean time, but the backend here feels more like a 3 to me)
We'll need to decouple DiffNote from MergeRequest a bit, but since we already support DiffNotes on Commits too, that may not be too difficult. I don't think we support image diff notes on commits, though, and MRs and commits both point to the same repo, which won't be the case here either.
Looks like most of the heavy lifting is done on the frontend, I think we should be able to add a DesignManagement::Design to the DiffNote.noteable_types, and then change the way we target a repository for any other features.
AFAICT we also don't trace the position of notes between versions of images, so that's also something we don't need to take into account immeadiatly.
With that in mind, a weight of 3 sounds reasonable.
@jramsay as we chatted some weeks ago, I don't think POI comments are a priority and could actually harm the experience if we did it now, since we don't have system notes, the ability to link to designs, or versions. It's also not clear in the designs how these comments would be surfaced in the main activity feed.
I think the most logic order that allows us to build on top of each iteration is this: System notes => linking to designs (design refs.) => versions => regular comments => POI comments
@pedroms thanks for bringing this up again. I agree system notes and cross linking are very important, and needed in immediately following iteration.
But I think the point of interest comments are the key improvement needed to solve the shortcoming that there isn't an easy way to provide detailed feedback on a design, and hope to reuse point of interest comment logic from merge request diffs to make this possible.
Let's create an issue about system notes and discuss those in more detail.
@jramsay image POI comments (and commenting in general) is the end goal, but I feel like we are jumping too much ahead. I'm afraid that building this now will lead to a fundamentally broken feature and experience, because there are other things to consider, like todos and notifications. For example, if you provide detailed feedback on one of my designs, how will I know about it? This discussion reminded me of the MVC illustration here: we build an amazing set of wheels but they are not useful without a steering wheel.
@reprazent have you considered todos and notifications as part of this issue?
Aside from that, in this issue's description we also mention “resolve a point of interest discussion”, but the designs don't show how that is possible. Or even how discussions (number of comments) and their resolvability are visible in both the design detail and list views.
have you considered todos and notifications as part of this issue?
I hadn't specifically, thanks for bringing it up, but I don't think creating a todo on a mention would create that much overhead. Having resolvable discussions might be more.
As chatted with @jramsay, we will move forward with this in 12.0 as an experimental feature because there could be some workflow issues due to the lack of todos/notifications. 12.0 is a major release and it would be great to announce our Design Management intentions with this iteration (even though it might not be that useful in the beginning).
@reprazent if we could squeeze todos and notifications in, great. If not, we'll have to clearly state in the UI that leaving POI comments does not send notifications or create todos.
@ntepluhina this is something we probably will have to keep “open” in the scope and decide in the MR.
To capture thoughts shared at Contribute regarding GitLab's design management strategy and my feeling post design hand-off is an area of opportunity7:
First, found this competitive analysis for context: Detailed UX tool comparison (@katokpara and @jramsay , I know there's a UX prototyping issue somewhere, but I couldn't find it so adding this here):
GitLab's strategic sweet spot is post design hand-0ff, IMO: Given a) most design teams strongly prefer design-first tools for design iteration, feedback and systems work and, b) the vast majority of design teams are unlikely to abandon mature, design-first tools they love to do design-first work in GitLab (just as a developer is unlikely to do dev-first tasks in a design-first tool) and, c) the design hand-off space is largely unsolved and a major paint point for many teams - with most teams struggling to validate UX designs and systems are implemented end-to-end - and, d) GitLab has so much leverage in the post design hand-off portion of the product cycle... I think Gitlab would be well served to focus on the post design hand-off workflows and features.
Product strategy - Are we building tools for the way we work or tools for everyone? - Most UX teams are sync or sync/async. Today, very few are full asynchronous like GitLab (we're working on that). So, what GitLab may desire likely varies from the broader market. From a product strategy point of view, I'm not clear if Gitlab is building tools to help companies work like GitLab, building tools that enable teams to work however they'd like (e.g. sync or sync/async hybrid) or both. And if both, which is the priority - because that radically impacts product and UX strategy decisions like these and many others, in my view.
At my past companies, such as Lean SAS startups, Symantec and Disney, we worked sync/async. Tools like Moqups, Figma and Invision supported our design iteration, cross-functional feedback and systems work so well, it's very hard to imagine GitLab disrupting that space in a meaningful way. Post design hand-off, however, was a persistent gap that hurt product, design, dev and ultimately users. Bug spreadsheets, Jira finagling and repurposing third party tools like BugHerd were just a few of the desperate attempts to fill that gap and get UX/FED working end-to-end, each costing more time and energy than we could afford. What if Gitlab turned that gap into opportunity? You know, with some seamless unified platform magic? For example:
Design code reviews with POI dev feedback - Send me a live link for code review and let me click a persistent icon to snapshot what I'm seeing and provide POI change request tasks.
Usability testing live products with ease - Give designers and researchers an easy test environment for spinning up moderate/unmoderate user testing to validate products and capture user feedback in a way that actionable for agile teams.
Design system integration and validation - Make it easy to communicate design system components in designs and validate they've been used.
Thought is: Why try to pull designers away from prototyping tools they love when we can provide them with prototyping-agnostic tools they desperately need and we're uniquely positioned to provide?
@sbouchard1 thank you so much for this thoughtful comment
Competitive analysis: Thanks for sharing those links! We actually did our own comp. analysis of design tools that tackle design creation, collaboration, and handoff, in October 2018: Google Doc. Check out our blog post and the corresponding issue (which also has relevant comments and related issues).
Design handoff sweet spot: Those are really good points. To be clear, our mission is not to compete with design tools and pull designers away from prototyping tools. But there is gap that GitLab can fill in cross-functional design feedback (and handoff, as you mentioned), because the whole team is already working in GitLab — PMs, Dev Team Leads, Devs, DevOps Eng., Sys Admins, Security Analysts, and also Designers (our Product Designer persona is worth a read.) Today, both Designers and non-Designers are forced to jump around different tools to collaborate on designs. What if we could make this process a bit easier by centralizing it in GitLab, being platform-agnostic at the same time (we do try to avoid language/platform specific features)? I believe the effort we are applying here for versioned designs with POI discussions will pay off because it will allow everyone on the team to have GitLab as the SSOT for all work planning, discussion, and delivery, regardless of it being code, design, documentation, etc. Yes, some teams will still use InVision, Figma, and others to collaborate, and there we can find an opportunity for better integrations.
Your ideas are great and I don't want them to be lost! Can you please create issues for them (if they don't already exist)? This will allow us to separate the concerns, centralize the discussions, and gauge interest.
@pedroms Yes! I hadn't had enough time to spend on a thoughtful response here, but I think you've summarized the current viewpoint clearly.
I also think we'll re-evaluate some of what our competitive analysis discovered based on that strategy. There's a few companies playing in that space that I don't think we have as much information on, but potentially make sense to look at.
In any case, @sbouchard1 thank you for your feedback and comments. I know we spoke about some of this as well, but it's great to have this feedback and input. It's one of the things that's going to make Design Management here so strong is that our UX team is already so passionate about solving this problem.
This is a great discussion, and I'm very happy we are having it, because I also have quite a few concerns with the direction we are currently taking. I thought it would be very valuable to take a step back and look at the research findings again:
Team collaboration
The following points were mentioned as some of the top challenges for the interviewees.
Making changes without having to manually update each file involved in the chain (integrating & syncing across tools)
"Better collaboration on specific visuals on deliverables, with a good way to keep the feedback 1) captured in a single area and 2) obvious for all roles to find and collaborate.
6 of the 7 interviewees used Sketch, which so far was indeed lacking functionality in that area. However, after their last funding round Sketch announced that the following features below would be integrated into Sketch, the first paragraph in Summer 2019, the second one in late 2019. All of the aspects mentioned are already part of Figma and Adobe XD as well, which together covers roughly 90-95% of the Design tool market.
We want to empower designers to work more closely together and our first step towards this goal will be the launch of Sketch for Teams, available early this summer. As you and your colleagues collaborate through Sketch Cloud, we want to make it the place where all your documents live and in doing so we’ll integrate Cloud deeper into Sketch — bringing things like annotations and comments from your team directly into the app.
And just as we’re bringing more of Cloud to Sketch, we want to close the loop by taking more of Sketch to the Cloud. We’re going to render the entire document, add developer handoff, and allow rich editing along with collaboration, all without leaving the browser.
All major Design tools also have either already implemented or announced the functionality to view the file and comment inside the browser, which eliminates another major pain point that was mentioned in the Persona research.
We sometimes use InVision for commenting, but it is harder to surface this feedback to the full team, and can be challenging to include PMs and Engineers.
In my opinion, this solves the collaboration and discussion part in one app for designers. As the person who was the closest to our interviewees, I would love to hear what @katokpara thinks about this.
Designer Workflow
We talk a lot about eliminating the need to switch tools. One important aspect that we are not taking into account for the Design Management enough, is that we add an additional switch of context and tools into the designer workflow. When using the collaboration feature in Sketch/Figma/Adobe XD the designer can implement the changes right where they see the comments, and also add new ones to continue the discussion right there:
If they use GitLab, they would constantly have to switch between GitLab and their Design tool. Making a change would mean:
Opening the issue in GitLab
Finding comment
Opening the corresponding file in Sketch
Finding the correct spot where the comment would be (a task that could take some time and lead to a lot of frustration)
Changing the design
Exporting the correct part to show the changes
Uploading the new version of the design to GitLab
Writing a new comment
In Sketch it would be:
Opening file in Sketch
Reading comment
Changing design
Writing new comment
The same would be true for version control, which is already fully integrated into Figma & Adobe XD, and partly integrated/fully extendable with plugins in Sketch.
This exact problem that we would be causing with this workflow vs. using the Sketch/Figme/Adobe XD native features is even mentioned as one of the top challenges and pain points for our Product Designer persona.
When presenting deliverables to stakeholders, I want to be able to make updates to a design without having to edit a series of files in various tools.
It’s frustrating to have to create a file in one tool, export the file, create a prototype in another tool, and use a separate tool to handoff the design to developers.
I would also love to get more input from @katokpara on whether she feels like this solution would be what the designers she was speaking to were hoping for.
Post design hand off
GitLab's strategic sweet spot is post design hand-off
@sbouchard1 brought up a great point here in my opinion, and our research findings support this idea.
When developers are implementing my designs, I want to easily keep track of changes that have gone live, so that I can alert them of any needed fixes.
This is exactly the spot where GitLab is uniquely positioned. No Design tool can offer this kind of feedback on the implemented UI, either in staging or production, or simply just for usability tests. This is an area where we don't have to compete with other tools. Even we as GitLab designers are currently only taking screenshots and drawing arrows, so it seems like there is not a single well known and popular option on the market.
This would also allow us to easily draw designers into our platform. It is an additional part of their work that would be triggered by the engineers, who are already heavy GitLab users.
Next steps
So far we only gathered insights, but as far as I can see, never validated the ideas that are based on this research with people outside of our team. This could answer a lot of questions for all of us and would allow us to go into the MVC with a clearer picture of where our vision should go.
Haven't read Marcel's reply yet, but posting an updated reply from me (deleted old one). Think this reply does a better job of responding to your post @pedro, representing our side conversation and adding new info to my view:
I’m struggling to understand a strategy that advocates less marketable products over more marketable ones, and I don’t see that notion directly supported in any of the linked handbook docs. I recognize it's ambiguous, but prioritizing the evaluation of internal request at 10x and avoiding unnecessary configuration doesn't directly imply we should pursue strategies and solutions for us at the expense of marketability/ux. Open minded, as always...
Bias is a huge risk to any product strategy - its what modern product and development methodologies like Agile and Lean are designed to avoid, by advocating continual outside-in feedback from an actual representative set of customers. I’m listening and appreciate the thoughtful replies, but I don’t yet see how the competitive analysis or inside-out blog and persona justify our current approach.
If we’re building this for our internal team, and the market niche of others that work like us today, to get ahead of an async and full remote wave of the future, and or because this is a step towards a future feature set that is more marketable, then to me those are more realistic justification. Even then though, we risk feature bloat and catering to the few vs. the many, which presents risks to our marketability and UX in the short term.
Concerned other teams and the broader market is not sufficiently represented, especially as I read the persona and blog. Have we asked the broader market what they want? Have we used a Venn diagram to find the strategic sweet spot between companies that work like us (the minority) and those that work like most (the majority)? I think that's the true goal here.
Most modern products and development teams are using design-first tools for rapid Agile and Lean UX. That’s because those tools offer mature, design-first, fully integrated, prototyping and feedback features that help teams build better products, faster. Having been on many of those teams, at companies large ad small, I can’t see why they’d migrate from those tools to the proposed solution for design (and here’s an example of important info missing in the persona):
As a Product Designer, I must be able to rapidly iterate— continually and quickly requesting and responding to feedback from product, design, dev and other stakeholders—in order to build better products together, faster.
This solution asks those designers, teams and companies to make sacrifices they can’t afford, easy and fast collaborative prototyping to done, for what seems like things they don’t need - async support.
Here are some examples of concerns (please let me know if I'm missing info and our tools actually cover these bases):
Working in both tools creates extra work and delay due to transaction costs
If feedback occurs in both tools, which is likely, it creates extra work, delays and risk managing and reconciling divergent POI input
Teams loose the benefit of interactive prototypes
Designer can’t quickly and easily reply to a comment with design options to clarify needs and find shared solutions
An iteration’s comments are tied to an iteration; in design-first tools they live on an can be discussed and resolved at anytime
I’m unable to host live design sessions where I’m using POI comments to draw attention to open questions and feedback that needs discussion, so I can make and validate changes in real-time
This solution seems to add transaction costs, delays and risk to most modern prod/dev teams, basically playing into the toolchain paradigm disadvantages we seek to end.
Sorry to be long winded here - given this is new ground for GitLab and we as UX team likely have best real-world context, I feel obligated to apply socratic method and constructively challenge our thinking so we can sharpen strategy as makes sense.
If prioritizing strategies and solutions that serve us at the expense of marketability/ux is our strategy, then I just seek to clarify and understand the why so I can support it effectively. For UX, this is a Rome - many roads are leading to it.
Discussing this on the Knowledge catchup call with @jareko, this seems to be ~"UX ready", so I'll label it as we're taking this issue over to 12.1 and completing it with frontend too.
@phikai@pedro Do the annotations need to support having emoji added to them? If so, does it need to support this for the first release of annotations?
I'm asking just because https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29919 adds the ability for emoji to be created, toggled and removed through GraphQL, but there's not yet anywhere in GraphQL that will return the emoji that have been given to things (like annotations).
@phikai Yes, I mean the upvotes/downvotes-style of leaving an Emoji (i.e., when you click on the little 'Add reaction' face button and choose an emoji).