Meta post: let’s talk about my portfolio site

This summer, I redesigned my portfolio website.

I’m still tinkering with it, and my site will see many iterations over the years to come, but I wanted to share some thoughts and messy sketches from my design process for the way it looks today.

In the first iteration of this site, I had an idea of what I wanted it to look like and I looked for a theme to match that. This was before I came to the iSchool and before I knew much about design. So when I came back to the drawing board this past summer to re-think my site, I knew that it had several problems I wanted to mitigate. I had three goals for my new site:

  1. Start from the information architecture. I wanted my portfolio to be front-and-centre in this iteration of my site, but I also wanted to keep my blog and to show some personality through static content, too.
  2. Let the content speak for itself. I wanted to take a minimalist approach to the visual design of the site and focus on showing my UX design chops and my personality through the IA, the content, and my portfolio pieces.
  3. Validate and iterate. These words were not clearly defined in my design vocabulary when I put together my site. This time, I wanted to make sure I got feedback so I knew the site worked for the people using it.

With these goals in mind, I created a project plan to redo my site, starting with IA. I wanted to make sure that the site’s navigation was simple and intuitive, providing users with a clear path through the site that provides the information they need to get a sense of who I am.

Sketches of screens, a site map, and content ideas from my notebook.

Water-stained wireframes (or perhaps coffee is the more likely culprit). These pages from my notebook show a quick and dirty iteration on my site’s content and wireframes after showing some screens to a friend for feedback.

Once I had the IA nailed down, I took an Agile-inspired approach to the project, working simultaneously on content and design and putting both in front of users to iterate with the project on the go. 

I created wireframes and showed them to several friends to get their input. I also started to write up the content for the site and shared the doc with a few of my writer friends to make sure the copy was clear and concise.

Once I found a Wordpress theme that would give me the flexibility needed to bring my site to life (Optimizer), I set to implementing and was then able to test on the real deal. I’m very grateful to my roommates and colleagues who volunteered for usability testing or otherwise provided feedback.

Kevin in front of my laptop looking at one of my portfolio projects on my site.

My roommate Kevin was a participant in my site usability test. Thankfully, he has grown to love usability testing and is always willing to take a look at things for me!

I continue to use user feedback to make changes to the site. Recently, I added the “latest posts” section to the front page after repeatedly receiving feedback about having current content somewhere there to indicate that the site is being updated. I also added the “design process” section after hearing from colleagues in the industry about the importance of including a high-level overview of my process on my site.

The next change I plan to make in the next few months based on user feedback centres around content. I’ll be working to shorten the length of my portfolio projects and add in bolded sections and pull quotes to make them easier to scan.

I’m always collecting feedback on my portfolio, and I’m always iterating on it. Still, I’m satisfied with the current iteration at a high level.

My central idea was to try to reflect my personality in the design, showing who I am through the content and using simple IA and minimalist design to let my work shine through. Particularly on the home page, I wanted to give the user a TL;DR summary of my approach to design, and I think I succeeded in that.

Disagree? Have other feedback on the site? Please share it with me, below or here! I’d love to hear your thoughts.

Check out my new Medium blog: UX in the 6ix

I’m very excited to be collaborating with two of my very talented colleagues at the iSchool, Aditi Bhargava and Therese Owusu, on a yearlong User Experience Capstone project this year. We’re working with a team at the MaRS Discovery District on reimagining one of their digital products, the Entrepreneur’s Toolkit. 

For all three of us, the Capstone is an opportunity to take what we’ve learned at the iSchool and apply it in a real-world context, and to continue to learn by doing as we pick up new skills and softwares throughout our design process.

We want to capture our capstone journey as we transition from students to full-time practitioners, taking the opportunity to critically reflect on our experiences, celebrate wins and reinforce lessons learned — and we’re doing just that on our new shared Medium blog, UX in the 6ix

Follow along to keep up with us!

5 things I learned at the RBC Next Great Innovator hackathon

This past weekend, I participated in RBC’s Next Great Innovator hackathon. It’s Thursday and I’m still exhausted, but it was worth it for a really enriching weekend — not to mention a third place win with my team, Team Athene! (Named after this owl because Mari thought it was cute, and because its name references Athena, the goddess of wisdom.)

I wanted to post this week while my memory is fresh to reflect on some of the many lessons learned I took away from participating in my first full-fledged hackathon. So without further introduction, here are 5 hackathon tips I learned over the weekend!

1. If you can, come in with a concept.

