CIID Learnings for EDB

Hi! Welcome to my site. 🙂

First, a bit of an orientation and introduction: this is a page that is password protected, and only visible to CM members as part of the CM sharing. If you’re not an EDB CM member, or minimally EDBian, please leave as you’re not the audience.

This page contains materials that precede a scheduled CM discussion on 27 Feb 2020. As the content is heavily interactive (as you can see from the images + video embeds below) and as none of this is confidential (it’s all public domain, except for my comments on applicability to EDB and on EDB), I’ve decided to try this format instead of a 900MB slide deck…

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). 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 (sometimes complete with user-research) in two weeks. This page is my attempt to peel back the onion, share some learnings I took away from this world, and to spark a discussion to see how we could replicate this in EDB. Hopefully, this provides some inspiration, and allows us to have a fruitful discussion. 🙂

For CM members who attended my brownbag, I have actually reworked this content, based on the evolving feedback from the brownbags. So hopefully this is also something new and interesting for y’all too. 🙂

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 Applicable to EDB – which are primarily my learnings from CIID
• How these might be applied to EDB – Reflection questions based on the key learnings above
• My research project – an overview of the three-month project I am undertaking in EDB

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 tech-world. When I was on the CREATE initiative and during the Design team’s Design Day Out, I asked someone (ex-frog design) 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 (thanks for understanding, Dawn Lee!), 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. -gulp-

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, where we work with major corporates (like, hypothetical examples, major furniture 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 EDB

I’ve thought a bit about the key learnings that could be applicable to EDB, 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 off 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, 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.

My transformative moment came from the Introduction to Programming class. During the second week, 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 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 look 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.

And 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 EDB, I think there is this focus on results, and (imo) a lot less on learning. Learning somehow seems to be a secondary priority. I dunno if it is still true, but a few years back, my wife told me that EDB apparently has a very shitty reputation in the corporate training industry. We are renowned for having people who turn up late, skip training for meetings without apologizing, or who are just working in the middle of corporate training. 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 when we first convened, 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 the other slides from the Sherwins, which they had given permission for me to share with EDB (I had previously sent it to HR and SP). 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 that.



---

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 RO while on a trip.

For most people, the second would be quite funny/strange/possibly-nauseating. But why? That’s because context is king, as it shapes your actions and behaviour. This is probably because 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, but suffice to say that problem-solving in most contexts is really not as straightforward as we think it is, because 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 it was.

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

How could these learnings apply to EDB?

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 SGS or 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 EDB’s current context and systems support driven normed flat teams? What’s missing or barriers?

#5: Context,
not Content

• What infrastructure and architecture does EDB 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?

Research Project

My research project is focused on understanding the causes of employee fatigue of EDB officers; for the causes that are caused by EDB’s IT systems, then this research will provide a prioritized list of projects for ITD to work on to address these causes (where applicable).

Specifically, I think we don’t fully understand the pain points raised within the context of the officers’ day, and I’m trying to piece together a “day in the life of an EDB officer”, so that we can understand the pain points within that context, not in isolation. This is so that we can increase the chance of addressing the right problem, rather than (as a meditation teacher once said) scratching your head when your itch is in your bum.

I have already created a live TEAMS channel to share my research as it evolves, and I will send that separately rather than post the findings and materials here.

Thank you for reading this far!