🤔 Is it possible to build a digital conference from scratch in two weeks?

(Spoiler: No, no it is not.)

I’d like to start with a disclaimer: turns out it wasn’t possible to build an online conference from scratch in two weeks. We were well-meaning but deluded to think we could build out a website, assets, brand, and strategy for a digital conference in two weeks. Not during a pandemic, with a team of three, sometimes four, people who all have other work and other worries. But we did build it in six weeks which is pretty damn good. Here’s how.

---

Building a digital conference

Part One: Proposal

On April 14th, I got a message from Nicole on Facebook. I vaguely recalled Nicole worked at a cool think tank and she vaguely recalled I worked in something to do with websites. We got talking about Nicole’s idea to run an online festival as COVID-19 restrictions forced her company to cancel their face-to-face workshops and classes. The hypothetical question of ‘Is this idea feasible, who would you need to hire, how much would it theoretically be’ very quickly turned into a request for a proposal.

I mentioned my friend Julian as a potential collaborator and developer. He had just moved to the US so the time zones were tricky but I’m not one to shy away from a 2:30am message. 

Julian: a private person and over-user of exclamation marks

I suggested Julian because we worked together in Melbourne where we learned to communicate well and became good friends. He’s moving into the development field, but he was originally a communications manager, video producer, and generally jack of all trades. He’s also the most elastic worker I’ve ever met. He can pivot to any change or challenge thrown at him. And I suspected there would be challenges because the timeline was toightttt - end of April for delivery. 

We bat the idea back and forth like a couple of kittens playing with yarn. I learned more about Nicole’s job. She’s a regional manager and programme co-ordinator for States of Changes (soon to become known colloquially to me as SoC). States of Change is a public innovation collective. In their own words, because I don’t have the words to describe their high-level operations, they “want to build the capability and culture of governments to practically deal with the complex problems they face, and to strengthen the community of practice around public innovation”. Their idea was a learning festival. A three-week online symposium that would allow SoC and their partners to share practice while in lockdown. Their audience is spread out across the world and the whole shebang would be coordinated online. 

Over the next few days, we asked and answered questions and came up with a range which Nicole took to her team to see if this idea/budget/timeline was feasible. I arrived at this budget based on hours. Both Julian and myself were working on other projects (his dance card was nearly full before we even began) and me with other clients. So we figured out a rough number of hours we feasibly could put into this project within the timeline. 

An aside: one of the toughest parts of being a freelancer, in my opinion, is quoting. I’ve become better at it over the years but it’s still hard. One day I stumbled across a pertinent Freakonomics podcast episode called ‘Here’s Why All Your Projects Are Always Late — and What to Do About It’. Steven Dubner talks about a phenomenon called planning fallacy:

“...the planning fallacy is a tendency to underestimate the time it will take to complete a project while knowing that similar projects have typically taken longer in the past. So it’s a combination of optimistic prediction about a particular case in the face of more general knowledge that would suggest otherwise.”  

Optimism, society rewarding overconfidence, not accounting for our low impulse control leading to self-procrastination can all conflate and lead to us creating really wrong quotes and timeline estimates. My quote of AUD$3k - 5k for this project would end up being off by AUD$2.5k - 5.5k, a significant amount. We should have quoted AUD$7.5k - $8.5k. We did end up padding our final budget offer with a 10% buffer, our attempt at account for the unexpected, and we secured a little more funding as we went. But it was a lesson. A good client isn’t a guarantee that a project won’t blow out of scope. In this case, the good client is actually why the project went over scope - we wanted to more for Nicole.

View fullsize

An email from Nicole clarifying the budget.

Anyhoo. The next step was drilling down into specific deliverables, refining the budget, and getting a proposal together. Nicole sent us this brief.

I had always factored in a few hours of time from our friend Matthew Blode, a wunderkind designer and developer we had both worked with in Melbourne. We weren’t 100% sure how we would use Matt, whether it was design or to look over Julian’s development work as I would be next to useless at that task, but we knew he would elevate the project. We were all pretty stoked at the prospect of working together again.

We sent a proposal back to Nicole that outlined our team, the stated user and business goals of the project, outlined assumptions we had made when developing this proposal, lists incidental costs we might encounter and would be responsible for them, optional extras, outlined two packages at different price points, the processes we would follow, and rough timelines for each package.

And on the 20th April, we received confirmation that our proposal was accepted. Cue celebratory GIF exchange.

“Nicole. Thank you for noticing my natural sense of playfulness, I am happy to work with someone who gets me. Best, Imogen.””

Why have I dragged you through this tedious process before we even get to the doing of the project? Because this IS the project. Proposals don’t magically appear. Most people don’t have a generic number they can give you for your unique project.

