• Johan Ronsse, over 1 year ago

    What I am about to suggest might not work for you, but I will explain how we deal with it.

    As designers we observed the problem you describe.

    Instead of just delivering static mockups, we have changed some of our processes entirely to a) include front-end development template delivery (for web) b) have access to the native codebase.

    If you want to change the spelling of a word, it doesn't make sense to go send an e-mail about it. Just change it in code and send it out for approval.

    This way the design change is embedded in the single source of truth (i.e. the app code) and it can't be missed.

    I realize this involves designers starting to code and it might not work for every type of change, nor do we want any (starting) designer to have access to any codebase (that has to be stable), but in general I think designers, especially senior UI designers, need to move closer to development sometimes so just avoid some of these communication problems entirely.

    2 points
    • Jan Vu Nam, over 1 year ago

      Interesting! Thanks for the answer Johan!

      I see 2 downsides of this approach and am not sure how you tackle these in your team. As you said, may not work for my purposes, but still would love to hear how you deal with it:

      1) The design source of truth is lost - there will be discrepancies between the design in the design file and final product, and it is easy to lose track of what changed for what reason. It harder to work with the design files afterwards if they don't really correspondent with what is in the product.

      Or do you have some special ways to keep the design file 1:1 with your codebase?

      2) It takes time and focus away from the designer - even when the changes are small, it takes time to communicate changes to the developer in person. It also leads to "designing on the go" syndrome - where designer is trying different styling variants with the developer rather than in his design tool. Which can make this process much more inefficient, considering how each run has to be committed and built out from the command line.

      0 points