Designathon Case Study

Intro

Just this past weekend was Design at UCI's first ever Designathon. Unless I am mistaken, this was also the first ever Designathon-type event hosted (remotely) at UC Irvine! For anyone who does not know, Designathons are events where individuals with any level of design experience from the local community complete UI/UX focused projects revolving around a central topic and prompt. This event was planned by Stella Adriana and myself. We started planning in around August and had our eye on the second half of November for the event.

Main Takeways

1. Segment Operations into a Traditional Structure

Working alone allows one to use a workflow of their own, known to be efficient and personalized. Wrangling over a collaborative platform such as Google Docs is good for exploration, but poor for productivity. As the club matures, traditional segmentation should trade such exploration for productivity. Of course, collaboration is still necessary, but not as essential to day-to-day work.

2. Be careful of Verbosity, and highlight Key Info

Information will always have a hierarchy of importance, so in a set of dense information, point out the key parts. This goes for any form of communication, such as emails, social media, and documentation.

3. Centralize Communication Channels

Communication is key to a multi-faceted project. In a small team where many hats are worn, understanding and knowledge is of utmost importance.

Issue 1: Organization

1.1: Google Drive + Docs/Sheets/Forms/Slides

All our files were organized in a sole Google Drive folder mixing Docs, Sheets, forms, and Slides. As you can imagine, storing everything on the same level in a folder proved to be annoying to manage. File names were inconsistent, difficult to understand, and were uncomfortably long.

Frequently, we would have documents that shared the same components. For example, we had some schedule variant in 3 different documents: Logistics, Logistics - Workshop, and Logistics - Judges. We started with the plain Logistics file, and when we thought it was sound we branched it off into the two meant for external use. But of course, while working through the project we had to tweak the main one, which caused the other two to be out of sync. This was extremely annoying to work with, and led to lots of confusion.

A very nice way of resolving this issue would be utilizing transclusion, where document contents are essentially linked and previewed within other documents. This would allow for extremely consistent specifications, and soundness that everything is synced together.To me, this concept is similar to concepts like Variables in programming, and Components in design tools like Figma.

Google Docs does not support linking files within the same drive, let alone some sort of transclusion. The only experience I have with this is in Emacs' Org Mode, a type of markup format. From rudimentary research I have not seen any user software implement this concept. I have seen references in Wikipedia's MediaWiki and in AngularJS.

Another idea I had is some sort of tangling, which I also use in Org Mode. This is a similar concept to transclusion, where components can be synced across documents, but tangling focuses more on the component level. Files or documents are mainly built through combining components, the act of tangling.

I am currently using tangle to create a pure HTML/CSS website. While creating the first version of my personal website, I faced an extremely similar problem of having to sync content between files. My current experience with tangle is solves most of my past problems.

As far as I know, 'tangle' is a term only relevant to Org Mode. Its use case is primarily when engaging in Literate Programming. And Literate Programming is a fairly niche topic in the programming world, most commonly seen concerning Data Analysis with Jupyter/Pluto/Wolfram Notebooks and R Markdown. I doubt there is a popularized method for tangling with plain english text.

1.2: Team Formation + Emails

Our formation process consisted of Stella and I working through the spreadsheet of <200 submissions, and manually combing through and organizing teams. We also fell into a hole of working with MailChimp, our club's email newsletter service. We simply were not knowledgeable on the service, and thus struggled with a main part of our plan.

I currently am not aware of any specific team formation software, but i believe there should be a generalized platform out there that would fit this application. Another solution is to script the process either inside of Google Docs or in a more traditional data pipeline.

1.3: Team Names