Proposals sets the scene and, more importantly, the scope. It’s a slog even at the best of times. This is true even when the client is great and the project is exciting and the timeline is tight. It takes a lot of coordination and expectation management and checking in with people and their various time lines. Proposals take work. Once more for those in the back: proposals take work!

---

Part two: Strategy

This process of scoping the SoC learning festival was reasonably smooth because Nicole is an excellent communicator, was aware of managing her own expectations, and we’d been transparent about the budget. But immediately, these issues complicated things:

• Timezones were already troublesome and we hadn’t even started the work. We couldn’t guess how difficult this element would be (oOoOooo more on this later);

• Nicole had never worked on a website before and she was to be our main contact. It meant we had to find a balance between asking her to trust our decisions (time saving) and educating her enough so she could confidently make her own decisions (relationship building);

• The sessions and agenda for the festival hadn’t been finished. They hadn’t even been started. As far as we knew, the format for sessions could be quite experimental and might affect the build of the website if they required special interactive elements. We didn’t have any fat on the budget for these kinds of additions and it’s not a good feeling to deny your excited client their good ideas because of money. Nothing for it but to wait and see.

Workshopping the conference

The first question Nicole and I asked and answered, during the strategy phase, was ‘Does this festival website sit under the States of Change website’?.

It was immediately obvious that this creature needed a room of its own. The SoC website was built on Craft CMS, a versatile CMS (content management system) that requires a specialist developer. That cinched it for us. Julian isn’t a Craft developer and the budget didn’t extend to finding a Craft developer to work with us. We went with a new build on a different CMS.

In our messages, Nicole used the word microsite to refer to a website that wasn’t built on Craft CMS and linked to the main SoC site. Terminology is a friction that comes up almost immediately and the way you deal with it, the way clients respond to questions about terminology, is a useful indicator of how things will go. Microsite is a fine word to express what she meant - a smaller, discrete website but still related to the parent company website but functions for one particular event - but it didn’t make sense in my vocabulary. My spidey sense was tingling and I wanted to make sure we were on the same page.

We intuitively began to build a dictionary of mutually-understood terms with exchanges like these. I find it’s easier to go through life without thinking your terms of reference are absolute and making everyone align with you. 

The first thing we did was run two workshops to figure out the big unanswered questions.

Note: you can largely skip this bit, it’s not integral to understanding the development of the project. But if you’re interested to know how workshops operate and what you can expect to get out of them, this is for you.

Nicole and States of Change were running their own workshops to plan the content while we figured out the website. Nicole referred to this process as ‘building the plane as we fly it’. A little bit visceral and horrifying but we were excited to work with a client with such a self-aware, experimental attitude. 

The first workshop went down on the 20th April, the day the proposal was accepted. I was able to facilitate straight away and base the content on previous strategy and project mapping workshops I’d run. The only issue was time zones. I’m currently based in Hanoi, Vietnam (GMT+7). Nicole is based in Melbourne (GMT+10). And Nicole’s colleague, James, would also be joining us from London (GMT+1). So we found a time that suited none of us and did the workshop then. 

James and Nicole are a great workshop duo. We worked surrounded by tea, coffee, slices of cake (mine), and with dogs pattering around in the background. We started by revising the short and long term goals for the project. The objectives stated in the original brief were already evolving.

These were the original user and business objectives:

These are the user and business objectives we developed in the workshop:

View fullsize

View fullsize

Now this is probably the right time to say - this isn’t how UX works. We’re choosing the user goals for the users which is a big no-no. Who are we to say what potential attendees want out of this festival and, therefore, how we should structure the website to suit them? Ideally, we’d run user testing with bonafide potential attendees and ask them what they want. But. The reality is that user testing is expensive and takes a while. With such a short time-frame and an evolving brief, we decided to skip initial user testing. The way SoC framed this, outside of time and money restrictions, is that they see this festival as a potentially ongoing project. This first iteration doesn’t need to be perfect. This time round, they’re just validating the idea. So framing the festival as the first of many helped us understand the website build as a prototype not a polished product. 

Next we did audience mapping. Who are your tertiary, secondary and growth audiences? Nicole and James had a really clear idea of who is in their community. The demographics of their audience tend to be dilute. It’s not so much a group of people united by an age bracket or a job title, but people with specific attributes. I thought and asked about who these audiences were, the kind of energy the audiences bring, what they would watch on Netflix, how they would act at work party. Because SoC are in the business of buying and selling thought processes, they took to this like ducks to water. The emotive descriptions gave us a clearer idea of who would attend these events.

Tertiary audience - we called the tertiary persona Charlie.

Secondary

Growth

