Source
r/UXDesign•
fieldwaves

Keeping Design files in sync with live site

Hi folks. Bit of a practice question here...

Here's a scenario:

  1. You have some UI designs fully fleshed out & spec'd in your design tool of choice
  2. Over the course of development some small compromise has to be made - let's say a button can't be placed where you want it, so it's left in a different place. Sure, compromises happen.
  3. Some months later you need to add another piece of functionality to this page, so you dutifully do so. However, now the button in your designs is in a different place from the live site, so when you hand over the UI work the devs are confused by this "new" button, and you end up having to re-discuss what it is and why it's there.

Obviously a very basic example but you can see how it could get messy with larger compromises made during development.

So - what would you do to avoid this scenario? One option would be to refactor the designs based on the change in dev, though this means you overwrite your intended design with the compromise, so you'd need some way of storing your original intention for the future.

Any hot tips?

Posted Aug 25, 2021, 4:03 PM UTC

48
mattberan•

When I have clients that need accurate prototypes that continue to represent the live product (very rare in my current role) we implement a couple different tactics to address this:

1 - We review designs with developers prior to stakeholder approval, this ensures what we have designed can be implemented as we have prototyped. Oftentimes this also reduces development costs, depending on the platform and operating models.

2 - We go through a training and process that connects the design lifecycle to the application development lifecycle. This isn't easy, as it is usually requires organizational, cultural and process changes. Basically all change requests and projects go through the designers (paired with product leads). Then combine this with tactic 1 above to ensure everything continues to go through design, prototype, validation (usability/develop-ability), approval, interpretation (story writing), handoff and development support.

This requires buy-in and support, especially from the development teams and primary stakeholders/decision makers.

Figma has added versioning, branching and merging which greatly improves this experience, especially when you consider multi-variate designs and implementations.

Hope this helps, share your experience!

3
fieldwavesOP•

Thanks, that's very insightful! Your organisation sounds far more mature than mine (we're somewhere between a 1 and a 3 on the NNGroup scale). I'm the only designer in quite a large, traditional organisation that's predominantly backend devs and middle-managers, so it's been a learning curve!

One of the issues as that the devs are fairly inexperienced with some of the tools we use, so often we don't know of a potential design clash until they've sat down and tried to implement it.

I think your method #2 is close to what I was thinking - have a process, and if anything changes you have to bump back up the steps and go through them again with the new information. That keeps everyone on the same page - the only thing I need is a good solution for all the "nice to haves" that get trimmed out of the design, so they don't get forgotten.

1
mattberan•

I appreciate the perspective, not mature across the org, just our microcosm.

Yes! What we make sure to do is to create snapshots that capture the roadmap, also tracking those on a roadmap in Miro.

So for a greenfield project we would have: 1- the initial wireframe 2- the MVP and a snapshot of what made it into production 3- v1 and a snapshot of what made it into production 4- v2…

Etc. each item is either a version or a branch depending how we are structuring.

We used to do this with pages in figma or UXPin or file names in xd. This gives us the ability to look back at our ideas during wireframe, mvp and other versions while still having an accurate representation of what made it into the sprint.

Would love to hear what you end up doing.

3
NMS-Town•

^^^this

What you want to do is try and keep your bias out of it as much as possible. Even if that change was out of scope and introduced later, then that should've triggered the buy-in and support from the relevant stakeholders.

Really it's like what Matt wrote, and this all should've been worked out from the start of the project. A PM should be able to mitigate for that type of scenario, and have few solutions already worked out.

1
mediasteve66•

Unfortunately you have to use the existing live design as you add new elements. Keep a second version with the ideal design and see when you can bulk fix your preferred solution when it can be added to the roadmap.

2
fieldwavesOP•

Ah see then you get out of sync if you do any other work to the page - let's say you add a new text field in. You have to add it in to both your "ideal" design for the page and the "compromise" design that's currently live. Then if that gets compromised on too... It keeps going!

I guess there's not really a clean solution to it at the moment, beyond saving the design off and then having some kind of improvement ticket. Then when you eventually get to the improvement you can refer back to the "ideal" design but then adjust it to fit whatever the current state of that page is.

1
mediasteve66•

Not a perfect system but often times you can take screenshots of the actual app and work in the new elements. Often times I’ll sneak in small formatting or styling improvements.

I’ll also put current and proposed side by side showing proposed updates.

Yes you still have the ideal design archived but that’s not really relevant to this conversation if those new designs are not actively being worked on is it? I think the crux of this conversation is you have to let go of the blue sky designs until you’ve received sign off from all parties.

2
fieldwavesOP•

Yeh that's a good idea - I think it's about keeping your design work easily to hand for any "not for now" features so you can easily work it back into the main design once it is needed, whilst also acknowledging that things move & change.

1