This is an issue to gather feedback from Product Designers at GitLab around the current Design Management features and use. The goal of this is to provide asynchronous feedback to the Design Management team in a retrospective style format. Please provide comments using the following themes:
what works well in Design Management
what does not work well in Design Management
what can we improve in Design Management
For each point you want to raise, please create a new discussion with the relevant emoji, so that others can weigh in with their perspectives, and so that we can easily discuss any follow-up action items in-line.
This is a public issue, but please feel free to provide honest feedback.
Questions and feedback can also be addressed to the Design Management team on slack in #g_create_knowledge or #f_design-management or directly to the Product Manager - Christen Dybenko (@cdybenko).
When discussing designs, it's tough to reference the specific design you are talking about, e.g. in this comment of mine https://gitlab.com/gitlab-org/gitlab-ce/issues/63499#note_214716221. This is the same issue as when using the issue description as place to upload the design instead of the comment itself.
This would definitely be an improvement, but there is still something else missing to really solve my problem. I will still have to jump from the Discussions tab to another place instead of how I currently attach an image to my comment and have both the discussion and the image in one place (even though I can't mark certain parts of the image, which will be possible with Design Management). The user will always have to switch between two places, which makes the discussion tough to follow.
Adding the designs tab now creates a situation where we do not have the issue description as the "Single Source of Truth". I would love to see whether we could maybe convert the "Designs" tab to a "Solution" section, that is part of/underneath the issue description and enhance it with more functionality, e.g. adding text to it.
this. It would also be nice to change the color of my marker- especially for GitLab designers given that our designs use the same color scheme. In my case the blue was blending in with my designs.
I think it would be nice to toggle that marker on and off as well. Hovering over my designs with that marker cursor constantly on makes me a bit anxious.
It would also be great if in a long thread- I could just click a marker and jump right that that relevant discussion.
I’m able to scroll behind the window, which should not be allowed. Similarly, I’m able to tab to content under the window, which is a no-no for accessibility. There should be an intentional keyboard trap that keeps me looping through these controls only.
Provide a clear way of selecting and deleting uploaded designs. As far as I know, there is no proper way of selecting and deleting screens. Let's say I mistakingly add the wrong design, if I re-upload one, it's creating another version. This was not what I wanted to do. Would we be able to check and uncheck uploaded designs and then delete one or multiple screens without versioning?
I'm concerned that critical conversations will be missed when happening in two different places (Discussion/Design). While no fault of this feature, I already find myself missing tabs often, because they just aren't that prominent.
To me this is all "discussion," just with different artifacts.
I have yet to dogfood in detail, but this was my initial impression too - that this feature may unintentionally obscure and isolate design discussions.
In a separate issue, I suggested some potential solutins (which may or may not be the answer)
ability to link to designs from Description or Discussion thread
logging when designs are uploaded/commented in the Discussion thread
I miss a spot to add more general description to a design that I upload. Often I want to add some explanation to a design when I upload it. That's no problem in comments as I can add any text and format it in any way, but when using designs, I either can't or I have to add the text in a comment in the discussions tab and reference the design I uploaded.
I am not getting notifications when comments are added to the Design section. This means I manually have to remember where I've added designs and then go through each to look for new comments.
@jareko@cdybenko@phikai Wanted to bring this one up again, because I'm still experiencing this issue, at least as of a couple weeks ago.
I do get notifications (both email and todo) when I am @mentioned in a comment in the design section. But I am not getting my participation notifications via email when someone comments in the design section. I will get email notifications if someone comments in the discussion tab, but not if they comment in the design tab.
Not for any good reason, other than because this isn't necessarily an actionable issue inside of the GitLab software projects and there have been other Feedback type issues in this project. Happy to move it somewhere else, but there doesn't seem to be an appropriate place for this kind of stuff.
This is a big improvement over posting a design in a comment and discussing it. I like that I can comment directly on a specific part of a design and just have a compartmentalized discussion with a relevant stakeholder.
That being said- if our conversation goes in an interesting direction it would be nice to quickly share the thread into the larger discussion.
That being said- if our conversation goes in an interesting direction it would be nice to quickly share the thread into the larger discussion.
This is being worked on in %12.4gitlab-org/gitlab#11851 (closed) where all discussions on designs would appear in the main Discussions tab of the issue.
When I'm creating designs inside of Sketch, me and other designers often times prefix them with numbers to have a better overview of the order.
In some cases, there might be a step missing and after inserting a new screen, we quickly rename all following designs to keep the order intact. When these screens get exported, their name changes and in our current model where a file is being identified by the filename, this creates 2 problems:
I upload the updated file, but it creates a new version instead of overwriting the previous one and I will have to manually delete the old one.
By using this model of only identifying the design by its filename, we will run into trouble when showing a history per file.
Sketch Cloud solves this by using the internal IDs of each artboard instead of the filename, so they can detect whether a file has been renamed. This is something that we could replicate with a Sketch plugin (gitlab-org/gitlab#29805 (closed)).
@mvanremmerden This is actually interesting. I understand what you're doing here, but I also think that if you were to look at a complete version in the way we're doing them with designs, the rename of files (due to the insertion) of a design actually means that collection of images at X version is different than collection of images at Y version.
Where that's hard is on the individual file level because the context is lost because the name has changed.
It probably makes sense to think about how we handle replacements/additions... or some kind of support for ordering files which would help here.
@jareko Maybe worth some UX research on this one to see how to handle these types of situations.
if you were to look at a complete version in the way we're doing them with designs
You brought up a great point, and I actually think this is a symptom of a bigger question: How do we as designers think about Design Management and what to use it for vs. what is the current implementation and vision, and what are the constraints that we have?
As a designer, the early phase of my usual design process consists of dozens of iterations. My work is often messy during that time, and I want a lot of feedback from other people (both designers and people from other departments) when we are still in early stages of black & white wireframing, only have a quarter of the entire flow ready or still have big flaws in our designs. For this phase of our design process, Design Management in GitLab will never be on par with the native feedback and collaboration features in our actual design tools and we shouldn't try to compete with them.
The current implementation of Design Management expects a complete set of polished designs that are ready to be approved with a minimal number of reviews and that should serve as guidelines for how the actual UI should be implemented. All of this is part of the later stages of the design process, and this is something where we can play to the strengths of GitLab. It's an area with a lot of different pain points, where there are no great solutions yet, and where we can use our direct connection to the developers and the implemented versions of our designs very well.
I'm afraid however that we do not make the actual use case we want to target and the problem we intend to solve clear enough, both in the current UI and experience, as well as in our communication around this feature. A lot of the feedback we are collecting here thus focuses around how to make Design Management in GitLab work for the early phase our of design process that I described earlier.
@mvanremmerden What prevents you from gathering feedback on the early stages of your process with Design Management? Is it just the activity of actually getting designs in to GitLab?
@phikai From an experience standpoint, using the feedback and collaboration features in our design tool itself vs. doing it in GitLab is very similar to having GitLab as your one devops tool vs. having a toolchain with multiple plugins and integrations.
When I create a design in e.g. Figma, I can just invite others to give comments or even collaborate with me. I can either decide to just include the bare UI screens, or add explanations and highlights in whatever format I want to (which is very important, as context matters a lot for designs). To make it easier for the reviewer to understand the flow, I can connect the screens together to create an interactive prototype that they can start from the same window.
When something catches their eye, they can comment on specific parts of the screens, next to the screens, on the description, or wherever they feel it fits best. They might even decide to go in change the UI or the text themselves, if they have the right permission level. If they don't, I can go in and see where they left the comment, quickly make that change, answer their comment at the same spot and resolve that thread. All of that within one window and in one context.
It's a seamless experience that we won't be able to replicate outside of the design tool. There are too many structural constraints, such as for example the need to always have to switch between one context for reading the comment (GitLab) and acting on it (design tool).
If you wanna try it out yourself, we just started experimenting with async design feedback sessions within our UX team and this might be a great example to show you how the experience compares: Figma file for snippets
You can start the prototype with the Play button in the right corner of the top navbar.
We could probably handle renaming by recording it as a new rename event against the old design, which would treat it similarly as if it were deleted (i.e., hidden from that point onward, but still allowing a new design to have that name in the future), and within the same version create a new design, which would be linked to the previously named design in PostgreSQL.
I'm not saying that would be easy (and there's a lot of questions, like how does this affect asking for a design's versions in GraphQL, could we have a rename/move mutation rather than handle this in the existing upload mutation etc.) but FWIW it could probably be done somehow if we wanted to.
I'm not saying that would be easy (and there's a lot of questions, like how does this affect asking for a design's versions in GraphQL, could we have a rename/move mutation rather than handle this in the existing upload mutation etc.) but FWIW it could probably be done somehow if we wanted to.
There also is another question: As we cannot automatically detect whether an uploaded file should be a new create or a rename, this will have to involve a manual action from the user. In the one case I encountered, this would have meant a rename for 20 files, while the native features in our design tools (e.g. Sketch Cloud) automatically detect that as each screen has its own internal ID.
I don't have enough knowledge of the Apollo::Upload object we receive to say how easy or hard it would be to have IDs optionally passed alongside the file upload so we can infer renames through the upload. But again, I'm sure possible in some way if we wanted to support it. In this scenario are you thinking of having internal Sketch IDs be used to match existing designs?
In this scenario are you thinking of having internal Sketch IDs be used to match existing designs?
That's the critical point of this problem: If the user exports their design in e.g. Sketch to an image file they can then upload to our designs tab, there (probably) is no way to extract that information from this file. As Sketch built the upload of their designs into the UI of their app, they can pass whatever additional information they need.
I also already checked whether there might be any exif information we could use in that image file, but it's completely blank. The only chance for us to replicate that behavior would be to build custom plugins for the most popular design tools.
It may be that relying on metadata would lead to an inconsistent experience when people have stripped metadata from the file and would expect the magic rename to happen.
At the moment our mutations only allow you to upload and delete designs, so there may not be a lot of extra value that custom plugins can add besides a quicker way to sync designs to GitLab. But perhaps considering what richer integrations would look like we may be able to come up with more proposals for mutations and features, and make the experience of using plugins more compelling.
When I create a design in e.g. Figma, I can just invite others to give comments or even collaborate with me. I can either decide to just include the bare UI screens, or add explanations and highlights in whatever format I want to (which is very important, as context matters a lot for designs). To make it easier for the reviewer to understand the flow, I can connect the screens together to create an interactive prototype that they can start from the same window.
Those feel like features vs. specific workflow issues. Basically recognizing that we don't have the same features as other more mature tools, but we're 1.5 releases in to this category so that's an unreasonable expectation.
It's a seamless experience that we won't be able to replicate outside of the design tool. There are too many structural constraints, such as for example the need to always have to switch between one context for reading the comment (GitLab) and acting on it (design tool).
I'm very curious about this component as what this sounds like is "Designers can't work in multiple tools because it's hard or context switching and doing work is hard". BUT - I haven't seen that same argument made for engineering tools to say that having to work in a local editor is hard and switching tools from the MR review to my editor is too hard.
Seems like an important question is surfacing here - When might our design management product compete with industry leading tools feature sets? Until we do, it's difficult for us to to compete with workflows that rely on full featured solutions. My perspective remains that we should start by supplementing those tools vs. competing, especially in areas of the design lifecycle where we have unique leverage.
For designers working in industry leading design prototyping solutions with the goal of working efficiently, which is majority of overall market, lack of feature parity plus the transaction costs and risks of conducting design iteration and feedback in two separate tools are prohibitive, and thereby create barriers to Gitlab adoption.
I'd suggest we exercise caution in drawing parallels between design and development problems and solutions, as the users and nature of the work are likely to be very different.
I'm very curious about this component as what this sounds like is "Designers can't work in multiple tools because it's hard or context switching and doing work is hard". BUT - I haven't seen that same argument made for engineering tools to say that having to work in a local editor is hard and switching tools from the MR review to my editor is too hard.
@phikai The further removed design is from discussion, the more friction is added. It’d be like grocery shopping and looking at a product, but the price, description, and reviews were in another isle of the store. In the design case though, it’s not even the real product, but just a picture of it, a screenshot or timestamped artifact—the real product lives in another store.
So silly analogy aside, IMO it’s not context switching that’s the issue, it’s that the feedback ecosystem is removed from the actual design source. In code there’s continuity and you’re dealing with the actual source. You must to move from local dev to MR. Design doesn’t have to do that.
Those feel like features vs. specific workflow issues. Basically recognizing that we don't have the same features as other more mature tools, but we're 1.5 releases in to this category so that's an unreasonable expectation.
I do think there is a deeper problem than just a lack of features. No matter which way we move forward, there are three aspects that we will simply never be able to solve in the same way that design tools can by integrating them as native features:
We will never be able to let users review and directly make changes/suggestions to the designs in the same context.
We will also never be able to display the comments from GitLab in the design tool right at the place where the designer has to change something, and also let him answer from there.
We might be able to show a popup window with all comments for a specific design in the design tool, but this requires a separate plugin for each design tool.
If we do want to build something for helping designers in the early stage of their design process, Sketch, Figma and Adobe XD are our direct competitors. All of these either already have all of 1, 2 and 3 built in or are actively working on them.
I'm very curious about this component as what this sounds like is "Designers can't work in multiple tools because it's hard or context switching and doing work is hard". BUT - I haven't seen that same argument made for engineering tools to say that having to work in a local editor is hard and switching tools from the MR review to my editor is too hard.
Designers had to work in multiple tools for years. Then Figma arrived on the stage and integrated design, feedback and real time collaboration in one tool, which led to them grabbing such a big share of the market in such a short amount of time that both of the biggest competitors adapted their strategy and now also have all of that built in, as mentioned above. There is no way that as a designer, I would want to move back to having to deal with multiple tools again for this part of my process.
All of that said, I still think there are other parts where building features for designers in GitLab will be extremely helpful, but I cannot see a way for us to overcome the three big issues mentioned above for the early part of our design process, until we have a polished and "ready to get approved" version of our designs.
it’s that the feedback ecosystem is removed from the actual design source. In code there’s continuity and you’re dealing with the actual source. You must to move from local dev to MR. Design doesn’t have to do that.
This is interesting, because if I were to think about an MR... the feedback for that happens inside of GitLab, but except for the simplest of single line changes you've essentially got one window open that shows the feedback in GitLab and another window open where you're acting on that feedback.
I'm having a really hard time groking how that could be different in a design. You could have one window open that provides feedback and one window where you're actin on that feedback. Those seem like very similar experiences to me, but I'm clearly missing something here.
There's certainly differences in how that content gets to a place where feedback can be provided, but the actual experience of acting on the feedback feels like it would be very similar.
There's certainly differences in how that content gets to a place where feedback can be provided, but the actual experience of acting on the feedback feels like it would be very similar.
You are absolutely correct that the experience would be very similar. What is different though is that in the design world, this is a problem that all big design tools have already been able to solve. Any solution that we build that does not unify both the feedback and the acting on it in one tool would thus not even bring us on par with what designers are already using, but even be a step back for designers.
As far as timeline, I'd reference our maturity page which have a time table for parts of the life cycle.
Shows feature category reaches and maintains Viable in 2020:
Definition of Viable absent feature specifics, so cannot assume we intend to build both design and feedback features required to satisfy concerns noted here,
Viable is defined as "used by customers to solve real problems", which does not imply a robust feature set. Seems we should factor that into our strategy.
I miss a way to easily tie comments to the related number on the image. With lots of comments/numbers, I'd like to hover over one and see the related comment (or vice versa) somehow stand out.
@tauriedavis I'm not sure I understand this. The comment icons are numbered, and the threads are numbered in the discussion. Are you looking for some other kind of visual representation here?
Yeah, I am looking for more connection when looking at an image that has multiple comments.
The above image has five comments. If I am reading the first comment, I want to easily see where it is referenced on the image without having to scan the entire image to find the (1). Interacting with the image number or comment number should somehow highlight the relationship to reduce the need to scan the whole image or comment list.
@phikai and @mvanremmerden here’s more of an integration I’d like to see. The Figma API allows read/write access to comments. This allows designers to stay where the design is, in Figma, and others to stay in GitLab, all while seeing the same comments and design. https://www.figma.com/blog/introducing-figmas-platform/
I believe that this is what Zeplin does with Figma files. So replace Zeplin with GitLab and you have a more seamless experience based on SSOT design, rather than artifact vs design file.
@jeldergl This is definitely something interesting, but there are way more constraints with Sketch and even more in Adobe XD, I wonder how we would deal with that.
Back to your other point though, others (Zeplin, Avocode) do this already with those apps. So it’s possible, but we’re back to replicating tools that already exist.
Absolutely agree, and it seems to me that all of these separate tools are currently struggling a lot as the big design tools are working on or have been able to build these features directly into their main tool.
@jeldergl I actually think we'll need to get to two way communication between design tools and GitLab for some of the reasons above, but that we'll also need our own version of these features for teams not using those tools. There's also a difference in what we can build (limited by imagination) vs. what we can integrate with (limited by API).
The challenge I'm trying to understand is... is a world with feedback not in the design tool, but in the tool that more of the company works in more valuable than feedback in the design tool.
The challenge I'm trying to understand is... is a world with feedback not in the design tool, but in the tool that more of the company works in more valuable than feedback in the design tool.
There are two answers to this question.
In many companies, the design tool is the single source of truth and where the majority of people live in and collaborate,.
If that's not the case and we are talking about more developer driven companies with similar structures as GitLab, having certain discussions in GitLab would indeed be more valuable, but all of them are in the late stages of the design process in my opinion. The early part is too iterative and fast-paced, so that every friction would be a big pain, as it would be repeated many times until we arrive at the first final version of the designs.
The challenge I'm trying to understand is... is a world with feedback not in the design tool, but in the tool that more of the company works in more valuable than feedback in the design tool.
In my experience the SSOT for design has never been housed in a tool like GitLab. At my previous role, we actually used an external link in stories (Jira) to reference Zeplin because designs embedded in issues/tickets became outdated artifacts and requirements/QA kept referencing the old artifacts rather than the most recent.
Here are the three most common scenarios I’ve experienced related to design, and my take on them.
If feedback is for the designer, then as close to the design as possible is where feedback should live. This prevents noise in channels where it is not necessary, and helps the designer check things off in context.
If comments are for requirements, then they should be added as requirements alongside a design artifact and updated when design changes, but not necessarily attached to the artifacts as overlays (most tools with commenting have a “resolve” function, so eventually comments should all be addressed, and potentially not visible).
If comments are for handoff, then they should be where the developer can most easily reference them, and have fairly robust inspect and export features.
In many companies, the design tool is the single source of truth and where the majority of people live in and collaborate,.
If that's not the case and we are talking about more developer driven companies with similar structures as GitLab, having certain discussions in GitLab would indeed be more valuable, but all of them are in the late stages of the design process in my opinion. The early part is too iterative and fast-paced, so that every friction would be a big pain, as it would be repeated many times until we arrive at the first final version of the designs.
Market analysis like this suggests majority of market is #1 (closed) (Sketch and Figma) and minority #2 (closed) for iterative design and feedback.
As per Marcel's above post, Figma, Sketch and AdobeXD are direct competitors that have or will shortly have design and feedback in single solution.
The chart above just shows usage for a given activity, specifically Design. It doesn't actually reference anything about the feedback cycles at all. In a series of interviews we did with users we actually talked to a few people who's designers use Figma and Sketch but feedback didn't happen in those tools. We also talked to someone using Zeplin and it didn't happen there either.
It may be that designers working with other designers work in these tools and have feedback cycles there, but based on people we've talked to... the rest of the company isn't in the design tool. Even here where we use Sketch, I've never provided feedback in Sketch directly.
Files need some sort of way to be organized (through sorting or manually dragging them). Order matters when showing designs and it seems there's no logic at all on how they get presented besides the order in which they get uploaded which also seems to be arbitrary.
Invision allows to do this, but their solution is not great either, since their alphabetical/ascending sorting option it's some sort of destructive action.
Both. Prototype/Workflows definitely require an order to clearly show their meaning, but individual screens many times are following certain narrative where order matters. For example the before and after of certain view or screen.
Also when you're inside the design previewer there are already strong navigation mechanisms like the pager, that reinforces the concept of setting up the designs with a meaningful order.
@gitlab-com/gitlab-ux I want to thank all of you for your feedback here! We're going to close this issue out at the end of the week and start to triage and prioritize some of the items reported here.
Thank you all so much for your feedback, and please know this doesn't mean we don't want anymore of it, we're just trying to keep this manageable.
As this is framed as "Design management" I would expect to be able to add design work other than static images at some point. I often create clickable prototypes in Sketch/InVision and would like them to be attached to an issue as the solution. Right now, our design management feels more like assets management and it reinforces the notion that designs are pretty much static images of UIs. I'd like to be able to add links to MURALs, Sketh prototypes, design specs, as well as videos (maybe also upload) etc. Is anything like this planned?
@matejlatin I agree with you in terms of using outside clickable prototypes. I know this issue is closed but lets set up a coffee chat on zoom to discuss!
On Plan, we are collaborating on designs in the comment threads, then putting the final designs in the Design tab. Because of this, it's pretty common that the design that goes into that tab has already been referenced elsewhere on the page. I love having the ability to copy/paste an image from somewhere else in the page into a field like in Descriptions, rather than having to click to upload each time. It doesn't appear this is possible so I need to upload each time.
@hollyreynolds Just so I understand - Are you saying you'd want the ability to paste a link to a design (that's already linked in a comment) rather than uploading them from your computer?
@jareko Yes! We finalize the design discussion in Comments so usually what goes into the Designs tab is already present in Comments. Therefore, it's nice to just be able to copy/paste rather than have the extra step of browsing for and uploading the file.
@hollyreynolds@jareko Interestingly, on the projects where I've used the design tab (in Growth), we're actually doing it kind of the opposite way. The design discussion all happens in the design tab. The final designs live in the design tab, and I also put key screens of those final designs in the issue description for better visibility.
Personally, I would love the ability to take the link of a design that lives in the design tab and put it in the issue description and have that image in the issue description update every time I update the design in the design tab to a new version.
@hollyreynolds In the projects I've worked on, I start using the design tab once designs are in a more high-fidelity state. At the start of a project, I usually share wireframes via Mural and we discuss those in the issue comments or in Mural comments.
Once the design has moved to high-fidelity mocks, I'll put it in the design tab. We liked that the design tab let us place comments on specific areas of the design, it made it easy to collaborate on suggestions and feedback. I'd update the designs based on the feedback and re-upload them until we get to the final design (which will be the latest version in the design tab).
As far as sticking images in the issue description, I like doing that to give visual reference to the content in the "Solution" section or the "Requirements" section.
I would like to be able to reference design files in the issue description. Get a snippet on the design file that I then paste in the description and the image is added and it links to the file in Design Management. It could save a significant amount of manual work
Another thing that I feel would be a nice enhancement would be adding some additional visual weight to the timeline when designs are added. I've received feedback from our PMs that they can easily miss when a design has been added, as it can get lost in the noise on the timeline. If we were to include thumbnails of the images, I think this could help with this problem (see images below for what I mean). If we were concerned with uploads that contain a lot of images, we could cap the thumbnails at a certain number, and do something like + 3 more designs. I'm curious to hear if others would benefit from this sort of enhancement?
This is awesome @nickbrandt ! I feel like it could help with one of the challenges I have- making my designs in the design management tab more visible to the team. I wonder if there would be an opportunity to even differentiate between different states and action upon them in different ways in the timeline (ie: "new" designs, "urgent" designs, designs that are just small updates or versions, etc).
I recently tried using the Design tab and ran into the following issues (not sure if there are issues already created for these items):
Bug: After posting a comment, I realized that I wasn't able to edit or delete
Bug: The "Preview" feature didn't seem to be working:
After having uploaded 4 versions of a mockup, it became hard to understand where all the comments were. I had to click into each of the design thumbnail in order to see if the comment/response I was looking for was there.
My expectation was that all the comments would stay in the Discussion area and would somehow link to the appropriate design files.
I also plan on posting more prototypes vs static images, as already mentioned.
NOTE: I was using Chrome Version 79.0.3945.130 (Official Build) (64-bit) when I ran into those bugs
+1 to this. I just added a comment to a teammate's design and then realized I forgot to tag her, and was surprised that I could not edit my comment! I had to post another comment doing so.