Some defining features of their primary audience: they have time. They want company. They like a more unconventional way of doing things. After two hours of wringing out their brains, they were fried. We called it a day and scheduled another workshop the next day. 

I messaged Julian to fill him in. 

We hadn’t spoken explicitly about roles in this project because we’ve worked together a lot. The assumption was that I would lead the strategy, the content management, and largely project manage the client and Matt. Julian would be my second pair of eyes on the strategy, handle the development, and would be directly in touch with the client throughout the development. We both track our hours so we can keep track of the budget and also so we both get fairly compensated based on hourly input. The contract we’d unconsciously developed while working together is that we stay across each others work and be actively invested, even if we’re not the one who’ll be executing the task. For us, this meant diligently reading over meeting notes, reports, chiming in at weird hours to request a second set of eyes on something.

While there are lots of traits I want in a collaborator/work partner, this tops my list. Knowing your team mate is going through your work and checking it to the best of their ability is so comforting and usually, when they have a broad skill set like Julian, adds a lot of value. When you work in small teams, you usually don’t have the budget to double up on skill sets and working with jacks-of-all-trades is so valuable.

In the next workshop, we started out with some functionality mapping. This is an exercise I learned from Francis Nicholls-Wunder and Nick Parker at my previous job with Light Creative. You map out all possible ideas and features you can think of for the website. Then you rate them based on cost and necessity. At Light, Fran would map these features on a coordinate grid and draw a diagonal line up the grid at the end. Everything below the line, that is lower on cost and higher on necessity, would qualify as a must-do. Because of the flow of this project (the need for the budget to be set before we started), we had already determined the cost. What we were trying to do now was determine which pieces were important enough to fit into the budget. It’s not the best way to do this exercise but we made do. We rated the features from 0 - 4.

0. Not needed. 
1. Would be nice to have but not essential
2. Would be really nice to have but not essential.
3. Would be nice to have and essential
4. Would be really nice to have and very essential.

Some features are obvious (like social share options, individual event pages, etc) and some are a bit more specialised. We ended up with a list of must have features.

• Easy social share options

• Featured events

• Agenda - static

• Quotes from speakers

• Parallax scrolling

• Filter by event type

• Countdown timer ’4 days until event starts’

• ‘Invite someone to this event’ function (A function we wanted to encourage the energetic primary audience to invite along others)

• Event filtering

Some cool ideas that we couldn’t include:

• Auto generate ‘My agenda’ (Too much development time)

• Filter by timezone (This became immediately complicated. Whose timezone -  the presenter, or you? And then do you filter by a time range you dictate? Suddenly you have a filter that two or three levels deep. We weren’t sure Julian could pull this together in a non-hacky way).

• Interactive festival map (Like at a music festival! But would have required more planning, an illustrator, and a lot more certainty on the festival events to pull this off.)

• Event happening right now - live events. (One of the strengths of an online festival is posterity - most events were recorded and archived for public access on the SoC website. So we decided it wasn’t so crucial that people had to be there live. We also assume that this audience would be the type of people to plan their attendance, rather than just wandering into an event because it’s live.)

• Poll feature on event page (Asking questions to generate relevant stats for the sessions. Too much of a headache - like coordinating with facilitators and managing data in the back end - for not enough of gain).

By the end of this workshop we started asking, and partially answering, some of the big questions. 

• How will events be filtered? What do we think the audience values and will want to filter by when searching for a session - time, session type, topic?

• How will the sign up process flow? How many follow up emails are too many?

• How do we classify sessions? Nicole said “The format and content of the sessions will vary. I guess what I meant with that was it could be a debate that they listen to, or it could be a small coaching session with 3 people. So the format of what they’re engaging with is different.”

• What URL will website sit under?

• Will all the sessions be recorded? Where will the recordings live?

• How do we present events that have already happened but can still be watched as a recording?

• What happens to the website after the festival? 

• Where does the glitter fit in?

• How do we make the website replicable within the budget? Can we even do this?

• What’s the mood of the festival and therefore the website UI? Nicole had kind of covered this. She’s fun and colourful and SoC is very dynamic. Glitter was literally and metaphorically thrown around. They wanted to make the event really feel festive and we were so on board with that. However, I could see a problem on the horizon. There was no budget for any brand development (Julian and I aren’t really brand designers to begin with). The SoC brand that we were slated to use is grey and fluro and angular (see below for an excerpt of the SoC brand guidelines). It’s techy and sleek whereas this festival was evolving into something accessible and friendly and colourful. Oohhh, foreshadowing. More on this later.

SoC brand guidelines

The plan for which platforms, plugins, and programs we would use was slowly coming together, like a Frankenstein’s monster being built limb by limb. We would develop in Webflow, the email marketing was to go through MailChimp which we could bolt on to the build, the ticketing was going through Event Brite, the URL would be a subdomain of the SoC website, sessions were being hosted on Zoom. 