We received a slide deck containing the challenge about two weeks prior to the hackathon. In the time leading up to the event, we pored over the information provided and bounced ideas off each other. When we arrived at the hackathon, our concept was rough — but we had a strong starting point and were able to hit the ground running with coding and design. Coming in with a plan gave our devs the time they needed to create a visually striking demo, while the rest of us continued to iterate on the concept throughout the day. 

2. Talk to coaches early and often.

Throughout the day, RBC made business, technical and pitch coaches available for teams to direct questions to and share ideas with. Within the first hour, we started talking our idea through with coaches, and we kept at it all day. Their input helped us better understand and articulate our concept, and, in several cases, added to and strengthened our product. So if any experts took the time on a weekend to be at a hackathon, take the time to talk to them! They’re an invaluable resource.

3. Two semi-controversial ideas: sketch, and sleep.

Okay, this one is really two pieces of advice for the price of one. But I’m letting it slide because alliteration! Early in the day, someone came up to our team and commented that he had never seen so much physical sketching and writing at a hackathon before. But sketching is a really easy, low time cost way to share and test ideas with teammates before committing them to code. Paper is a really powerful communication tool, particularly in the pressure cooker hackathon environment where so many ideas are flying around the table that it can be difficult to really understand one another.

And slipping this one in here — get some sleep. We decided to end our night a bit earlier, and meet the next morning a bit earlier to make up time. Sleeping gives your brain the opportunity to reboot — when my alarm went off around 5:00 am, my writer’s block on our pitch from the night before was far gone and I was able to hammer out a rough draft in 10 minutes.

4. Practice your public speaking.

It all comes down to the pitch. You may come up with a remarkably innovative idea — but if the pitch doesn’t sell it, your product will struggle to speak for itself. I don’t have much experience with public speaking and I really felt that this weekend. I understood the challenge and believed strongly in our product, but when it came time to talk about it with a microphone in my hand, I was struck by how nervous I felt.

Throughout the weekend, and ideally leading up to it, practice some form of a pitch — even if it’s just talking through the idea in front of some peers. Get comfortable talking about it, and when the moment comes to present and the requisite nerves come around, take a deep breath and meet the judges with the same confidence you’ve shown others.

5. Act like you’re the winning team from hour one.

I’ve saved what I think is the most important takeaway I have for last: behave like you’re number one from hour one! No, not to motivate yourselves (though it can’t hurt for that reason) — to make sure that, should you move on to the final round of judging, you’re ready for it.

In our case, in the first round of pitching, we only had to present a two minute pitch. We didn’t expect to advance to the next round, but we did! That was wonderful, but then we were left with about an hour to turn our two minutes into ten minutes. Somehow we pulled it off, and we were happy with what we presented, but had we acted like we were going to be a final five team throughout the weekend, we would have put together the long pitch alongside the short one, and just had to practice in that hour, rather than write, too.

It was a gruelling weekend, but I learned so much about myself as a leader, a designer, and a project manager from my experience at the NGI. I also got to work with a really talented team, and to see the work of talented students from across Canada. There may yet be more hackathons in my future! But not this weekend — this weekend, sleep!

Making meaning from research: from insight to requirements

I’m currently working on a participatory design project with a group from one my classes (User-Centred Design — a full post on this project will come soon!). I also recently joined another project through CivicTechTO, a great local meet-up that aims to solve civic problems with technology solutions.

One problem both groups seems to be encountering is how to translate design research into actionable requirements. We’ve got a lot of design research from consulting with users and stakeholders and creating artefacts like user journeys and interview reports, but we haven’t distilled it in order to create meaning to pass the baton to other teams and facilitate an agile design cycle.

This leads to a lot of group discussion. On the one hand, some team members are concerned with how to best focus in on one aspect of the research in order to move the project forward; on the other hand, others are concerned that the research we have is not yet refined enough to start moving forward and that doing so would be premature.

This dilemma got me wondering: is there a more productive way to build our research outputs, such that they translate more immediately into requirements? In other words, does cleaning up our research for requirements gathering have to be an added step, or can we get the work started?

In the project team for my User-Centred Design class, we decided to start to make our research requirements-ready by creating highly refined user stories for the two of the users we felt we had significant research on. A couple of our teammates took on the task of focusing in on one of our users each, reviewing all our research, and coming up with a concise table with two simple columns: “User should be able to X,” “So they can X.” These were accompanied by high-level personas including the three central tasks of the user. This effectively creates a set of scenarios to inform requirements development.

