Where do you see shared layouts/workspaces actually helping you as a dev/platform team?
Is it more about:
End-users tweaking and sharing individually?
Standardising “golden” setups for a desk by the platform team?
Onboarding new apps/teams?
Faster support (“send me the layout that reproduces this issue”)?
What would be the required vs. nice-to-have features?
It is meant for end users to tweak and shared. It really is nice to have since they don’t really change their workspace frequent.
Thanks for sharing @sunsay00!
Yes, I was thinking the same. Most end-users will not change they default workspace, but there can always be some efficiency seekers and power users that can come up with a smarter solution a developer wouldn’t think of. Now will a normal conversatin during lunch be “Hey, guess what cool layout I have configured” maybe not, idk. But making them visible, maybe further tweaked by the platform team, and then distributed to other users sounds pretty cool.
We are extremely heavy users of workspaces
We have the notion of “global workspaces” that are considered the golden setups for particular use cases in our buisness workflows. These are created alongside developers and a few buisness analysts.
These golden layouts are then adapted by end users or just used directly, if a users finds a better way of working and its accepted by their team we then update the “global workspace” to this new workspace, they tend not to share between each other except for this
This is especially useful when making adjustment to the workflow, new app changes etc… as the new apps automatically load or changes appear directly in the golden layout
We also use contexts inside workspaces to have “shared” applications between teams that then have specalisations using the workspace context to save this so it opens in the teams context view to help with their ways of working
We have at times used workspaces for issues allowing us to re-create the scenario a lot easier
That’s extremely helpful, Steven!
Wondering if you do some tiny tweak variations for A/B testing or that would be overkill to maintain.
+1 here
As we allow users to modify the “global workspaces” creating their own versions we find that overtime they A/B test themselves without dev/platform intervention. As one users modifies and makes a better workspace/flow, others see this in the office and will try it out and slowly coming to agreement, they all converge near enough with a majority. At which point our users then reverse the process asking us to make the new workspace into the “global workspace”. For small tweaks/improvments we found this works incredibly well. This does rely on the fact we have co-located teams mainly in an office that helps enables this.
We do A/B testing from a dev/platform perspective for much larger changes where we are trying to adapt their workflow whether this was asked for by the users or driven by technical requirements. We tend to measure this in a very light way e.g. adoption metrics (who is using what workspace) and qualitative feedback from users to often choose the “global workspace” to be set. This is quite a rare event often when creating new systems so the time it takes to do this is never too much