What’s going on outside work?

During the span of this project, we were pretty much all in lockdown. It was, and still is, a very strange time. Memes are sent at volumes every day.

Cabin fever sets in. During a particularly grim day, I Macgyvered a Minion outfit out of a hoodie, the strap of my saxophone, a yoghurt lid, and the lid of a makeup pot in a moment of frustration.

During the span of this project, Julian, Nicole, and I all turned 30. My boyfriend and I accidentally send Julian too much cake which he eats immediately.

Not a great angle on me but look at that solid inch of icing! That’s a good cupcake. The other big thing going on in my life is that my Sim watched another Sim die out the front of the local gym in winter and then nearly died herself of exposure because she was so stuck in a grief loop freaking out about the grim reaper that I couldn’t make her go back inside and keep working out. So you know. Lots to reflect on.

My Sim is the partially obscured one who looks like she’s been rifling through a trash can full of charcoal.

Part 3: Build

Programs we used

We’ll go into some of the software and programs in more depth but this is what we used to pull this project together.

Communication

• Slack

• Facebook messenger

• Email

• Facetime

• Zoom

• Instagram

Documents

• Dropbox Paper (my preference)

• Google docs (everyone else’s preference - sorry team, I just love my Dropbox Paper)

Design

• Figma

Development

• Webflow

Admin

• Clockify

Information architecture

Next step was to draft an information architecture and explore some user flows. Again because of time and $ restrictions we were not basing these flows on real user data, but on insights from the client about the user mixed with some wishful thinking. 

Eventually we come to this which Nicole approves immediately on the proviso that we strike out T&Cs as we won’t need it.

James let us know that based on their data, the majority of their users prefer desktop (or at least use their desktop to access the SoC website). This made sense for the profile of the user who are interacting with SoC in a work mindset. We made a note to design the website desktop first.

While sifting through hypothetical user flows, we sorted out a few other issues. I want to show you some conversations we had because a lot of people go into web design projects, or any creative project, without comprehending the sheer volume of micro-decisions you the client have to make. See below: A series of verbatim conversations between Nicole and I as we make micro decisions.* I’ve broken it up with pictures of Furbies otherwise it’s just too much text. Enjoy!

*Please note: I’ve copy and pasted these conversations instead of showing screenshots because they were happening in the comment section of a Dropbox document and screenshotting them would produce really long threads that would go on forever.

Asking do we need separate pages for agenda and events? And what to call the pages?  ‘Agenda’ or ‘Schedule’? ‘Events’ or ‘Sessions’?

Nicole: My only question is the difference between Agenda and Events. Does it need to be separate? Could it be the same main page for simplicity of use? It could work as separate if the agenda linked to the individual event pages? And agenda is the place where you see it all vs event page when you know where you want to be? Is that the logic? It’s hard for me to picture the relationship b/w but I’m not completely against it. Aside from that I’m happy! Nice work

Imogen: I can confidently say they need to be two separate pages. They have two different functions: ‘Events’ to filter/search and 'Agenda’ for a broad overview that allows you to see the events in the context of when they’re on (and yes, to answer your Q: you will be able to click on the events from the agenda).
Also, I think an agenda page is an expected feature of any festival website. 
Also I’m realising that the more commonly used term is schedule. Do you prefer that? It makes the purpose of the agenda/events divide a little clearer (one time-based, one content-based).
Program is also used! Maybe agenda is a bit too academic/business-y now I see it in comparison.

Nicole: yes excellent points. I trust you, 2 pages it is. Schedule or program over agenda. I’m leaning towards Schedule. Which makes me think then it should be ‘sessions’ over ‘events’. Event you go to, session you participate in?

Some ideas of how we want the contact form to be.

Nicole: Contact forms can be really impersonal I find - like it just goes into the ether, can we list the ways they can get in touch instead? Or be playful w the form at least

Imogen: Yeah definitely understand this! Especially when you don’t get a confirmation your enquiry has been sent. There’s a few ways we can customise this to make it feel more like you’re connecting with a real person.

-Absolutely include a confirmation - ‘Your enquiry has been sent, we’ll be in touch soon!’

-Can include an image of someone from the team -‘Nicole will be in touch soon!’

-Can suggest more specific avenues underneath the contact form like  ‘If you’re interested in a partnership, email our partnership manager nicole@states’ etc - so people feel like their enquiry is going to the right person.

-Showing twitter feed (as long as it’s regularly updated) is a good way to show there are people on the other side.

-We can make the copy quite conversational and friendly

Nicole: you’re great. All of this is good. Our twitter is quite active, and i like the idea of having our lil faces saying “we’ll be in touch!”

