Hi! Welcome to my site. 🙂

This post is an adaptation of an internal sharing I did in EDB in February 2020, about my experience in the CIID Interaction Design Programme in 2019, and my 5 key learnings from that crazy, amazing year.

The purpose of this sharing is to share some learnings from a very different world that I lived in in 2019: not Copenhagen, but CIID (Copenhagen Institute of Interaction Design). I hope that these learning points are useful for people. But I especially hope that this is useful for the creatives & rebels who are courageous enough to try changing within large organizations. This includes

  • designers
  • product managers
  • new business developers
  • new venture creators
  • strategy people
  • digital/org transformation people

Part of the challenge is convincing your peers that an alternative universe exists and is possible.

I am here to share with you that it does exist. It’s a world where things move at an amazing clockspeed, where it’s not uncommon for a project to go from zero to working prototype (often with user-research) in two weeks. But where most importantly, the core value is really about people as human beings.

This page is my attempt to peel back the onion, share some learnings I took away from this world. Hopefully, this provides some inspiration, and allows you to have a fruitful discussion. 🙂

This sharing is structured as follows:

  • Introduction to CIID and IDP (the programme I went through last year) – this is to give an overview of the programme and institution, as they’re quite unique
  • Key Learnings – which are primarily my learnings from CIID
  • How these might be applied to you & your organization – Reflection questions based on the key learnings above

It should take about 20 mins to go through. For maximum effect, I would suggest going through all the materials, including videos; I’ll provide some guidance around how much you should see (e.g. just watch until 1:07 or when you puke, whichever is earlier). Hyperlinks are provided for context.

Introduction to CIID & IDP

But first, an introduction to CIID, and its Interaction Design Programme. CIID’s reputation is (thankfully) quite well known in the interaction design and parts of the tech-world. When I was on the CREATE initiative and during the Design team’s Design Day Out, I asked someone (ex-frog design ED) about design school recommendations, and he said

“Go to CIID, don’t go to RCA. CIID folks can get stuff done and they know how to work in teams. RCA graduates are too theoretical; I don’t understand why they are so highly ranked. Ivrea is pretty good too.”
(Note: RCA is “Royal College of the Arts”; Ivrea is CIID’s predecessor)

Here’s the CIID intro-reel, which showcases a lot of CIID projects in an artsy-manner (it’s enough to watch until 00:42 when the guy jumps off the plane…):

CIID_Reel_Final_h264_1280x720p_Feb2017 from Gizem Boyacioglu on Vimeo.

CIID was co-founded by two ladies (both mothers) who met at the now-defunct Interaction Design Institute at Ivrea. They brought Ivrea’s curriculum into Copenhagen, founded CIID, and also brought Ivrea’s director Gillian Crampton-Smith to CIID as an Advisory Board member. They also brought in Bill Moggridge (IDEO co-founder, and editor of the canonical book Designing Interactions), who then brought in Bill Verplank (HCI pioneer).

Co-founders of CIID Bill Moggridge advised Simona to get funding, “so that the school isn’t filled with rich Emirati kids but is instead filled with the best students.” They advertised on their website while still seeking funding, and got 150 unsolicited applications for 24 places.

CIID initial advisors And that’s how the pilot year of the IDP came to be, more than 10 years ago.

The starting premise of CIID is to generate impact through design & technology, focusing on human centred design. Thus the curriculum is structured to focus on learning by doing/making/testing, and is very applied: most courses have at most spent 1-2 days covering theory, with the remaining week(s) focused on studio i.e. doing/making/testing. In fact, CIID is so applied, that they are completely not accredited, and yet the reputation is pretty high in the industry: two IDEO instructors openly said that the reason they taught at CIID was because we were a “significant pipeline of talent for (IDEO)”.

IDP 2019 Detailed Curriculum Every course culminates in a final presentation, where the team has to present (and the presentations are open to everyone/anyone, including people walking in from the street); often they have to give a demo of their prototypes.

The courses are also run sequentially, not in parallel across two semesters. So when we’re done with Intro to Programming, we’re done: next course.

Overview of IDP 2019 A key part of the curriculum are the two industry projects (see overview above), where we work with major corporates (like major retailers, or toy manufacturers. No names due to NDAs.) Our second industry project (more later) was intense, as this was the first year that they brought back CIID alumni to work with current students on actual industry projects! Huge doses of reality, but also a lot of fun.

In the words of an instructor (a professional designer who also teaches at California College of the Arts), “CIID is unique in the design education world, for curating the best cohort: it doesn’t always have the best individuals, but the cohort as a whole is great”.

