Tips for Running a Remote Design Workshop

Advice from an Experience Design Lead

What makes a remote workshop so different? And how can you make it work for your team? A practical guide for running remote workshops – specifically design workshops – that work and deliver results.

Work from home policies and remote collaboration don’t need to put workshops on hold or detract from their value. But online workshop do you need to be rethought in a few ways to ensure the business outcomes are achieved.

There is plenty of advice available for those looking to run any kind of a virtual workshop but I wanted to talk to the special requirements for a design workshop. Below I will guide you through how to facilitate a remote design workshop so its most effective.

How are remote workshops different?

First, let’s talk about how remote workshops are different to in person workshops.

  • Reduced depth of conversation: intonation and body language carry significant amounts of meaning but these pretty much vanish during an online workshop. Even with videos turned on and good internet it’s easy to miss visual cues.
  • Increased levels of distraction: emails, text messages, Slack/Messenger/Teams, your dog in the room and learning new tools are all the result of not having a dedicated workshop space.
  • Reduced effectiveness of tools and methods: post-it notes and whiteboards take on different forms when online and sometimes these aren’t as effective as in-person.
  • Reluctance to actively participate: Creative teamwork takes trust and it can be difficult to build trust over a remote connection.

Advice for a successful remote design workshop

I’ve been running design workshops (in-person) for many years now but we recently ran a design workshop for a new client and I wanted to share the extra steps we took to ensure high engagement from all participants. Let’s dive into those now.

General Advice

  1. Prior to workshops, advise people to be on time, joining midway will derail the agenda for the group and usually ends up causing topics to be repeated.
  2. Organise a workshop assistant to lookout for participants who wish to speak that may be missed by facilitator. Facilitator may miss participant’s body language signs in the video grid while working with the tools, and they may also be unfamiliar with the introverts in the group. The workshop assistant should know all participants and encourage equal contributions from everyone in the group.
  3. I suggest that participants bring and use a mouse and not use trackpads for interactive workshops. We’ve seen some participants having issues with clicking and dragging items around on trackpads.
  4. I highly recommend participants connect to an external larger monitor if they are working on a laptop as it can help with viewing smaller details on the screen.

Miro-specific Advice

I’m a huge fan of Miro, a collaborative online whiteboard platform designed for remote and distributed teams. But if you are going to use Miro then I recommend familiarising yourself and other participants with the platform in advance of the design workshop. A few tips to help with this:

  • Tutorials are required for the first workshop participants.
  • Conduct an tool-familiarisation exercise to get participants to write their name on a sticky note then move into a designated area in a workspace.
  • An ice breaker is required for the first workshops to ease participants into doing workshop activities. We love a simple ‘price is right’ guessing game of three items which we prepared in advance. It’s not too hard, provides a little competition and fun without being so technical that some group members won’t be able to participate.

Running a remote workshop requires additional levels of focus and leadership to ensure engagement and participation from all attendees. To summarise:

  • Set up ice breaking activities
  • Over communicate
  • Set ground rules to reduce distractions
  • Ensure sufficient breaks to maintain engagement
  • Document using the tools that meet your workshop needs

Design: Your Questions Answered

Following on from our recent posts A lesson in design processes for 2020 and Design: But I still have a versioning problem, our design expert, Chung Sham is answering a few of your design questions.

Don’t see your question on the list below? Pop it across to and one of the team will send you a reply and update this post.

Let’s get into our Q&A with Chung Sham.

Q: You mentioned previously exposing design elements in Sketch. How manual is you needing to expose all of that stuff? The button does not have the font and the specific hex codes and all that sort of stuff. Is that something that you would manually do in Sketch?

Chung: No, there is no process or anything additional that we have to do as part of the design. Sketch, because it is a JSON-encoded file, is where it is getting all this information from. We just hit publish and InVision decouples everything. So, it is a smooth process. You can sort of see here with the text label, we have got the font family, the font size, all that sort of stuff, no additional work on our end.

Q: What you shared is an out of the box Sketch set up. Could you make your own  core style sheet page and then have your H1s and feed into your design?

Chung: The short answer is yes, you can set up a Sketch file and put all your H1s, H6s or your icons in a Sketch file and then have that in Abstract and push that into InVision.

The longer answer is that there are other tools available that will help with creating a design system, because then, once you have certain design decisions about why an H1 is the way it is or what fonts were chosen, you can put comments around it and expose that in more accessible way for a website or something like that rather than for Abstract, but yes, is the short answer.

Q: Thinking about responsive designs. If you are designing a component, you end up with different versions, one is for desktop tablet and another for mobile. Is that for just one design file? Does it actually have any tools to go? Okay, his container needs to drop it into the next slide. And can you do something like Flexi design or really? 