Debating the function and relationship of the events page and the agenda page.

Nicole: Does the agenda link to the event pages too?

Imogen: We’re thinking the agenda will be all clickable links (linking back to the individual events) but also as the agenda is in the main nav, you can always jump into it from any page. I am guessing that a voracious Charlie would use the Agenda page as a way to get a good overview of the festival before browsing events. [We’ve started referring to the persona of our primary audience as Charlie]

Nicole: I heart voracious Charlies

Deciding if and where we want FAQs.

Imogen: One notable thing: I haven’t included FAQ in the main nav. FAQs generally can either be a full page for themselves OR can show up as sections on individual events pages or elsewhere. It depends on the audience. Nicole and James - do you think the audience is the kind who would want/look for a dedicated FAQ page and why?

Nicole: I don’t think they need a dedicated FAQ page. Perhaps on the contact page we can have somewhere you going to ask us x - here’s you’re answer’ otherwise send us a email!

equally, could be some faq on the about page - about us and about festival

Imogen: FAQ page on the contact form is good, especially if we assume most enquiries will be users with practical questions, not potential partners, event pitches etc. 

FAQ on the about page i’m more hesitant to do as generally people go to the About page for a statement of intent or a demonstration of values, etc. FAQs are a bit too practical for that.
Another option is FAQs page but in the footer. If we do this we can also include FAQ modules on the contact page.
It really comes down to - how many FAQs will we have and will there be many sub categories?

Nicole: Nar there won’t be that many FAQs - let’s keep it on Contact us only. If they can’t figure out something obvious then we’ve failed somewhere else. Decision done. boom.

And we expanded on that above comment on the purpose of the ‘About’ page content.

Nicole: could do there [have FAQs on the ‘About’ page]? about us and about the festival?

Imogen: I’ve mentioned this somewhere about but I think the ‘About the festival’ bit shouldn’t be an FAQ, but a paragraph or similar. FAQs are generally for practical questions rather than philosophical ones.

Nicole: agree. keep this page philosophical

---

See how many micro decisions you have to make as the client?! A shocking amount. The question is, should the client make these decisions or should they rely on the expertise of the freelancer? It kind of depends. If the client is nervous or controlling or wants to be in charge (which Nicole clearly isn’t/didn’t), the client will want to make these decisions and will probably take their time, dragging out the timeline and maybe requiring some correcting and education here and there. And if there’s not much budget, the client will end up making these decisions to save hours. But if the client relies on the freelancer too heavily, it can be a lot of pressure for the freelancer and erase any sense of collaboration. I wanted to highlight these conversations to show what is, in my opinion, the perfect balance of intent and collaboration. Nicole debated, chimed in, asked questions, challenged but she also heard us and took our advice. It meant that instead of dying a thousand tiny deaths every time the client makes a bad choice you have to manage, you start to feel real ownership of the project. You both have a hand on the wheel and it feels good.

Wireframes

Now we had a better idea of what goes where, it was time to rough up some wireframes. Again, we didn’t do this properly. Proper wireframes would be iterative and draw on user feedback to refine. Our wireframes were refined based on what we could do in the timeframe and what we could do with Webflow. They were also a strong guide for the UI which we knew we didn’t have much budget for. While the UI would generally be developed completely separately, with more freedom to move bits and pieces around the page, we saw these wireframes as a (bland, colourless) prototype of the website, the missing evolutionary link between UX and UI. The UI was already coming up in conversation as a point of difficulty.

Example of Nicole being all over things

By this point, an idea had been growing in my mind. I don’t know where it came from, maybe it was incepted into my brain during one of many disturbed dreams about Leonardo Dicaprio, but it was becoming insistent. Blobs. Colourful blobs. I strongly imagined this website being built on colourful blobs or some sort of organic, colourful shape. There’s no rhyme or reason to this theory. It was the aura of the event that my third eye could see. When I set out to do the wireframes I snuck my idea in there. 

I designed these in a program called Figma, recommended to us by our ex-colleague and ongoing friend Josh Leeman. Leeman is a great designer and a practical, no-nonsense guy (so no-nonsense I often accused him of being a curmudgeon, an accusation he took with grace). That Leeman was willing to advise us at all is a miracle, as we would often have lengthy, heated debates across the co-working space about the best type of Subway bread (Julian and I would team up in agreement that Italian herbs and cheese is king, Leeman was a fan of honey oat?!? Ludicrous). 

Josh, you’re right - Figma is great. I’d never used it before and while my file organisation was a dog’s breakfast, the program itself is easy to understand and looks fantastic. 

View fullsize

View fullsize

View fullsize