As is almost always the case, more user research is needed to enrich our user stories; but this gives our client the opportunity to move forward on some aspects of development without compromising our research cycle.

When working on our design research, it’s easy enough to just throw ideas into documents and throw documents into a shared folder; but without continuously reviewing our research and building upon a thorough, yet concise presentation of it, we ultimately create more work for ourselves. Rather than needing to review everything in order to create a distilled version to inform requirements when all is said and done (or at least getting there), we should begin to distil and refine our research for requirements from the start.

Going digital-first: content management systems in news organizations

Last week, I presented some research I worked on over the first year of my MI at the iSchool’s Student Conference. I gave a five-minute lightning talk on introducing custom content management systems (CMSes) in print news organizations as a means of facilitating a shift towards a digital-first newsroom culture. An edited version of my talk is below.

In my undergraduate degree, I worked at The Varsity for several years. We had a lot of great ideas for digital content but couldn’t seem to follow through. Then, in late 2015 while working on my Master’s, I used the paper as my site for a course project and questioned whether the intervention of a new digital system could assist with pushing the paper towards a digital-first model. When I started to research that question, it quickly became clear that a new (or customized) CMS was one way to go, and this research emerged from following that thread.

While developing Snowball, Thomas Park, a researcher at Drexel University, found that, among the top newspaper websites in North America, WordPress is the most identified CMS, but at only 11%. For most (62%) of sites, the CMS could not be identified. These “others” are likely using custom solutions, and I wondered why so many newspapers seemed to be going in that direction. (Student newspaper sites overwhelmingly use Wordpress, at 68%). View his research here.

Case study: The Star

Let’s look at a case study in introducing a custom CMS: Total Publishing System (TOPS) at the Toronto Star. This case study comes from Scott Rodgers who did an ethnographic study of the Star’s newsroom from 2005-2013 and published his work in the journal Journalism in 2014 — view the study here (at a cost unless you are affiliated with a public institution with a subscription to the journal). TOPS was introduced in 2006 as the so-called “high performance engine” of thestar.com. The Star started a new unit, TorStar Digital, with a start-up style office with hundreds of staff, which ran the CMS and built new products, at least in theory.

A screenshot from the TorStar Digital site showing its emphasis on innovation.

The TorStar Digital site and it’s bouncing jargon slideshow in 2007 (screenshot via Wayback Machine). Today, torstardigital.com redirects to the TorStar site.

In practice, TOPS and TorStar Digital posed many challenges to the everyday operation of Star reporters and editors. Technically, anyone at the Star could edit content on TOPS, but because the CMS was complex, the web team that implemented it just never left the newsroom. The CMS had all kinds of problems such as lags between updates, constrained navigation and layout, and poor SEO — and the web operation in the newsroom actively worked to subvert it.

Senior management at the Star was frustrated that TOPS hadn’t been designed collaboratively and an us vs. them mentality gradually developed: a senior digital editor complained, “[TOPS] just doesn’t give us the flexibility we need to respond to things instantly and overly creatively.” The CMS wasn’t empowering — it was limiting.

The TOPS CMS demonstrates what goes wrong in general when you do a top-down design process. It also shows that having a website and a custom CMS isn’t a digital strategy on its own.

Case study: Chorus

By contrast, Chorus from Vox Media is lauded as the holy grail of CMS solutions for digital publishing. It should be noted that Chorus had a major advantage over TOPS — it wasn’t developed in an existing print newspaper culture. That said, it’s a good case study for us to look at because it shows the power of what a CMS can do for a digital publication.

Some things Chorus does well. Image via the Vox Media Product Blog.

Some things Chorus does well. Image via the Vox Media Product Blog.

Chorus is the product of an iterative design process with a tight development loop between developers and writers. Everything can happen inside Chorus and everyone can use the CMS. Some features include forums, an editorial workflow system, and flexible layout.

It’s the Chorus CMS that led to the creation of websites like Vox.com and The Verge. Ezra Klein was formerly a reporter at the Washington Post and went to Vox because of Chorus – he says of his decision to leave the Post in the New York Times, “we were badly held back not just by the technology, but by the culture of journalism.”

Chorus is flexible — tools can be created as tools are needed. Developers are embedded in the culture of the organization and content creators are part of the development process.

Building systems that work for you, not against you

So between these two case studies, we learn that for a CMS to be a productive part of a newspaper’s digital strategy, it has to be user-centred — it has to help journalists become developers, and developers become journalists. So what are some ways custom systems are tackling this?