My CIID Fam And my CIID family IS pretty awesome and diverse: 25 of us from 15 countries, previously doing a wide range of things. Silvia, for example, used to run the Liverpool Bienniale. Marc used to run IT support services for the Swiss-equivalent of Govtech. Laurin my flatmate used to design for a telco. Gaana used to work in Amazon. Joseph is an architect. Zoe is a freelance writer. You can see their profiles here.

Key Learnings Applicable to Most Corporates

I’ve thought a bit about the key learnings that could be applicable to most corporates, and I’ve structured them as follows: they are in order of increasing scale of implementation. For instance,

  • Learnings #1-3 can be applied through actions by individuals, maybe divisions, possibly all the way up to the org-wide level.
  • Learning #4 is applicable to teams, and above.
  • The last learning, though, probably requires org-level interventions, as it cannot be completely done by any single individual or even team.

#1: Speed, not Certainty

I’ve come to realize, the best way to not do something, is to discuss it.
– CIID instructor

CIID is very focused on quick iterations and speed, because one year is really not a lot of time. By design, the courses are 1-2 weeks long, full-time. And they are sequential: when you’re done, you’re done.

And this focus and sequencing are definitely key causes for the amazing speed. We’re not switching between courses in a day or week: it’s JUST that course.

And so you aren’t distracted by another course, project etc., which allows you to get pretty deep pretty quickly. The tight timelines also focus the mind wonderfully: nothing quite like a very tight and final deadline to focus the mind. There is practically zero switching cost of attention, because you’re fully focused.

How the CIID curriculum is NOT sequenced There’s a logic to the sequencing, which incrementally builds on previous foundations. For example, Introduction to Programming (where we learned Processing, a Java-based language) comes before Physical Computing. Why? Because you need to learn how to troubleshoot code (in computing projects), before you learn to troubleshoot code, mechanics and electronics (in physical computing projects).

What if we’re not certain what path to take or to do, which is like 95% of the time? Frequently, we will tightly timebox and test the most critical assumptions (more later); if that doesn’t work out, then we figure out either a solution or another test of a critical assumption. It’s just listen, build, test, repeat, listen, build, test, repeat… but with focus, and sequencing the biggest priorities.