Nicole and James believe that their effervescent primary persona, Charlie, would be the kind of person to browse events based on big ideas and emotions rather than practicalities like time or mode of presentation. They’re the kind of person who would chase a butterfly with a magnifying glass and end up getting hit by an oncoming train but not regretting it at all because life is for the living! Does that make sense? It’s quite morbid. Anyway. Charlies want big questions. We decided to sort the events of the festival by questions. The homepage blobs we imagined would contain the big questions the festival hoped to address and when you click it, you go to a page of filtered events with all the events related to that question. Seemples, as that TV meerkat says. 

Well, actually, TV meerkat, it’s complicated. I know I keep banging on about the tight timeline but by god, it was tight. Our original timeline had slated May 4th for development but the wireframes had taken until the May 3rd to be developed, reviewed, refined, approved. Meanwhile, Julian was champing at the bit (“First of all, horses champ at the bit.”) to get started on development before other projects took over his schedule. He had done all the initial set-up in Webflow and once we had a rough set of wireframes, even though they were not yet approved, he got to work moving the pieces into place and playing around with some animations. As I said, he’s an autonomous, elastic robot worker man.

Meanwhile, after a few more days of finessing, the wireframes went to Nicole for feedback. 

She compiled feedback in a very considerate grid.

We refined the wireframes based on their feedback over the next day or two and then it was all approved. Kazoo sound!

User interface design

Most projects follow a pretty clear narrative that goes wireframes → feedback → UI → feedback → development → finish → have a beer and a chocolate biscuit to celebrate. For us it was more like wireframes → UI → oops change the strategy a little → wireframes → development now omg hurry →  UI to stay just ahead of development → hurried client feedback → research a thing we forgot → strategy sprinkling → glitter UI strategy → maybe back to wireframes, for some reason, love it → UI → finish development → stress eat a block of home brand cheddar cheese to celebrate. While the wireframes were being finalised, the development was starting concurrently, and the UI strategy was changing. While this was going on, I made my case to Nicole that the UI needed some love and some real budget.

This is the kind of pivot that would have previously given me a fear headache. Asking clients for more money, even when you know it’s the right thing to do, is scary. It makes you feel like you’re moving the goal post and can be a delicate conversation to have while still maintaining trust and not crushing the beautiful butterfly that is your growing friendship. 

With Nicole, this conversation was easy. I recommended we ask wunderkind Matt to commit to a set of hours to finesse the UI using the SoC fonts and the expanded brand colour palette. The tight timeline, different time zones, and everyone’s mental health being destroyed by COVID-19 lockdown made decisions like this bigger than they would be normally. It required an extra step of checking in with everyone, making sure the extra work and budget was the right choice for us and them. Nicole asked for a few hours to consider the UI budget before approving later that day.

On the 30th April, Matt sent through a draft of the homepage UI.

By the 1st May, Nicole sent through her feedback and we had a meeting to discuss it all.

Nicole’s feedback, shown below, was great which is really becoming a theme of this case study. 

Clear, easy to execute feedback. Unfortunately, Matt is a cool young person with a life and was not able to work on a Friday night … but I was. First, I needed some logins which Nicole and James were trusting enough to give me. This is an example of how to be a fun client

One pizza later and I had something to send through.

I presented Nicole with a new UI design that evolved Matt’s design and took her feedback in.

The highlights of Nicole’s UI feedback include:

• “The photographs. We are all stuck in one ‘place’ yet the ‘meeting place’ of the festival and online sessions will hopefully feel connected. I recognise the contradictions I”m creating here - “I want people” & “we can’t show people together” & “people by themselves is lonely” & “show me connection and people”… I don’t know how to resolve this contradiction.”

• “I like the placement of the images. But if we can’t find images that represent the vibe, let’s skip it all together but keep the blobs around photos as images for presenter bios if possible.”

• “I much prefer this mix of bolder colours w pastel than the first one. Nice.”

• “The blobs are blobby enough without being too shapely.”

Kazoos were blown, yays were yayyed, and the UI problem was solved only to be replaced with my new problem: what imagery fits with the colourful design, shows people being connected, but not together? Lockdown sure creates some impossible questions.

Also - I wasn’t lying about my mess. Look at this filthy Figma board. People with clean files, forgive me. Matt, forgive me.

After this point, I bought a bank of Matt’s time and he used it to clean this mess up and skin the wireframes in record time. Much like Julian, working with Matt is effortless. I very much recommend it.

Images

How do you find images to advertise an online festival of learning when you can’t show people who are together? No, I’m really asking. I never figured it out. We tried so many different image combinations. I sourced images from CC0 sites like Pexels, Pixabay and, obviously, Unsplash. I also trawled across paid sites like Adobe Stock and Shutterstock thinking that if we found the perfect image/s, surely SoC would agree to pay for it. But there was no perfect image to be found, the conditions we needed were too complicated. If we had an illustrator or a designer on board, we might have been able to get creative with the way we represented togetherness-while-apart. 

