Skip to content

Settings and activity

2 results found

  1. 1,540 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    fmckinney commented  · 

    @Jacob Goldstein,

    I understand the thinking you're talking about, but I think the implemented solution addresses 1 use case, while causing a major pain point for a lot of other use cases.

    The supported use case is:
    - I as a user want to create a mock that only I can update, so other users don't change things and update the link without my knowledge.

    Here are the use cases where it causes a pain point:

    - I'm a UX designer. I make a mock and pass it to a UI designer for styling. The UI designer makes changes, but has to request that I update the mock, even though I trust them to update it when they feel the mock is ready (or after they get the go-ahead from a team leader).

    - I'm going on vacation, so I pass some work to another designer to continue while I'm gone. The link to the prototype is in the features or dev specs. They can work on it, but they can't update the shared prototype. I'm on vacation on a beach somewhere drinking mojitos by the gallon and there's no way I'm opening a computer. Now they have to save-as, create their own link, update the link in the features in Jira/wherever, and deal with the developers who saved the original link emailing them asking why the prototype isn't updated.

    - I work on a collaborative team where multiple stakeholders work on mockups depending on their area of expertise. For example I do the basic mock and information hierarchy, a colleague deals with animations, another colleague tackles the UX writing, a third designer is in charge of the design system and checks mocks for alignment to product guidelines and adherence to existing components. Every time one of them makes a change, they have to find me and ask me to update the mock, which is super annoying because I've already moved on to something and I'm not their manager, they should be able to update the mock whenever they feel like it.

    - As part of our research process we often do field testing in pairs. Each UX will sit with a user in a different place. In the course of testing, my colleague finds an issue with the interaction, or some problem in the mock. They can't fix it/update it themselves, so they have to write it down, find me in between usability sessions, and update it, even though it's something really minor that they could update themselves.

    These are all real situations that have happened to me personally. So the implementation I would say addresses maybe 5% of my mocks, where I really want full control. For 95% of the mocks, it's a big pain point.

    The ideal solution would be, for each stakeholder in a mock, to allow them update abilities or not.

    fmckinney supported this idea  · 
  2. 257 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    fmckinney commented  · 

    Definitely a must have! I work on more than 20 mockup files at one time, and it's very difficult to find the right one

    fmckinney supported this idea  ·