One approach to making reporters “digital” is to reflect actual editorial workflow in the CMS. At a newspaper, many people are editing the same content at the same time. If they want to add a comment, they want to note it right above the spot they’re critiquing. Certain editors or reporters should be able to access certain content at certain times; others should not. These are really fundamental processes of editing nicely reflected in the New York Times’s custom CMS, called Scoop.

Another approach seen in Scoop is to empower non-technical editors. Flexibility is a major limitation of traditional newspaper CMSes. Like I said, at The Varsity, we wanted to do a lot online that we couldn’t because our online team was busy doing things like copying content into text fields and maintaining the website.

So, as much as possible, non-technical editors should become digital editors — they should be actively using the CMS and able to create custom, interesting content simply through CMS tools, like Atlas by Quartz and Snowball. This also frees up time for the dev team to spend time responding to requests for new features and actually fostering a culture of innovation.

TL;DR

These are just a few key ways the right CMS can help facilitate culture change — in fact, my research turned up quite a few more, as well as several tensions in approaches to CMS design, including integration of user-generated content, the role of algorithms and computational journalism, and how CMSes should integrate with print content management. As newspapers continue to hone their digital strategies, more approaches to CMS design and open source tools will emerge.

TL;DR? When your editors are able to participate in and post digital content, you can facilitate a culture shift wherein developers are in turn able to participate in content creation and you get innovation. A custom CMS, built with input from content creators, can help to foster a culture shift in news organizations in which editors become digital editors, developers become journalists, and newsrooms become digital-first.

Lastly — to address a great question that was brought up during my talk: how can a small paper, like the one that inspired this research, afford to change their CMS? First off, no need to re-invent the wheel: Wordpress is a great foundation to build off of. Secondly, there are lots of open source resources that can be integrated into a patchwork custom CMS for smaller organizations. To name a few well-known organizations with github repositories: The Guardian, The New York Times, Vox Media, and FiveThirtyEight. Those are just a few — and even better for smaller papers is when other smaller papers open source their tools so they can work collaboratively to build great things.

Featured image via @iStudentConfTO on Twitter.

Why you didn’t read the terms and conditions

I recently worked a project for one of my courses on the usability of privacy policies. Our hypothesis? Privacy policies are nearly impossible to read. There are snarky commentaries online making fun of users for never reading privacy policies and instead accepting them, point blank. And it’s true that most of us are guilty of just that — but I don’t think it’s because we don’t care about the way people use our information.

Rather, privacy policies are designed for us to fail — there’s a reason most websites aren’t set up as massive walls of text. Most privacy policies simply aren’t readable. They’re written in inaccessible, jargon-filled language; they contain no tools for navigation; they’re not designed to scan; and they’re presented to us when we’re in the middle of trying to achieve a task, like signing up for an account, and are fixated on getting that done over anything else. (Check out NNGroup for a great readability primer.)

For this project, my partner and I did a literature review on research observing whether people read privacy policies and why they do or do not. Afterwards, we came up with a set of design principles for creating human readable privacy policies. 

Consent

These principles deal with the concept of consent, emphasizing that users should not have to give blanket consent all at once for a massive document. Rather, consent should be flexible and ongoing, and users should be able to accept certain parts of a given policy and reject others (as per Facebook’s privacy settings, for example).

1. Flexible/active consent: Users should be able to easily opt in and out of different aspects of the policy.

2. Ongoing visibility: Users should be able to view the policy throughout the site.

3. Ongoing consent: Users should be able to opt in and out of different aspects of the policy over time.

4. Just-in-time information: Sites should provide JIT privacy information to users during key tasks on the site involving use of their information to ensure clear comprehension is ongoing. (Fortunately, this is an emergency trend in privacy policy design.)

5. Update notifications: Upon landing on the site, users should be notified of any recent updates to the policy and able to view them in isolation.

Readability & legibility

These principles deal with basic concepts of readability.

6. Refined policies: Policies should be as concise as possible and employ short sentences and paragraphs. Similar policies should also be grouped together.

7. Simple design: Policies should be designed in a minimalist fashion and employ a clean Serif typeface presented in a large size that can be changed.

8. Plain language: Policies should employ plain language to express terms. (The research showed a strong consensus that natural language, though comprehensible to users, was often misleading and allowed organizations to sneak branding into policies. Plain language is a preferred alternative to express complex ideas clearly, without obscuring their meaning.)

9. Navigation: Users should be able to navigate through the policy through layered notices. (Layered notices is a term used in relevant literature to presenting policies using standardized headings.)