Chung: There are plugins that will allow you to set up Sketch files and build some of those smarts as you change, what we call in Sketch up boards, which is basically the working size of your design. You could start with a desktop, build in some of those smarts using a plugin, for example Anima. And then that will adjust the designs based on the breakpoints that you want. Now, that takes a little bit more work, obviously, because you do have to bake in those designs. So you are not just designing on that up board itself.

Another option is you could have multiple Sketch files at different breakpoints. And just like what you saw with Abstract in the second post, you can have those in different branches. Someone might be working on mobile, someone might be working on desktop. There are a few different ways you could manage that, and every team in every organization is different, but there are ways to do that. 

Q: If we end up having multiple Sketch files for different breakpoints because technically, some of those can be not achievable. For example, some designers just go crazy and then just move stuff around in mobile, not making it responsive. This increases the complexity of development. Do you come across any of these challenges and how did you sort of overcome them?

Chung: Yes. So that comes down to, I suppose, the design practice and the designer themselves. What you saw before is the way to manage those design decisions. I think the example would be that you would have three different uploads, freedom files because that just visualizes how certain elements or components should behave down to different breakpoints. And you can share those with the client as well. Whereas if you do bake it in and inside Sketch, you do have to change the artboard within Sketch to be able to see how that behaves. So a lot of times, it is a lot easier for clients to visualize how these three different breakpoints look like and then have comments be placed against it in something like InVision.

Q: Our designers might have ideas around placement. Do you see that more as a collaborative experience between technical and the designer team to go, “Yes, we have worked together to produce this design but there could be technical difficulties and we might need to sort of, it goes kind of both ways.”

Chung: There are a few different deliverables that we designers like. If it is quite a complex component, you might want to start off with a discussion with the developer first, create a wireframe, have a discussion around how that actually behaves before creating a high fidelity version that you would see in Sketch. This is what I’d call design practice for the individual designers, rather than the tools to help solve that. 

Q: Let’s say you have a senior designer on the project. Then you bring in more junior designers who are still onboarding and still learning. Do these tools have any provision for you as the lead creative person to place restrictions on things or warnings, let us say? I guess you’d call it an approval workflow but for alerts.

Chung: There is no out-of-the-box function that might facilitate that in Sketch, it will be a lot of basically, communication. But Abstract would be a place where – such as the request review –  so if they complete a task, send a request review to whoever the senior lead is and then they can actually see and edit that file if they need to or send it back to the junior designer before merging it back into a brand new milestone.

And we are starting to see plugins for Sketch where if a designer enters a different font, it will say, in real-time, “Hey, this is not part of the design.” But that is still in its infancy, but it is moving towards something like that.

Don’t see your question above?

Pop it across to and one of the team will send you a reply and update this post.

Design: But I still have a versioning problem

Following on from my recent blog post, A lesson in design processes for 2020, I wanted to address versioning in design.

Design working shifts are history

Sketch files are managed locally and we still have the problem of how to manage versions on different people’s machines. 

For example, you could try design working shifts. You might have Jane, who will work on the website file from nine to twelve and she will make edits to a couple of banners but Jim will work on the website after that from twelve to three because he is going to make changes to the footer. But then Alice might need to work on the main navigation and she will take that from three to six.

This isn’t good enough. We need something that is better able to:

  • Manage our files.
  • Work together in parallel. We do not want to work in design shifts.
  • Preserve the thinking and history of designs because clients might ask for something and we will make a change, but then another designer might be freed up and they will jump on board the project but they might not know the history or the context that they are jumping into and make changes that aren’t based on current information.
  • Communicate and collaborate
  • Scale: onboard new team members, preserve team knowledge and have context around all design decisions

This is where Abstract helps

Abstract is one place to manage your design versions and collaborate in the one platform.

We have borrowed certain concepts like branches, you have got master. We also have merge branches as well. And of course there are tools around that offer version history, but in terms of version history and version control, it is not exactly the same.

A quick definition: version history vs version control

Version history is still working on a single timeline, and this sort of goes back to that design shifts problem mentioned in our first design blog post. What we really need is version control where multiple designers can work on different branches and they can’t intermingle with other people’s work. And then, we merge that back into the master file after we have all decided which ones meet the requirements.

Until now, designers have mostly been working with version history. Version control is common for developers but is a very new but powerful concept for designers.

Quick recap of the benefits:

Single source of the truth

  • All work is located in one place can accidentally be overridden or lost.
  • Master files, they are all centralized.

Parallel design

  • Multiple designers can work on the Sketch files without overwriting each other’s works.
  • Designs are branched, committed and merged.


  • It is no longer my file. It is our files.
  • All design work is visible, and you can track progress and changes, as well as see feedback and understand context.
  • Designs can be reviewed and approved before merging.
  • Create a smoother transition from design to development.

Check out the next blog in the design series: Design: Your Questions Answered.

A lesson in design processes for 2020

Today, I’m talking about the tools and processes in a design process, and I’m going to specifically cover the past and present of design processes.