I tried a few approaches. The original showed people alone around their computers but they’re happy la la la having fun, maybe even looking at each other and laughing together across the void of time and space.

As a Hail Mary, I tried using some free illustrations called Open Peeps, designed by Pablo Stanley. These illos are so cute and easy to customise but they didn’t quite work with the bright, bubbly style of the website and I don’t have enough of a design eye to force them to work. Another fail :(

Why TF were the images so hard to figure out?

Something I picked up while working at an agency and have heard repeated a lot by my sister, who’s also an illustrator, is that illustration is tough to bolt on at the end. You should develop the illustration style to work with the UI. For example, I worked on a great project at Light Creative called Good Form. The client, Victoria University, wanted to develop a learning resource to help deliver an educational unit on body image and positivity for teenage boys. 

View fullsize

View fullsize

We worked with our friend, the obscenely talented Jeremy Ley, to develop an illustration style alongside the UI design of the website. Jeremy was involved from day one and collaborated with the UI designer (another great talent, Carla Young) to harmonise the illos and the UI.

Another good example is the website of my friend, and sometimes client, Hani El-Rafei. Hani is an accountant and financial strategist with a sharp sense of humour. His website was developed by the good boys at Alyoop, Adrian and Daniel, and you can see how the illustrations were built into the style and colour palette of the website. They’re also subtly animated to come to life as you scroll and create depth - this kind of synergy isn’t something you can fake when you’re jamming illos into a project at the last minute.

Anyway. Enough bragging about my friends. All of this to say that I couldn’t make images/illustrations/photography work. This problem cropped up because we pushed for the festival brand to become distinct. I’m really pleased we did push for that because it needed it. But I’ve learned though that something’s gotta give when you add a whole new component to a project and for us it was sleep.

Content

Content! Oh my favourite sneaky snake. I have never met a client, even one as self-aware as the SoC team and Nicole, that has not underestimated content. I define content as the writing, editing, and inputting of all the words on the website. In this case, it was a huge task because it meant developing and writing up tens of events and inputting them. SoC actually hired someone for this purpose and even then it nearly overwhelmed them. 

I learned early on in my career to active opt-out of content. Some clients will assume it’s your job, that you’ll just ‘pop the words in’ and it’s like - no? Are you batty? Popping the words in is a full-time job that will break you. I’ve accidentally been roped into it a few times and lived to regret it. Now I make it clear that if you want me/us to do the content input, it’ll cost ya. Most people are willing to do this themselves to keep costs down and because they’ll be familiar with the content itself. I like this arrangement better because it makes clients engaged, makes them think about the backend functioning of a website, and gives you something to bond over.

For Nicole and the SoC crew, the website content was their white whale. The content design started early on and the SoC team were not just designing sessions but designing a pedagogy that meant something to them. This is an excerpt from the blog post SoC wrote about their experience designing an online festival (you can, and should, read the whole thing here).

“We built on our previous, immersive, experiential, hands-on pedagogy. Our instincts still said we didn’t want people simply talking at you (though these are much easier to organise!). Nicole wrote more about the pedagogy behind the session designs — to be interactive, not to default to one hour — that sort of thing. In reality… as with all good design work, learning design takes time. And by this point we were slammed arranging sessions with people, seeing the website develop, setting up the backend, preparing comms and engagement plans and keeping the How not to waste a crisis series going. The lucky thing is, we were working with amazing facilitators and session hosts who brought out their expertise in this regard.”

View fullsize

View fullsize

The design of the content should be massively influential for a website. Good design should be responsive and specific to the content but when we started this, we didn’t even know what it would be. But we were building the plane as we flew it, I kept telling myself.

Around mid-May, SoC figured out a structure for their content. I honestly can’t say when as the days were all blending into one long day, punctuated with coffee and occasional stress naps. At the time I was working on another giant project as well as a few copywriting jobs so I want it on the record that the late nights weren’t the fault of SoC at all. During our meetings, Nicole would frequently notice my glazed over look and prescribe me a night of Netflix and cake to recuperate. 

Jokes helped us through the grind

Anyway. SoC eventually decided to organise the festival content around stages (like you would see at a music festival) including a versatile, online Community stage that was just for chilling, chatting, and networking. Each stage would be linked to a fundamental question and those questions would form our discovery collections. When I say ‘discovery collections’, I mean the colourful blobs on the homepage that have a question floating in them. These questions would lead to groups of events related to that question. This meant Julian could move forward quickly with the search functionality, tagging, and filtering.

Julian stays up late just FYI, he’s like a sleep camel.

This was the rough prototype of their content design. Of course, I couldn’t help but chime in.

Over time, these questions developed and changed. The final expression became something entirely differently, that was on the homepage for the duration of the festival: for the planners, for the dreamers, and for the doers. 

As SoC outlined in their blog post, they started with the assumption that all events would be finalised and all content in the website and ready to go before the website went live. What actually happened is we went live with one event finalised and slapped a ‘Coming soon!’ sticker on the rest. 

Thankfully, the one event they finalised before launch was a banger. It was the opening event for the festival, titled 'How Indigenous Thinking Can Save the World’ and facilitated by Tyson Yunkaporta, the author of ‘Sand Talk: How Indigenous Thinking Can Save the World’. Within a few days of ‘opening’ the event to registrations they had 160 people sign up and hundreds more soon followed. (You can watch a recording of the event here. It’s very good.)

Week by week they slogged to finalise events while running the festival, writing the marketing, and putting out a thousand tiny fires that kept threatening to burn up the dance floor. In the end, the design and execution of the festival content was a remarkable feat of endurance. 

Development

So the development had been running throughout all of the above. 

Julian is such an autonomous worker that I barely heard a peep from him, except when he was solving my problems or asking for a second set of eyes on his work or endlessly sending memes and pictures of his various sandwiches. What I would like to go into was a few problems/solutions that were working out with development tricks.

Time zones

Time zones are a pain. In theory, they should be simple. In practice, they’re like the devil’s butthole - weird, confusing, no one wants to deal with it, embarrassing. The SoC audience is flung across the world but most facilitators would be from London and Melbourne. But a 9am session on a Monday morning in Melbourne would be a late Sunday night for users in the UK or a mid-afternoon session or anyone in LA. We considered geo-tracking users and automatically translating the event to their time zone but you can just tell that’s going to be a nightmare. How does one even geo-track? Julian said please no, find a way around it. But we couldn’t. I previously mentioned the ‘filter by time zone’ debacle - this was like that at scale. In this case, we gave the user some credit. We hoped they would say no to solipsism and double-check which time zone the event was expressed in. We hedged our bets by linking to a time zone converter for every event. 

Live events

Then there was the issue of live events. Some events were lectures - you log on, you listen, you log off happy. But some events were designed for a smaller group and were to be interactive. Mics on, hearts open. We couldn’t afford to have timezone mistakes for these groups when the places were so limited and coveted. We also needed to know more about the users, to know they were a) definitely going to attend and b) would get something out of the event. Let’s call it light vetting. 