10. Consistency: Policies should, where possible, be presented in consistent formats across different sites. (This is an ambitious one, that would require standardization across industries! But some measure of consistency would greatly increase readability by allowing users to learn to read policies better over time as they encounter similar ones.)

Comprehension

Related to the above principles, these last four serve to address other means of supporting user comprehension by providing robust support mechanisms and using visual texture to present information more effectively where appropriate.

11. Support tools: Policies should employ support tools such as hints, summaries, and links to relevant documentation.

12. Explanations: Where necessary to express specificity, policies should employ relevant “jargon” terms but provide plain language explanations as well. (Twitter does a nice job of this.)

13. Textured presentation: Where appropriate, policies should employ visual texture to aid in comprehension, including but not limited to colours, visualizations, icons, and tables.

14. Mobile usability: Policies for use on mobile devices should be unique from website versions, employing textured presentation to improve comprehension. (This last one is meant as a nod to the unique problems posed by reading privacy policies on mobile devices, which warrant a set of design principles of their own.)

Future challenges

After presenting these findings to our class, we had them evaluate the privacy policies of some prominent sites with these principles in mind, as well as their own perspectives on design. We also discussed some future challenges for privacy policy design, like how consistency in design could be enforced, and whether people would read policies even if they reflected design principles like these.

Perhaps optimistically, I think they would (though also with good reason, since research shows that people in general are concerned about online privacy, even though their behaviour doesn’t always reflect that concern.) And regardless, organizations have a responsibility to users to create readable policies that allow them to make conscious choices about the way their information is used online.

 

Related links:

Some of the best (and some of the worst) – TIME rated privacy policies on some of the most popular sites online

What information is missing from those privacy policies no one reads, and why tech companies need to do better on Slate

Easy-to-read permissions from apps on the Google Play Store via Pew Internet

Notes from the 2016 IxDA Newcomers Design Jam

Earlier in January, I took part in IxDA Toronto’s 2016 Design Jam for Immigrants and Refugees. It was my first pseudo-hackathon experience and a bit out of my comfort zone, and I can happily report that it was a really fun day! I learned a lot, met some great people from the UX community in Toronto and from refugee service providers, and became involved in a really exciting project. Not only that, but my team also took home the Most Impactful award at the end of the day and won ourselves all the Kijiji swag a girl could ever wish for (thanks, Kijiji!).

The challenge

Groups were given the opportunity to choose from a variety of problem areas that were generously brought to the group by some amazing local social organizations. My group went with a challenge brought to the design jam by COSTI Immigrant Services, which asked for groups to design solutions oriented towards empowering refugees and immigrants to take control of the settlement process.

Monica Abdelkader, a Program Manager at COSTI who volunteered her time as a domain expert at the design jam, explained that newcomers to Canada often experience a sense of disempowerment as they rely on various service providers to get set up in their new country. They often have to depend on unreliable and conflicting information. Our challenge was to design a solution to help refugees and immigrants take control of their settlement process and avoid delays prompted by moving around between multiple service providers.

The process

With my four teammates, we started out the day by brainstorming initial ideas and pain points that emerged from listening to Monica describe the challenge and discussing it amongst ourselves. Right away, we were inspired by the concept of peer-to-peer knowledge sharing, and we sought to approach this idea through a mentorship service. The more we fleshed out the idea, however, the more problems seemed to emerge, which we discussed at length with Monica. In that conversation, a collective lightbulb seemed to turn on for the group and we came up with the idea of channelling knowledge-sharing more specifically onto a review service.

To explore the idea further, we created personas, journey maps, and use cases that provided valuable insights into user pain points and potential challenges that could emerge from our solution. Sustained by pizza and burritos, we made it to the end of day prepared with wireframes, some basic branding, and a preliminary business plan for our pitch.

The solution

Our solution was a service called MySettlement which provides immigrants and refugees with a mechanism to post and browse verified, anonymous reviews and experiences of service providers and programs written by fellow newcomers. Our solution stuck to our original concept of peer-to-peer knowledge sharing, but rather than employing mentorship to advance this goal (which is already offered by many agencies), we realized that an online interface would have broader impact and allow for immigrants and refugees to more effectively research their options to make informed decisions about where and how to access services.

So what’s next? My team is still in touch and hoping to continue to refine our idea and work with like-minded volunteers and organizations to collaborate and see where it goes! I’m excited to carry the idea forward, and to participate in more events like this in the future. That, and I am now in possession of a Kijiji-branded baseball jersey, which I’m hoping to pass off as a Jays uniform this summer. Updates on that, and advancing MySettlement, to come!