And that’s what allowed my team of non-engineers to come up with the project of the Knife Game in three days. We spent the first two days of the week learning the basics of Python, Raspberry Pi, Linux, Unity (and C#), before the three days were spent brainstorming, building, testing, and trying different things, with a lot of very tight timeboxing. You can see the video of Gaana testing out our setup: this wasn’t acted out but was her real reaction.

#2: Test (by Doing, Making & Testing fast), not by Thinking, Writing/Talking, Arguing

One of my key learnings from CIID IDP is to build and test, fast and cheap. Like, build-in-10-mins fast.

Or fake-and-make-believe-to-test-assumption fast.

Or the-MVP-is-literally-paper-and-masking-tape cheap & fast.

I can hear your questions: What about the strategy? Planning? Positioning?

Sure, you do need to have those, but you know what? Those are often just grandiose words for assumptions that need to be tested. And to be tested in as cheap and fast a way as possible. That allows you to reduce your uncertainty as quickly as possible.

I learned that from the Introduction to Programming class.

During the second week of that course, Amit and I got stuck after brainstorming three different ideas for our project. We were supposed to create a game, and we had the three ideas below.

The three ideas: (from left to right) Cards for Humanity, Magic Mandala, Twister

We got stuck. We couldn’t proceed, because we didn’t know what to choose: all three ideas seemed interesting or valid.

So being good obedient Asian students, we went to the instructors to get their help with choosing the game. The instructors politely gave us their feedback on each game, and then said “it is your team decision: you guys have to decide” and walked off.

After a while (maybe an hour of discussion), we again went back to the instructors. One of them then asked have you tried it out?

Blank looks on our faces.

She then said,

Look, why don’t you take 10 mins to build paper prototypes, and to role-play each idea?
Take turns instructing the other, so you each get a chance to feel how the game is like.

So we did that, and quickly got rid of “Twister”: we both felt that it was interesting for the first 20 seconds but rapidly became stale.

Then we tried my “Cards for Humanity” game. As I continued on the receiving end of the instructions from Amit, I had a sinking feeling about my great idea… it felt like a copycat.

Then we tried Amit’s idea.
And when I was on the receiving end of Amit’s instructions (“Press L“), human animation (“when you press ‘L’, these shapes POP up “-shift paper shapes-) and sound effects (“…and the sitar sounds BOING BOING BOING”), I finally TRULY understood what he meant.

So I said, You know what? Screw my idea. Let’s go with yours.

Because testing the idea with a 10-min prototype allowed me to truly understand what worked and didn’t. All the arguing and reasoning couldn’t help me understand. Testing also helped me to let go of my pet idea, which was great only because it was “my” idea: the idea really didn’t work.

And that’s how we ended up with this project (which an instructor later told us was an example of Euclidean Rhythms) in about three days of coding, and a lot of sleepless nights and help from the instructors (just 1 min from each video):

#3: Learning, not Results

In most corporates, I think there is this focus on immediate results, and (imo) a lot less on learning. Learning somehow seems to be a secondary priority. I also suspect that learning is often seen as a “soft” activity, vs. delivering results!

In contrast, every CIID faculty member is almost always asking the question, So what did you learn from this? It doesn’t matter if you bombed, but what did you take away? How are you going to improve, using the feedback? Listen, build, test, repeat!

Why is this important? Because in the short-term, results>learning, but with compounding over time, learning yields >>>> results. The difference can be very big. I’ve this great quote from designer John Maeda’s latest book, which illustrates the power of compounded improvement.

If we make no improvements to a product every day for a year, or 365 days, then it turns out to be: 1 ^ 365 = 1 It remains exactly the same and unchanged.
But if we improve it 1 percent every day, then it turns out to be: 1.01 ^ 365 = 37.8. So constant improvements multiplicatively accrue to becoming roughly thirty-eight times better after one year. Thus, when you have invested in iterating constantly after the launch of an incomplete product, the benefits can be impressive. Let’s consider the alternative scenario, letting the product get progressively worse by 1 percent every day: 0.99 ^ 365 = 0.03 It ends up as 3 percent of what you started with on the first day of the year.

Borrowing from calculus, it’s the difference between looking at the function vs. looking at the function’s derivatives: looking at results just focuses on whether you’re there or not. But focusing on learning focuses on how fast are you getting there, what speeds up the fastness of getting there, which drives exponential growth in a very short time.

CIID also has both a structured and an open environment for feedback. This results in very fast feedback loops: it’s very common to ask for a few mins of feedback across the whole house, regardless of whether you’re asking Simona the CEO or sometimes even passing visitors. The feedback is critical, in the sense of it is critical for you to know, in order for you to improve.

It is also pertinent to note that the feedback goes both ways: we do an anonymized assessment of the instructors and the course at the end of every course. The feedback is often used to make changes to the programme, including switching instructors, changing course details (e.g. duration), etc.

The example of this learning is taken from my (only) individual course project, the GUI investigations. A faculty member looked at my first app screen that I had put together from scratch, and said

I can see that you lack the visual language to express yourself.

Which was a very polite way of saying that I sucked. But you know, I did. Listen, build, test, repeat!

I won’t deny that the next two weeks were a complete emotional roller coaster…. But the picture below shows the evolution over two weeks of non-stop grinding at the craft, with lots, and lots, and LOTS of feedback from the amazing instructors. I think it’s fair to say that I improved.

Evolution of my Weather App, from abomination to acceptable

The end result can be seen here.

#4: Driven (Normed) Flat Teams, not Obligated Individuals Following the HiPPO

In dozens of trials (of the spaghetti marshmallow challenge), kindergartners built structures that averaged twenty-six inches tall, while business school students built structures that averaged less than ten inches. The result is hard to absorb because it feels like an illusion. We see smart, experienced business school students, and we find it difficult to imagine that they would combine to produce a poor performance…. We focus on what we can see—individual skills. But individual skills are not what matters. What matters is the interaction (within the team).

– Daniel Coyle, The Culture Code

A frequent topic that I chatted with Marc (the 40 year old SVP of the Swiss Govtech-equivalent) is the challenge of working in flat teams. We’re both much more used to working in hierarchies. We both talked about the experience of having worked in “teams” that were filled with people who did things because they were forced to; HiPPO-led (Highest Paid Person’s Opinion) decisions; etc.

But we both agreed that the CIID team approach was often much better and faster, because you’re not waiting for someone to give an instruction or vice versa. And there’s something about passion-driven projects (interestingly, Paul Graham from Y Combinator also wrote about this, e.g. here), about missionary vs mercenary-driven teams You can only harness passion if you’re willing to let it flourish, and to follow it. And that often can’t be done in hierarchies but is better done in small flat teams.

And a key CIID “secret weapon” here are the Sherwins, specifically the Teambuilding course they ran at the start of the programme. Marc and I both felt that the one-week with the Sherwins taught so many useful teambuilding techniques & rituals that were WAY more useful than all the corporate trainings we’ve ever attended. Without this, I think the class of 24 of us would have just gone in multiple separate directions.

But the most critical technique and ritual was norming a team’s behaviour. Without that, you just have a collection of individuals; but with norms, you provide an API for individuals to interact with each other, forming a team.

The most impressive proof of this was when we had our second Industry Project.
For the first time in CIID’s history, alumni came back to form mixed teams of two-current-students with one alum. And for 75% of the mixed teams, the experience was AMAZING: as a classmate put it, it was “like having a classmate who went out, gained real life experience, and came back. It’s like having an extra brain!”

My Industry Project 2 team, with Fei (IDP 2019) and Clara (IDP 2017, HP Lead Service Designer) And that was due to the Sherwins’ teachings, because the first thing that almost all teams did was to norm. That allowed the teams to go from strangers to tight teammates in the two-weeks. In my case, working with Clara and Fei was amazing, and yielded inspiring results: the client was actually in tears after our presentation (where we showed an experience-prototype of a circular-economy service). And it was largely due to the fact that we normed, and had the same language to talk as a team.

I’ll leave you to browse through a couple of other slides from the Sherwins. The Sherwins’ materials can also be read through their book, Turning People into Teams, which is perhaps the best book that tells you HOW to do what their book title says. I think it’s the best book for team managers.

Another example of the power of flat, normed teams driven by their own passion and autonomy is perhaps my favourite project from my entire cohort. It’s called the Future of Password, and was built by four designers, all non-coders, in five days (watch to the end):

#5: Context, not Content

Content is content…. context is KING.

– Michael Kasprow, in Sketching User Experiences by Bill Buxton

What drives behaviour? Here’s a simple thought experiment for you:

  • Think about what you would say to your spouse/wife/partner, at a nice dinner in a nice restaurant.

Take a minute.

Got it?

OK, now imagine saying that same thing in the same tone to your boss while on a business trip.

For most people, the second would be quite funny/strange/possibly-nauseating, and definitely inappropriate.

But why? Because context is king, as it shapes your actions and behaviour. Context frames perspective and common understanding.

There are different layers to context, some of which are:

  • Culture & norms – expected behaviours (as above)
  • Roles & structure – hierarchical vs. flat
  • Infrastructure and Architecture – physical (e.g. layout of offices) and digital (e.g. G Suites)
  • Size of the organization – Dunbar’s number
  • Etc.

It’s beyond scope to go into the details of what makes context. But suffice to say that what works for one context might not work in another, and the variation could be due to something as simple as different team norms (for example).

At CIID, the context is largely designed to support speed and learning: the organization is very small; each IDP class is capped at 25; the class is kept as much as possible to the same floor so that it is easier to interact with each other; everyone can usually see everyone else’s folders and work stuff on Slack and G Suite.

And because context has such a huge impact on behaviour, my problem in my final project (which you can see here) was that, not everyone in the school understood the context of the location I was solving for, which was a nursing home. There were a lot of important nuances in the solution, which wouldn’t make sense if you didn’t understand the overall context.

Thus, to convey the context, I created a video, showing actual footage of a typical “day in the life” of a nursing home caregiver, to show just how action packed their days were.

(You can watch until 4min29s). The whole final project can be seen here (best viewed on desktop).

How could these learnings apply to you & your organization?

I’ve shared a lot: thanks for making it this far! The following are just some reflection questions for the discussion:

#1: Speed,
not Certainty

  • What are the biggest barriers preventing YOU from focus and sequencing of tasks?
  • What balls would you like to drop? How would you drop them?
  • What are your 1-2 priorities that will unblock other dependencies for yourself and others? How would you sequence your priorities?
  • What are your 1-2 priorities that are possibly blocking other people’s dependencies/priorities? How can you find out?

#2: Test (by Doing, Making & Testing fast),
not by Thinking, Writing/Talking, Arguing

  • How could you tightly timebox and test your most critical assumptions quickly and cheaply?
  • How could you build, test, do more quickly and cheaply in ten minutes?
  • What are the barriers stopping you from doing this more? Who can help remove those barriers?
  • What objective test criteria or key results could you use for your tests, beyond HiPPO?

#3: Learning,
not Results

  • How could we curate the right conditions to enhance learning feedback loops in ourselves, teams, Divisions and the whole org?
  • How can we redirect our focus from immediate short-term results, to compounded learning?

#4: Driven (Normed) Flat Teams,
not Obligated Individuals Following the HiPPO

  • What team rituals do we have right now, that the whole team practices?
  • What individual habits and team rituals do we need to keep, change or dispose?
  • How does your organization’s current context and systems support driven normed flat teams? What’s missing or barriers?

#5: Context,
not Content

  • What infrastructure and architecture does your organization need to have to cultivate speed, learning, teams etc. above?
  • What values will we need to hold each other up to, in order to support the above?
  • Who in your teams exhibit those values that support the above? How are they recognised and how are these values signalled within your team?

Thank you for reading this far!