When discussing our team formation process, I threw out an idea of auto-assigning teams to a randomized color hexcode (hexadecimal triplet, e.g. #1032EF). Stella and I thought it was a fun idea that could work, since color is heavily intertwined with design. It did turn out to be a fun concept with incorporating finalists' colors into the slides, but the cons outweighed the pros.

The random nature of hexcodes meant any form of communication with them was destined to fail. We assumed teams would be able to remember and recite their codes, but obviously that did not prove to be true. Our Finale presentation slides initially only contained finalist team's hexcode, but during the event no one remembered their code and we were asked to include member names, so we had to add them in on the fly. When the judges were discussing which winners to choose, they also faced this same issue. There was no way any of them were going to recite '#1032EF', rather they logically went with the product names of the projects. Even between Stella and I, we had to resort to a mixture of 'the group with nice UI', 'the group with John Doe', etc. All in all, our hexcodes were just functionally worse glorified indices (1, 2, 3, ...). As a novel concept, they were good for internal consistency, but extremely poor for uses in human communication.

The solution to this would be to just take the simple route and let the teams submit their own project name, and keep hexcodes or a similar system for internal consistency.

One club board member suggested the idea of having application forms being submitted by one member for a whole team. This would ensure that everyone has teams before hand and would be pretty easy to manage. However, this idea would breakdown when teams change and dissolve between applying and the event. This situation occurred a handful of times, and was still a pain with our current system.

Issue 2: Verbosity

This designathon was our club's largest undertaking yet. We had to plan inside and out, on both our side and the participants and judges. We unconsciously decided to go through this process by being extremely detailed and verbose.

2.1: Challenge Brief

Every participant was required to follow our Challenge Brief, which basically had everything one needed to know to participate. It included sections like the Prompt, Participant Requirements, Submission Process, Rubric, and Prizes. As you can imagine, it was a fairly dense document, which resulted in many people not seeming to read and/or process all of it.

We received many questions regarding even the prompt itself. People asked if they could work on a mobile app, when the prompt clearly stated to 'design your own desktop app'. To me, this signifies that there must have been something wrong with the way we or the prompt presented the information. I am not sure if these questions stemmed from their own wishes in projects, or our informational writing, but it should be noted nonetheless.

I personally think our Challenge Brief PDF document had clear visual hierarchy and organization. So I believe a solution would only have to add to it, such as visually highlighting key parts of the PDF or making another brief flyer with only select key parts. The latter option may prove to be more confusing with more things for participants to manage.

2.2: Communication with Judges

Likewise, we tried to be as clear and detailed with our communications with the 4 judges + 1 workshop host that graciously agreed to participate in our event. But we may have been a bit too detailed. Our logistics document was a couple pages long, in addition to numerous emails and nuanced scheduling information. Looking back, I have no idea how we thought busy professionals would read a 3-ish page document + all the correspondence and have photographic memory of them.

I believe solutions for this issue would be similar to (2.1), where key info can be highlighted and segmented away from the noise. Correspondence paragraphs could be reduced to _bullets or key highlights_, or at least be supplemented with some. On the grading spreadsheet, we included notes that were a couple sentences long, which was definitely not apt for a spreadsheet nor for our judges. Instead, they could be replaced with less mentally intensive elements such as cell colors and border thicknesses.

In summary, Stella and I thought verbosity was a good substitute for usability, but clearly it was not. Of course, hindsight is 20/20. There could also be similar improvements to accompanying materials such as our website or marketing flyers and descriptions.

Issue 3: Internal Communication Channels

As an overall club, we have always struggled with using a consistent communication platform. As of writing we have used: Facebook Messenger for most of our group chats, Discord for public facing channels with some internal ones, Email for general and board Newsletters, and whatever one-to-one channels exist on SMS/iMessage/etc.

Since this event was mostly handled by Stella and me, we were pretty comfortable just using Facebook Messenger for everything. This however is fairly difficult to actually search through and is not suitable for productive messaging. We also used Discord for its Voice Channels which allowed us to talk freely and have relaxed meetings.

Stella handled pretty much all of the communication, both with externals and our internal teams. I trusted her enough to do this, but it also led to me being a tad left in the dark about certain information. I would always have to ask her if she did a certain task or how a party responded to a request.

These more minor problems could be solved by fully utilizing the potential of a platform like Discord or Slack, where dedicated channels with various combinations of members could be set up with ease. These types of platforms also have functions like pinned messages and voice channels, which could improve the efficiency and friction of our communication.