But the event the CTA defaults to ‘Register’. Having the right label on buttons can do a lot of work for you. The wrong label (like a button that says ‘register’ but actually means ‘apply’) means you get a bunch of people clicking that may only be half-interested or CBF applying for an event. 

Nicole solved it in the end by whipping up an EOI Google form and requesting a manual override that would change ‘Register’ to ‘EOI’. There were some hiccups with manually organising attendees but the SoC team pulled it off.  

Transitioning to past events

When events were finished, they would still be accessible as recordings. That’s the joy of an online festival - the archival possibilities are endless and events don’t really expire. When an event ended, the register button had to be manually deactivated and replaced with button that links to the page on the original SoC website where archived content was being collated. This is a simple solution when I say it now but it was a headache to get to this point. Simplicity is WORK. I don’t even want to go into the various harebrained solutions we devised before getting to this point, trying to meet needs we made up, trying to make seamless processes when, actually, a few seams are fine - they hold our pants together, after all.  

Outcomes

Alright, you’ve come all this way on this wild and wordy adventure. What did we learn? Is it smart to fly a plane you are currently in the middle of building? For most of my working years, I’ve been told not to do this. That planning is God and I should be a devout worshipper. But after this experience, I’m more planning agnostic, a worshipper at the altar of controlled chaos. I usually plan projects to the hilt and control every little bitty. I realised throughout this process that I do that because I don’t trust my clients enough. If you trust your clients, if you’re not scared of them, you can build the plane as you go. 

For SoC, it worked a treat. I trusted Nicole implicitly and, I assume, vice versa. We planned some parts, we chose not to plan some parts. The festival was a success in the ways they chose to measure success - people came, people thought, people subscribed to their mailing list (subs went from 300 to 1800 by the end of the festival). Maybe another way to describe the success of the festival was that the team had a purpose during a time when everyone across the globe was being shaken up. 

For me, this project was a success because it was fun and a little outrageous. I got to work with a team of people I adore. I got to work during a pandemic. Mostly, it was a good project because I wrote this whole case study, revisited every inch of the work, and was left smiling.