Yes, We can host collaborative Design Workshops Online

Gayanjith Loku Pathirage
6 min readMay 2, 2018

It was the start of a new software development project at Cambio Healthcare Systems! I was included in the team as a Business Analyst. A part of the team was in Sri Lanka and the other part was in Sweden.

First of all, let me tell you what Cambio is. We are a company that provides healthcare solutions by designing and developing world class Electronic Health Record systems and related products (ex: Cambio COSMIC).

So what is this new project?

Well, it’s about giving a new look and improving the performance of the product that is responsible for patients’ medications. And the toughest part is that even a small change in this product can lead to huge reactions of end users since it deals with the lives of people. One wrong dose shown on its User Interface can result in a loss of a life.

So, long story short; we need to make sure that we provide the best solutions with the highest quality.

The Challenge: How to design collaboratively?

Since the designers of this product improvement are based in 2 different locations geographically, we needed to find effective methods that can be used to design collaboratively, online.

Many believed that it is absolutely necessary to be located closer to each other in order to do collaborative work successfully, but our experience in this case suggests that it is only a bonus.

Understanding the problem

The requirement analysts and designers located in Sweden were able to go out into the field, interview end users, observe them and gain a lot of insights which were very useful when it came to generating ideas to solve their problems with our current product. They invested a lot of quality time understanding the actual needs of the end users without relying on assumptions.

It’s always necessary to have a thorough understanding of the problem we are trying to solve before going about it. This will reduce a lot of rework and frustrations.

Generating ideas

Since we have identified, prioritized and defined the problem that we should solve, then it was the time to try solving it.

We wanted to treat everyone in our team as Designers! Software Engineers, Product Managers, Product Owners, Testers… All of them! We wanted everyone to try to passionately solve the problems that our awesome researchers dug out.

We wanted different eyes on the problem.

We planned a 30 minute video conference to facilitate an online idea generation workshop with the participation of the whole team who are engaged in improving this product. Prior to opening up our minds to find solutions for the problem, we discussed about the problem and the technical limitations that we have in our product and made sure everyone understands the challenge at hand so that they will focus on solving a defined problem which makes the task a bit easier.

Even though we tried to define the problem as finer as we could and we tried to let everyone feel and understand the problem that we were trying to solve, we still felt that we could have done better in this case. Next time we would probably do a separate workshop to present our research findings.

Ideate Method #1: Crazy 8s

The first Ideation Technique that we tried was ‘The Crazy 8s’. Surprisingly everyone took it really nicely without any hesitation and we were able to generate a lot of ideas at the end of the session in 8 minutes. 8 ideas per person, to be precise. We went for the quantity, not the quality.

At the end of the workshop, we asked everyone to pick the best idea that they have generated (individually), build on it and in the next meeting present us an One Big Idea that would solve the problem or the design challenge. The workshop ended with a lot of new lessons learned by everyone and with some curiosity troubling the mind about the next workshop.

Ideate Method #2: 3-step Story Board

https://library.gv.com/the-product-design-sprint-diverge-day-2-c7a5df8e7cd0

After the workshop, I wrote an email to everyone about how to present their best idea and as Jake Knapp tells in his book, ‘Sprint’, I would like to call it ‘The 3-step Story Board’.

Since most of us were new to these methods, some good knowledge bases were provided to the team, related to the design methods, such as DesignKit and many YouTube videos. The non-techy people were asked to talk to the software engineers and testers if they need any help with building up their idea in order to let them have a good idea about the feasibility.

Ideate Method #3: Design Critique

In the second online video conference, we presented our Big Ideas on 3-step story boards. After one was done presenting, the rest of the team started the critique! Ishan, who was the Software Architect, questioned the technical feasibility. Linda, the Requirement Analyst, questioned whether it would actually meet the end user’s needs.

The conversation went on and at the end of the day we were able to identify the strengths and the weaknesses of everyone’s solutions. At least, I was able to identify how complicated my solution was.

I wanted to let everyone vote for the features or ideas that they liked in others’ story boards but unfortunately I could not come up with a proper method for that since I was more used to voting silently using dot stickers physically. Therefore, we had to circulate an email stating the favourite ideas or features that we saw during the ‘Design Critique’ session.

I’m sure there should be better methods that can be used at these online workshops for voting. We’ll surely use them in our next workshop.

Current situation

With this output generated from these workshops, now we are going to pick 2 or 3 best ideas and then build them up to 2 or 3 concepts that would solve the design challenge.

Our target is to prototype them and test them with a few real users to see whether they like it or not. Based on the feed back, we will continue to refine the concepts until we are in a position to pick one and implement. Obviously, with one eye on the deadlines.

All this effort was put in, in order to give the best for the users of our products. We want our products to be seen as tools that ease their work rather than an overhead they have to live with.

Picture courtesy: The Simpsons

--

--