Usability and usefulness

Since starting at the iSchool, the term “usability” has become one I hear, think, and talk about most days of the week. This semester, in fact, I’m in two usability-related courses: a workshop on usability testing, and a human-centred design course. In another class, I’m working on a project on the usability of online privacy policies (spoiler alert: they’re not very usable).

We talk a lot about usability – but we talk a lot less about usefulness, as one of my professors pointed out in lecture this week. This has been on my mind a lot lately.

At one of my former jobs, we had to use a project management system that was, frankly, quite clunky. It was difficult to learn, finicky, and frustrating. At the same time, it was really useful to have one place where you could see everyone’s progress on a given project. So despite the fact that the system was frustrating, we used it. It was not an uncommon sight to see someone yelling at their computer over it, but it was rare that anyone neglected it.

Undoubtedly, that system had major usability problems, and resolving those issues would likely foster a happier workplace. But despite the headache, once you figured out its idiosyncrasies over time, you could work around its problems fairly effectively and get a lot of benefit from the system. In other words, since the system was useful, we figured out how to use it; and in that interaction, it became usable.

In my classes, we’ve been engaging in different methods of usability testing to build our UX toolkits. Recently, I worked with a team on a heuristic evaluation of the Scotiabank Toronto Waterfront Marathon site. (You can view our report here.) While there are several usability problems with the site, what struck me most was the depth of information on the site. Before it needed a usability intervention and the aid of developers, what it really needed was an editor to ask what information is actually useful to the site’s key user groups.

As my professor pointed out in my usability workshop, there’s really no such thing as a “user-friendly” product; usability is the outcome of an interaction between a given user and a given interface (or otherwise), and what works for one person may very well not work for someone else categorized in the same user group.

We can certainly improve products by testing for and striving for usability – but the first question we need to ask, no matter what our role is in the development process, is what problem we are actually trying to solve. Before we can make it usable, we have to make it useful. Usability, both through testing and evaluation and through users’ will and ability to adopt useful products, will follow.

Image by Ragesoss via Wikimedia Commons.

Why I’m getting my Master’s of Information (or at least an attempt to answer that question)

When I tell people that I’m at U of T for my Master’s of Information, I am nearly always met with a puzzled look. Information? Like, all information? You mean IT? (Cue Justin Bieber: What Do You Mean?) (This was the first reference to the Biebs on this blog, and you can rest assured it will not be the last.)

Usually, I give a short, laughing answer – something like “oh, you know, information systems” or “information management” – and just shrug it off.

The truth is that I don’t have a nicely packaged answer for what the degree is, or what I plan to do with it. Here’s what I do know.

I came to U of T thinking that I would eventually go to law school, but after a week or so of politics and economics classes, I realized that was not the case. I switched up my schedule and studied English and Jewish Studies. I liked it, and for a while, I imagined academia as the road ahead.

But then I started writing for The Varsity. Writing turned to associate editing, associate editing to editing, and editing to editor-in-chief-ing (which I’m declaring a verb for our purposes).

I liked writing, but I didn’t feel the same hunger to chase news stories that some of my incredibly talented colleagues at the paper felt. I was happy in my editor shoes, and even more so in my managerial role.

I became really passionate about working at the paper. I was excited to go into the office every week (or more accurately, every waking hour). I was passionate about the journalism, but I came to realize that what I was enjoying above all was the process. I relished the teamwork, the problem-solving, and the feeling of making something. One of my favourite parts of the job was working with the design team and talking through decisions based on students’ experiences as users of our print and digital products.

At some point in all of this, I decided to apply to the iSchool. I wasn’t totally sure that I had the right credentials for the program, but I saw that the type of work that I was interested in was happening in the tech world, and I was eager to develop the skills that would make me a more effective team player there.

I’m now a couple weeks into the program with about 200 pages of reading to do as I write this post, as well as an assignment due a week Monday and many more looming over the coming months.

In the past few weeks, I’ve learned what an Arduino is and coded one to broadcast morse code in LED lights, an abbreviated history of the computer, an introduction to Python, and a lot more than I ever thought I’d need to know about binary code.

So, what’s an MI and why am I doing it?

I think the answer is that it’s something like a hybrid computer science/management degree, or at least that how I plan to use it. I still don’t have a perfect response, but I’m learning a lot, and I’m excited to go to class every week – and if there’s anything I’ve learned from working at the paper (and for the record, there’s a lot), it’s to follow that feeling.