Exposing design tools and processes can improve collaboration, provide a smoother transition from design to development and provide insights into how designers work. Because there’s no point building a bridge from two sides if they don’t align once they reach the middle.

What design used to look like

In the beginning, there was only Adobe Photoshop. A traditional process would have seen a designer send JPEGs to a client because the Photoshop file was too large to share. In response, the client would provide feedback in a Word doc and the designer had to muddle through trying to align the design in Photoshop with the client’s amendments. Versioning and latest files became a problem. As a consequence, the aesthetic output was impacted.

Keep in mind that Photoshop was designed and built around photography rather than graphics. It sort of did the trick when it came to web design, in that you could draw some stuff and put some text into your designs but in reality it wasn’t meant to be a digital design tool. It wasn’t designed first as a digital design tool.

A smarter working environment for designers

What we needed was a smarter working environment built from the ground up specifically for user interface design or digital design.

What designers really needed was:

  • To expose the structure of design work
  • More optimised files, faster to open and easier to share

Along comes design tools such as Sketch…

…and InVision.

But what is Sketch? An app built for digital design. It is a local application on a Mac. Edits are non-destructive, so that is different to how Photoshop works. If you want to redraw a shape, you would have to start all over again, and you cannot really change things as easily as what you would be able to do in Sketch. Much smaller file sizes; we are talking about megabytes here. You could have files from ten megabytes, twenty, but certainly, we are not talking about five hundred, unless you add large raster graphics or photos in there. The documents are stored as ZIP archives. The Sketch file format is actually just encoded JSON data. That allows for better third-party integration to plugins or other platforms such as InVision. There is a whole bunch of plugins, and Sketch is super-fast compared to Photoshop.

But where does InVision fit in? It is a cloud-based hosting platform for designs. The reason why you would want to combine InVision and Sketch is it allows you to create interactive prototypes.

It is a shared environment for collaboration. You can put comments in context, and we can share these screens out to clients. There is also smart outputs, but why we want that is developers can inspect the actual structure of the designs and also get creative assets like SVGs from the actual design files itself, rather than send it by email or zipping it up as what we used to do back in the day. So, it is one place to host all your designs.

Example 1: No such thing as dumb JPEGs anymore

Let’s say you draw a shape in Sketch. It is 212 pixels wide, and it is 212 pixels high. I can change that to, let us say, 200 pixels and it would just change dynamically. Now, it is smart in a way that these fields are not just inputting values. Sketch recognizes some conditions as well. So, let us say I wanted to make this with an extra 100 pixels wide. I could type in 300 pixels, but instead, there are calculations. I could do +100, and it will make that three hundred. I do not have to actually know what the end result is. I just need to know what I want to add to it. Just like with plus, you can also minus as well.

It also recognises different commands. For example, I might want to add 100 to the left only so I add a letter, say ‘R’ and that locks the Right side. The shape them adds to the Left side only. You can measure and have consistent spacing, which is really good for designers because we do want to have consistent spacing for certain elements to match up to a grid.

These are all decisions that we have been baking into the designs.

This is all living on my local drive but how do I share that?

There is a little plugin that InVision has made called Craft. I have made a prototype called, “Awesome Website,” and I can go and publish. That goes off into the cloud and will publish this image into that project.

For example, I have this component called, “Hero Banner” and I have got the modal in here as well. If I click into the Hero Banner, anyone that has the shareable link will able to see this banner. 

But did you know this isn’t just a flat image? We can create an interactive prototype from this file and clients and anyone with the shareable link can start adding their feedback. No more Word docs back and forth! Simply, click on a spot (aka hotspot) and add comments. Now those comments are a part of the project and there is context. In turn, a designer can return to the file, know straight away what is being asked of what, go into build mode and implement the change.

The designer then returns to Comment mode and hits resolve to say, “Yes, that is done.” We can track all the history of this, and all the design decisions.

Quick tip: This is not just a JPEG image for developers as we do have an Inspect mode. You can expose many different design elements, for example:

  • What is the width
  • What is the height
  • What is the grid width columns and the gutters
  • There is also the colours
  • If there are any assets available for download
  • The structure of the pages and the layers on the left here
  • There is an image, a background, content too

You can also grab the code. It is not just a dumb JPEG image, there is a whole bunch of code that gets pushed up through into the cloud and gets decoupled. You can also change what the code is. For example, you want to use less SAS objective-C Swift code as well. It is all in here. So depending on what the project type is, you can switch that up yourself.

Example 2: No such thing as dumb JPEGs anymore

Let us say we go to any website (but today let’s say that website is, grab a screenshot. We’ll then copy/paste the SVG image into Sketch.

Because this is a smart working environment, it is not a static or dumb image. In Sketch you’ll see all of the exposed different elements from the screenshot: colours, texts, font sizes, etc.  

Next in our design series, I’ll be talking versioning control.