 Let's record here, or double back up goodness. Awesome, thank you. Hi everyone, thank you for joining me today. So I'm gonna be presenting Discovery to Launch, a UX focused case study for U of T Woodsworth College. My name's Aidan Foster, and I'm a front-end architect and UX designer. I help run the Drupal Toronto Meetup. So if you're not aware of what this is, it's a monthly meetup. We talk about all things Drupal. So if you haven't heard of it, please do sign up on Meetup.com and come and join us. My company also put together the Drupal North.org website, so the website sponsor, and the coffee sponsor. So I hope you enjoyed it. As my company, my company's foster interactive when we do a lot of work with small and medium enterprise, and we do a lot of work with the University of Toronto. We have built a distro in Drupal 7 that runs about 30 faculty of medicine websites. We've done the alumni.utoronto.ca website. We're working with University College and of course, Woodsworth College. So for the presentation today, I just wanna let you know that your mileage may vary with some of the items I'm talking about. We're gonna be talking, so I'm gonna be talking today about some principles that we use in our project management and our UX development for projects. But we take these same basic principles, but we kinda modify them for each client. And we're also evolving our process pretty much in every project we work through. So I'm gonna sort of tell the story of this one project and show some of the deliverables we used and created along the way. And so I'm not gonna dive deep into code or pattern lab or any of those items today. But what I'm hoping is you could maybe see our process and cherry pick a few ideas out of it and bring it back into your own project process. So websites and building websites for me really is about, it's a journey and not so much just a destination. The process with which we, the end product is of course important, but the process that we take to get to that end product is as important. And so this presentation today is really gonna focus on that process more than on the actual website, the finished product itself. So our project process is pretty standard. I imagine many folks do this. We break up our projects into phases. And so our first phase is discovery and information architecture. The second phase is user interface and design concept. And then we get into development. So first off, I just wanted to say a huge thanks to Woodsworth College for allowing me to do this case study today. There was no obligation to share the UX deliverables we produced along the road. And just a little bit of background on this particular project. University of Toronto is Canada's largest university and it's broken up into colleges which is a little bit different than most other universities. So there's five colleges and regardless of whether you go to the Mississauga campus, the Scarborough campus or the downtown campus or what program you enroll in, you're gonna get associated with one of those colleges. So part of the project itself is kind of or one of the challenges in the project itself was expressing what's unique about Woodsworth College compared to all the other options that are out there. Another challenge we faced in the project itself was the audiences for this website. So we have students, alumni and donors and those three sort of broad audiences need very different things out of the website. So we have sort of a diverse user group for the website. Final thing that was sort of a unique component of this is that Woodsworth College, one of its sort of unique aspects is that it focuses on programs where or it has a set of programs where students can join the college not directly from university. So it's more like a mature or an adult student audience and they have some pretty unique programs that we needed to feature. So starting off with the project itself, we start off with a discovery sort of phase and that usually involves a kickoff process where we assemble the team to assemble the team and you sort of roll things off. Part of that project, oops, pardon me. My stages are disappearing. That's not great. Anyway, I will just roll through and proceed. So part of the process and one of the core roles that we're looking at inside of our presentation process is that we're trying to balance in a fair way the needs of all the stakeholders that are sitting at the table together. So there's many different folks that have ideas and aspects of the project that they want to talk about. And so our job is to help try and balance out those competing needs. But we also become advocates for the people who are not at the table, which are the end users themselves. And so we constantly just need to keep that balance between the stakeholders' objectives and the objectives of our end users who are gonna end up using the finished product. So as part of this process, U of T itself is a very democratic place. So part of the project workflow that we're using to go through this. The builds are not working. It's no fun. Let me just restart this and see. There we go. Okay. Did all this work on cool animated slides and it wasn't showing up. Anyway, that's how it works sometimes. So our core team for this project, we were the UX and dev team working with a core team of three folks at Woodsworth. And we worked on a structure with two-week sprints where we met with a larger group of people, maybe every two weeks or every four weeks, but we had weekly check-ins with that core group. And we had an awesome core team on this project because that team had technical chops as well so they could help make technical decisions on the project. But in addition to that, we had team members with sort of political cloud and understanding of the inter-organizational politics of the university. And so having those two aspects covered on your core team was super useful in this project because we make technical choices and we can make business choices effectively with that core team, which was great. Then we added on, then we had about six other stakeholders, each representing one of the different programs or offices involved and inside of the website. Each team would be like one or two people kind of representing the interest of that particular program or group. And so, as I said, we'd have weekly meetings with the core team and then every sprint or two, two to four weeks we'd meet with a larger group. So one of the key aspects that we need to sort of consider when working in a big team is we like to sit down and collaborate with everyone at a big round table. And that's great for distilling out ideas. But it was also important as we go through the deliverables, which I'll talk about in a sec, is that we had individual calls and meetings with those individual stakeholders separately from those large group meetings. And so the reason that we wanna do that is that some folks are quieter and less comfortable sort of speaking out loud in a big group. Sometimes maybe an individual group disagrees with something that a bigger, louder personality at the table might be advocating and they're not comfortable expressing disagreement with that in front of everyone. So an important part of the project process was to make sure that we spoke with everyone individually about their own components in addition to having those conversations with the group at the table. So the first deliverable that we worked on with the team is creating personas. And personas are fictitious sort of persons that represent a group of your audience in the website. So in this case, we interviewed and spoke with stakeholders to generate our personas. In a perfect world, we would be doing a whole bunch of user research to generate that data itself. So we definitely, this is a bit of a risk trying to make the assumptions that your stakeholders know your audience well enough. But in this case, I feel that risk was mitigated because these stakeholders are the people who answered all the calls of the students answered and dealt with their problems on a day-to-day basis about the programs. So some of the risk that I would say comes from using a surrogate rather than firsthand data for generating your personas was mitigated a little bit in this project. But frankly, just in the timeline for this project, we didn't have time or budget to address that. So with the personas, we're trying to accomplish three main things. We wanna gain insights about our audience and gain empathy for the challenges and problems that they face. Personas also create a framework for the stakeholders to have disagreements where we can make decisions. So instead of two different stakeholders saying, well, I like this feature and someone else says, well, I prefer to implement this feature, we can reframe that conversation where we're saying, you know, that prospective student would benefit from feature A more than feature B and we can change the conversation so that we're not talking about what we like, we're talking about what our audience needs. And that really helps sort of steer the conversation away from sort of individual preference. And then the final goal for personas that we work on that we want to accomplish is get a list of the main goals that those personas want to accomplish when they come to our website. So this is an example of one of our deliverables for the personas for this project. So we created five, we've got students and alumni personas here. So Grace is a prospective high school student who's considering coming to Woodsworth College. We kind of encapsulate them with a quote at the top to sort of express their main idea, write a little story about them and outline the personality traits and some of the ideas that, some of the things that they like to do so that we can help imagine these people. And these are the goals I was talking about. The main accomplishments that these people need to accomplish are main things they need to accomplish by visiting our website. And these maps here are called user journeys. So they're expressing that person's, that their experience where they come to our website and how they navigate throughout it. And it's important to note that many goals, especially at U of T, which has like literally thousands of websites as far as I can tell, many of those goals that a person wants to accomplish where they end up on Woodsworth College's website, they're gonna start on arts and science, utoronto.ca, some other website. So we're just a part of their journey throughout the different structures that they're exploring inside of the website. So this is the second persona for a mature student. And we can kind of see that the main point of that is that the goals of a prospective high school student looking at Woodsworth College versus a mature student who's been at work and is thinking of coming back to university after working professionally for a while, they have very different goals. And so this is an exercise to help us explore what those different audiences need. So once we've accomplished creating the personas and we do this collectively with everyone and they go through rounds of revisions and improvements over time, is it's time to do the content audit. So we start off with the legacy websites that were using us the basis for the new website. And in this case, we have about four different microsites like a main site and other microsites that were using us, we wanted to amalgamate into the new website. So we start off by running a content scan, which is a software that we use called Screaming Frog that literally goes and spiders all the websites and creates basically a giant Excel file of all the links on that website. We then take the Google Analytics data and measure how many visits those pages, those individual pages have and merge that into that Excel file. And we create what we call as a content audit tool. So instead of Excel, we copy that over to Google Docs and Google Docs is nice because we can share it with the entire team and different people can work at the same time on the same resource and put notes and collaborate on it itself. So at that point, we've now got a scan of four websites blended together. And as you can imagine, there's like hundreds or thousands of links on these things. So we go in and we try and find the junk and get rid of any of the pages that we don't need to worry about from an information architecture point of view. So one example of pages like this is every single news article that's in any of these websites. We don't really care about, we're not gonna choose where to place those individual news articles in the information architecture. We're gonna worry about where the news page is and all the articles are gonna be underneath that news page. So we wanna try and get rid of that noise inside of that file as much as possible. And then finally, we wanna take every single page of all these source documents and assign a specific owner to those pages. So that those six content, those six sort of stakeholder teams, every single one of them got assigned every single page on the website. We can take a look of, it's a giant Google Docs file. So you can see across from left to right, the pages, the title, and then it's gotten assigned to. So those are the teams and we literally assign every page to those team members. And then the next step is we went through and reviewed those pages and made a recommendation. Do we wanna delete them? Do we wanna rewrite them? Maybe we wanna merge a couple pages together to kind of simplify it. And so we put together a recommendation sort of column and use those to discuss the topics. And then ultimately there's the action at the end, which is, whomever owns that page really should be making a decision about what happens to it, not us. So we just provide the recommendation and they decide what they're gonna do. Over the end, you can see the Google page views which is showing how much traffic that page has received. And so this document is actually sorted from most traffic to least traffic because we're assuming that in the website as it is now, if a page has more traffic, it provides more value to our audiences and aggregate. So by sorting it from most traffic to least traffic and there's sort of color coding that happens in there. It goes from green to yellow to red to white. You can kind of see that we wanna just start at the top of the document and work down and focus on the most important pages first because there's lots and lots of stuff to go through here. And you can see when you get down to the pages that have almost no traffic, it's pretty easy to flag them all and say delete because if no one's visiting them now, it's very likely once we build a new website, they're not gonna be providing value to that audience in the future. So once we go through this exercise, we now have a good idea of all the raw materials in the content audit that we need to consider when figuring out what the new website's design and structure will look like. And so to do that information architecture planning, we like to do an exercise called card sorting. And basically you take all of the rows in that Google doc and print them out on index cards and get them on a giant table and start organizing related topics together with index cards. It's a really easy and fast way to experiment with different ideas and different information architectures and sort of it's like a brainstorming exercise. And depending on the project, sometimes we do this with clients and sometimes we do it on our own and just use that to come up with the first draft of an IA to present with the client. In this case, we just didn't, we did it internally. But if you're curious about learning about that, I've got, there's a like a short video on lynda.com that was free to get you started on this idea, but I think it's really helpful and a good exercise for helping to brainstorm those kinds of ideas. So once we completed that, we load the information architecture into some software we like to use called slick plan. And this is basically the best software we've come across for sharing and organizing versions of information architectures. And so you can see this is the tree, the menu tree of the hierarchy and you can attach notes to things, which is useful and there's labels on the side there. So we sort of categorizing pages by their rough templates. So we're trying to start thinking about what different page types will eventually look like, but really we wanna get the labels right and the structure, the structure of the tree sort of mapped out at this point. And so we sit down with the team and, you know, propose this and then work again, this is a time for a working session where we get feedback and review on it. It's also a great place where we had definitely a couple break off calls with individual people because they're focused on a particular subset of the larger information architecture. So at the end of the day, through a couple rounds of revisions, we end up with an architecture that we feel collectively as a team is a good architecture for the website, but it's loaded with our own assumptions like the stakeholders are, it's really hard to see the trees from the forest when you're doing information architecture because we're so familiar with the content. So the next thing that we need to do is actually test that information architecture to make sure that it works for our audiences. So how we do this is we took the personas from the first exercise and took all of their goals and we basically dumped them all into one bucket so we've got a big long list of goals and we rewrite them as goals to tasks. So instead of, you know, Grace is trying to learn about first year programs, it gets rewritten as a task saying you know someone who's considering Woodsworth College what first year programs are available to them. The next step is we take the information architecture we created collaboratively and load it into some software for tree testing. So we use a software called Optimal Workshop and basically you can load that information architecture into the software and then we load in the tasks into the software as well and it basically makes an online survey where you're presented with a task and then you're presented with a just the navigation structure and it says, you know, try to accomplish this task and you click through that and it tracks absolutely everything about what you do when you're participating in the survey. So we took that online survey and emailed it out to a few hundred students and alumni to do a test round with our actual students and alumni. And so upon completion of that test we have amazing analytics as to how well our information architecture actually works with our audience. Let's take a look at that. This is an example of the link you'd see when you open up the email, the email invitation there. So up top it says, what extra curricular activities are available to students living in residence at Woodsworth? And you just have this bare bones menu structure and you can see I'm clicking through it and sort of exploring different places where I think I would find that information as you get down in the navigation tree, once you get to the bottom of the navigation structure, a button appears saying I would find it here. And that is getting tracked about whether I'm successful, whether I went down the path and then had to come up and find the correct answer or whether I'm incorrect at the end of the day. So that turns into this data. So you can see these pie charts, there's a number of different tasks. This is measuring how successful we were at each individual task with our students. So green is good, red is bad. And you can see whether the successes, you can see how much time people took. And then what's really interesting about the pie chart or about this type of tree testing is this pie chart display where this is a visual representation of a task that did not perform very well. And so for this task, we were basically, this task was to find the page where if you were an alumni, you could become a mentor to students. And so down the bottom left-hand side of the path is the green successful people who went down the community alumni donors, alumni mentorship program path. And that's what we expected them to do. But a whole bunch of other people went down the students support and services find a mentor path. So basically there's some confusion about whether you're finding a mentor or being a mentor. And so when we find problems like this, we can sit down with the team. Maybe we need to change the labels. Maybe we need to restructure the website. Or in some cases, like this page, we ended up deciding not to do that and instead decided that the content on these two pages and completely different sections of our website needs to include a link that goes back and forth between them. Because it's kind of reasonable, especially if you do a Google search, you might end up on the wrong page anyway. So the outcomes of this kind of tree testing are new labels, new structure, and then sometimes notes that appear on the information architecture map that I showed earlier, those notes. We definitely want to add one on these pages saying make sure that we cross link those two pages. So that completes the sort of discovery and information architecture portion of that project. And then we moved on to user interface and design concept. So we start off with user interface wireframes and we're really trying to accomplish three main things when working through wireframes. We want to explore the navigation patterns for our website because after a couple rounds of tree testing and revisions of that tree testing, we've got an information architecture mapped out that we have empirical evidence make sense to our audience. So now we got to figure out the best way to create that navigation in an actual user interface. The next component that we're looking at is also to create UI content blocks. So we want to start visualizing the content structure for various pages of our website so that the content teams and the stakeholders can kind of start to see how those pages are coming together and start thinking about how their content is gonna work. And then finally, because we use software called Aksure which ends up creating a wireframe prototype that's an actual functional prototype that's a website. So we can take that prototype and sit it down in front of users again and actually test to see how successful we are with some of these really early crude experiments in the wireframes and get feedback really quickly and make mistakes and change our minds and fix them really quickly. So this is an example of one of the wireframes from it. This is what we call a low fidelity wireframe which at the beginning of the project they sort of start low fidelity. So there's just big blocks mapped out with labels on it so you can kind of get a sense of what the content might be in a particular section. But in this one you can see that the navigation structure up top is actually functioning. So that's like a mega menu that you can click around and get a really good sense of how the navigation is gonna work. And if I'm creative comps and static comps just don't express how a navigation is gonna work very well to stakeholders. So having something that's functional that wasn't too expensive or difficult to implement is well worth the effort. We're now seeing a second page which we call like a high fidelity wireframe where instead of just big blocks of text you're starting seeing things that look like cards or news blocks or call outs, that kind of thing. And so it's sort of the natural progression for our projects is start low-fi, work to high-fi. And then you can see in this example there's another sort of navigation pattern appearing where it becomes a sticky navigation. Once you dive deep into the website and are exploring within a particular section that navigation appears and sticks to the top and might be one or two levels deep. And so when we say do user testing with these wireframes this is super informal, quick and simple user testing. In this case I just snag random family and friends to sit them in front of it because we're just testing the navigation pattern. We're not, you don't need to be subject matter expert to be able to provide meaningful feedback on whether this interface is working. And so the original version of this actually had the mega menu and then the interior sort of, the interior site menu were both sticky. And so just by sitting that down in front of someone they scrolled down and it actually, it became hard to use because they'd hover over the main menu by accident and then the panel would open and cover the other menu. So we kind of quickly learned that was a bad idea. It sounded like a good idea when we started but some quick testing shows that it wasn't good. So we just changed it to a single sort of sticky menu. To do this kind of quick and dirty user testing I strongly recommend checking out this book, Steve Krug's Rocket Surgery Made Easy. It's a short book, it's fun, and it's like, it's actually funny to read and it just gives you quick and concrete examples on how to do this sort of informal quick user testing. And I recommend it because it gives us really good results. So we worked together on wireframes, we collaborate with the teams, we go through a whole bunch of iterations and now we've got an idea of what the navigation might look like. We know what our information architecture is going to look like and now it's time to dive into some creative. And we always start this off with a kickoff discussion with the group. And the problem is the creativity or creative concepts are so subjective that it's really easy to burn a whole bunch of time and budget getting through creative in a project. And so to sort of frame that conversation we have a process to kind of steer us down a road where it's not a conversation of I like blue and I like purple. We sort of make a process to help guide that, to get rid of some of that subjectivity or to gain consensus about things that are essentially subjective. So before the kickoff meeting we invite the stakeholders to supply websites they like and we both go and we also reference websites that we like as well and basically use these examples in a presentation to frame a discussion about features and design elements inside of those websites. We also review any brand guidelines that might exist. So U of T has a brand guidelines document. Woodsworth College didn't have its own sort of separate one. And then finally we collect any digital or print collateral that Woodsworth had produced already and use that to reference because it's important to think about the new design of the website in the context of where it came from as well. Some other people have put a lot of time and energy into producing print materials and posters. So we don't want to just throw that all out. We want to think about those decisions those other people made and maybe build on top of them or maybe not but bring that to the conversation with all the stakeholders. So in this creative kickoff that we frame we talk about four main topics and all of these examples that we present with everyone are sort of in this structure of those four main topics. So the first is typography. The second is color. The third is layout. And the fourth is imagery. And basically these are the components that make up a visual identity system for any brand or for any website. And so we can show examples of other U of T websites and say, hey, do you like how the fonts are working on this website? We could, you know, there's many, many different U of T websites. Some are very blue and some are kind of white, you know? So we can frame conversations about color and by having examples in front of everyone, folks who are not, they don't have design language as part of their training. It helps us have a sort of common language where we can have meaningful discussions about these four topics and actually make decisions about them collectively as a group so that we can narrow the range of possible creative options that we could go in to a more focused sort of way so that we set the expectations for what the creative is gonna look like when it comes to actually producing the comps. So here's sort of two examples in our project. U of T has brand standards that outline colors and they have got a primary color palette, which is blue and then a secondary color palette which almost no U of T websites actually use but it's in the brand standards. And so we made a decision as a group. We don't wanna make a big heavy blue website but what we do wanna do is stick to the U of T brand standards. We don't wanna drift too far. And so we made the choice as a group that hey, let's explore the option of making the secondary colors like almost equal weight to the primary colors which would give us a unique look and feel but still be within the brand standards. So that was just something we hashed out in that discussion. Another example is fonts. So the U of T brand standards do express typography rules for print but those brand standards are old enough that I don't think web fonts were really a thing when the brand standards were created. And so there's many different fonts being used on U of T websites. UToronto.ca uses open sands but the U of T brand standards do specify that Trade Gothic is one of the fonts you're supposed to use in print layout and Trade Gothic now has a web font. And so we sort of sat down and made a recommendation and talked with the group and we're like, hey, let's run with Trade Gothic as the main font for the website and explore the possibility of introducing a second font like a title font for headings or to use very sparingly inside of the creative. And so just got consensus amongst the group that this is where we're gonna go with fonts and so we've basically kind of narrowed down the options with regards to typography and fonts to a more limited set. So that leaves layout and imagery where we're gonna really explore in different options. And so by doing this, it also sets a stage where the creatives show up and someone's like, well, I like script font. Well, we all agreed in the previous meeting that we're gonna go in this direction for typography. So it really helps make the creative process go more smoothly and we actually take the results of that first meeting and write it up in a document which we call creative brief and send it around to everyone and get approval on it. So if someone disagrees with what we talked about you know, what's encoded in this document like actually know we meant this, we make sure we revise that and include that in the brief before we send it around to everyone. So then on to the creative presentation itself and because we've set the stage in sort of a formal way here it went really smoothly on this project. So we normally show up with two creative comps. This is an example of the one that was selected and you can see that we like to frame the creative presentation so that it's got a web browser frame around it or it's on a mock up of a phone to help people understand the context for how this particular, so this is the homepage element will change in depending on the nature of the device you're looking at. And so, and then we literally, we had two different options. Just discussed them in with the group entirely and actually ended up picking this option in that meeting which is great, that's what we wanna do. Pick a direction and then we're set to go. We have a number of wireframes already produced that had the basic layout sort of explored so we can just iterate on this basic idea and expand it out into the other, to create creative comps for the other sections of the site. So we're at now in the project flow. The content audit is the raw materials that the writers need to work from. The information architecture is a map of where we wanna go and sort of the map of all the content that we're gonna need for the project. The creative comps themselves express the design and the art direction and the design intent of the website and then the wireframe sort of express how some of the navigation is gonna function and the content hierarchy for pages that aren't really rendered in creative comps. So I've got a question for the room, okay? So audience participation time. So raise your hand if you have ever been on a team that's launched a website and involved in the launch of a website. All right, so keep your hand up if you were working on a website and the launch was delayed for some reason from what you expected, okay? And then keep your hand up if that delay was related to content, right? So most of the room kept their hands up for that and we can definitely, I can say from my own experience that 95% of site delays are tied to content. And so really we have an extra step in the process that is our attempt to mitigate the risk in a project related to content even when we aren't the people who are producing the content. So we have a content writing workshop with the team. It's usually around this phase in the project where the wireframes have to be very far along the road. The creative comps, we've got some ideas there but there's probably still more in production but that doesn't really matter at this point. And so in the case of most projects that we work on we don't have a dedicated writer on the team for the project and we're not producing the hundreds of pages of content there. So what we like to do is have everyone sit down and do a bit of a workshop. And in that workshop we cover three main things. We talk about an editorial style guide. So actually before we have the workshop we work with the client to set out a set of standards for writing. So you might talk about verb tense, you might talk about pronoun usage, you might talk about inclusive language, date formats, all this stuff gets put together in a writing style guide. On Woodsworth it was great, we had a client who became the champion for dealing with a client, one of the team members became a champion for dealing with the editorial style guide and actually kind of recommend don't try and own the style guide as a third party coming to the table. It's better if the clients own their style guide themselves because they're gonna have to write to this style guide long after we leave the project anyway. So we wanna make sure that it's not us that are the people who are responsible for it. And so the next component that we review in that workshop is writing for accessibility. So accessibility has tons of components in a website project. Your design has to have sufficient color contrast to be accessible. Your site has to be coded in such a way that it's accessible. But it also has to be written in such a way that it's accessible. So we need to talk with the team about heading tags and nesting them in the correct order. We need to talk about writing good and meaningful alt tags that aren't logo, that kind of thing. It needs to help express what the meaning of those images are. And also things like writing style where you don't wanna do huge blocks of text. You need to make sure that one to three paragraphs is broken up with the title, that kind of thing. So these are all important parts of making sure that the end product that we create is accessible. And then the final component that we talk about is the inverted pyramid writing style. So this is kind of a journalism one-on-one thing where basically how we learn to write in university or whatever in the essay format is the exact opposite of how journalists write. So the inverted pyramid writing style, you put your conclusion up top as the first thing on the page. And then from your conclusion, you provide your most compelling supporting evidence and then the second most compelling evidence all the way down to your least most important support of the conclusion. This is the exact opposite of how we learned how to write essays in school. In essays, you put forward a thesis, provide the evidence, and at the end of the essay, you provide your conclusion. And so writing for the web, that format doesn't work. It's not scannable. People start at the top of the page and they're like, no, and then you get a page bounce. So we need to talk a little bit about the inverted pyramid writing style just to get everyone on board with making sure that the content they write is impactful. I also forgot to mention the editorial style guide by having that in place, really what we're trying to accomplish is that we've got tons of different people writing content for the website. And we wanna make sure that that writing doesn't look like it's been written by tons of different people. So it's the same sort of tone and style. Another part of the content writing workshop is a review of what we call the component library. So what we're seeing here is a little piece of the wireframes, the wireframe version of a user interface component that we called a course card. And so you can see on the left, the wireframe version and on the right is what it appears as in creative comps. And then the middle, the instructor for the course is like an optional piece of that particular component. So we review with everyone all the little components that they can use to construct the website out of. And they need to be writing not long form blobs of text. They need to be writing text that will fit into cards that are, cards and other user interface components that match this kind of layout. So this is an example of a wireframe page that's like a step-by-step guide on how to register for something. And you can see there's a whole bunch of components that make it up. So there's a call to action at the bottom, these sort of expanding accordions and so on. And so this is the component library itself where this is the header item and there's the wireframe version and the creative comp underneath. And there's notes on like how long the titles should be and whether a piece is optional. So you can have a button or maybe you don't have a button for that message component. And so we review the comps and we identify all the pieces that are available to the content teams that they can use to construct their pages. Then we move on to sort of the workshopping part of the content sort of workshop. And so we asked everyone to show up with one or two pages of content from the old website to work with collectively together. And we try and like noodle through all this process together. So what we did was just go to the old website, copy and paste the text into a Word document. And then the first process is to go through that and look at that Word document and then look up the component library and try and match pieces up. So you can see, you know, this top part of the Word document was like a list of stuff. So we've got a list component. So that's like a good match. You literally just print it out and like circle it and say list. You know, maybe you're sure, maybe you're not, question mark. And then underneath we had a list of courses. And I'm like, okay, course card component, that's a good match there. So the first step is simply just to, just to look at your raw content and try and match it up to user interface component that we might have. The next step is then you take that raw content and copy it from the sort of, you know, the raw Word file dump into a structured content template, which we provided that's also just a Word document. And basically each component piece gets a row in the table. And so when you're copying across, the first thing you do is copy that raw text across and then review it for editorial style and then review the components and try and, you know, get the titles to the right length and identify the optional and mandatory components for that and write the content in this way. So after the workshop, they went off and produced tons and tons and tons of content. And we end up with a whole bunch of structured Word documents, which have some, you know, have some SEO components as well as the search engine optimization components in there, but the advantage of doing this is now we've got a structured content document that is going to match and, you know, when we start writing the Drupal website doesn't exist, but much later in the project, we will have a Drupal website and the website's gonna be built with exactly the same patterns in mind on the Drupal content administrator interface. So we use a module called paragraphs, which basically allows us to go into the content administration and you press a button saying add a course card and it will have exactly the same fields that we mapped out in the original content document. So it's a very simple exercise of copying and pasting the content as it moves from the structured content document into the Drupal website itself. Gather content is a software tool that does a similar job to what we're doing in just in Word documents here. And so it is a really good tool. So I would suggest to look into it if you're considering, you know, thinking about writing your content before the website's built in a structured way. But for the team that we had on this project, it would introduce a new software product that we would have to teach them to use. And so we all ended up making the call that the overhead of learning gather content wasn't worth the benefits that it provides compared to Word documents. When we went through the content writing workshop, to be honest, there was mixed results with the team. Some people it clicked with and some people it didn't click with. And I'm not really surprised because we're asking someone to think about accessibility for the first time, to change how they think about writing content and then to kind of cross reference, a palette of interface options when they're writing. But despite that, some of the team members who had the most content, it did click with. And it really, you know, if you don't do anything, it's just your site's delayed and the content will be all over the place. So it's a step in the right direction. It's not perfect. But if you do nothing, we knew it would just be a dog's breakfast when it comes to the content at the end of the day. So now we're on to the sort of the third phase of our project build. And I'm really not gonna talk too much about the website development itself in detail, but the front end theme that we use to create the website is built on a front end stack that we called mainspring.io. So it's an open source, basically bootstrap project that we use for all of our work. If you wanna check it out, you're certainly welcome to. mainspring is really a toolkit that we use that makes our process faster when we create websites. And it's got really three main pieces. It's got a bunch of automated task tools built into it using a technology called Gulp and a different tool called Node. And basically what that does is allow us as we're writing our website code, it checks to make sure it's to the correct syntax that we agreed upon as a team. It does things like optimizing images and managing repetitive stuff like icon sets and so on and keeping those optimized. The next piece of it is a very opinionated structure on how to organize your code and how to name things inside of your theme. So an architectural choice that comes pre-baked with it. And then finally it provides the ability to create what we call as a living style guide in the theme itself. And so we'll just take a look at that now. So what we're seeing is this is a website that's automatically generated from the mainspring sort of toolkit using a tool called Pattern Lab. And the code that we use to create what the website looks like and the code that generates this website are the same code. So if we take a look at this, that's sort of the title styles that you can see inside of there. And it basically makes this documentation of all the pieces, all the user interface components from small things like type and buttons all the way up to more complicated elements. So for example, this is a message component. So now you can see all the variations, you know, of messages that are available in the website. We're combining typography and buttons or it's optional, so maybe not a button and the icons. You can see how in Pattern Lab we're building from the very simplest pieces into more complicated pieces into whole chunks of the interface that these chunks line up with the component library items that we're talking about in the content writing section. And so these pieces can be combined together to construct the website. And what's really important is that this isn't a secondary style guide we create after the fact. The code that generates this documentation is the actual code that the Drupal website uses to render. So this is a huge topic on its own if you're interested in diving into it. I've got another presentation from talking about advanced front-end architecture. So if you're curious, check out the link there. Another interesting piece that I felt from a technical and development point of view in the Woodsworth website is we used for the first time CSS Grids in a production website. So CSS Grids is a new feature available to web browsers these days. And it's a really powerful tool for being able to do more complicated layouts. This sort of overlapping mosaic approach that we put on the homepage would be difficult and perhaps impossible to implement without using CSS Grids. So you can kind of see how this is at play. So this is, and just to note, Firefox browser has the best CSS Grid debugger. So if you're working in this, you definitely want to be working in Firefox. So I've turned on the Grids where you can see there's both vertical and horizontal lines and you can see how the overlap here is lining up with half the card over here and these cards down here. So CSS Grid gives us the ability not only to line up vertical columns in a seen and reasonable way inside of our layouts, but it's also horizontal columns means becomes something we can control, which has really never been something we can do in web design. So it's definitely been a major benefit to our practice in general. If you are interested in learning about CSS Grids, Rachel Andrews has a website called gridsbyexample.com and it's an awesome resource with tons and tons of examples on how to do CSS Grids. Another component I'm proud of in how it got implemented in the website is actually that navigation and we were looking at it in the wire frames, but you can see how it actually turned out in the final website. We've got our top level navigation as a mega menu and then once you go into a subsection of the site, it becomes sort of a sticky nav that is one or two levels deep depending on how far in the IA you're sort of descending. And so this is basically like one of the more customized parts of the project itself but based off of our initial UX work, we were really sort of discovered that our audience itself tended not to go across different sections of the website and they'd go into one specific thing and spend most of their time inside of that section. So it's almost like an approach where we're treating the different sections of the website as microsites inside of a broader project. So the launch, we launched it went well. The stakeholders were happy and we got good feedback on the site and then there's plans to do new and enhanced features over time to the website, which is great. I just say the key takeaways from this process that I'd like to sort of leave with is that it's really critical to get key stakeholders involved early and often in the project. Changing a wire frame is easy and redoing finished code is expensive. So you want to show and get people used to seeing rough ideas that are just implemented enough to express the idea, get some quick feedback on it, do a user test and then move on to the next item so that you're making your choices when it is less expensive to change your mind earlier in the project. And you can see in our process really everything is structured around this idea of reusable components or the idea of the component library. The design and the layout are created with these ideas in mind. The content is written from the team thinking about the structure of those reusable components and then the Drupal theme itself is implemented and coded with these components underneath the hood that generates the pattern lab and then ultimately generates the website. And then finally on the admin UI on the Drupal side of the implementation, we use paragraphs as an analog so you can place an individual component in the page, maybe make a grid of them or whatever. And so really what we're trying to do is keep that core principle of reusable components across the entire continuum of the project from both the design and planning phases into its actual implementation. So thank you, thank you very much for listening. We're like everyone else at the conference hiring so if you're interested in this kind of work and would be curious about working with Foster Interactive, please do talk with me or check out the website link. And so thank you so much. Is anyone have any questions? Yes. How do you or do you use any kind of system for tracking? Tracking, communications that come in through different methods, right? So one of the biggest challenges that we have is that we'll have people text and calling and DMing, what else is there? How are you tracking all of those different communications? Yeah, so the question is, how do you track all the random communications that would come in from the multiple stakeholders? Yeah, so in the Woodsworth project, we were blessed by having a really awesome core team. And so the core team tracked everything through their own base camp, which they managed all of the stakeholders and funneled the requests that made it to us had already been vetted before they went there. So we were very fortunate to have on this project. In other projects though, I've seen sort of forcing everyone either through Slack or JIRA or Combo of them to say that feedback, if you're reporting a bug, then you can set up your bug tracker to probably receive an email at least. So you're like, bugs go to this email and then it generates a ticket and when there's not enough information on there, at least you can send it back to them and be like, well, what browser were you using when that bug was reported? But yeah, I would say setting the stage for that, that's one of the very first things you need to have as a conversation with the team. And so, yeah, if you could have a, I guess in classic agile, this would be the product owner is what that core team was. And so if you can have them be the conduit, then that would be great. It's either gonna be that or a project manager on your side and on your team who can filter out the random requests and the, what about purple? Coming after, we're at a creative phase and it's like, well, that conversation was supposed to happen a long time ago. So great idea, but maybe phase two. That's a good way of addressing things if for random requests, yeah. Yeah, sorry? Going back to the grid, do you ever consider kind of the rule of thirds in photography and that golden mean idea and I'm doing websites, is that playing at all? So it's funny, the CSS grid I feel is actually, so the question is, have we considered the rule of thirds in the grid's layouts for our designs? And it's funny that the grid layouts that are done in websites, you'll often see a 12 or a 16 column grid because there's basically like a tradition in web design to use a 12 or 16 column grid because doing the math to calculate a grid used to be really, really painful. And so there's grid tools out there that helped make the math easier and that's why we tended to use those grid systems. CSS grid has freed us from those constraints but we still have the habits that we've learned and so we have to learn, because it was our first production project with CSS grid, we didn't wanna try two new things at once. Changing your underlying grid system and the technology you use to implement it adds a little more risk than I'm comfortable with on a particular project. So I'd actually suggest stick with something, don't do a wild crazy new grid design on your first CSS grid project but just get used to it and implement some of the things that it's really good at. So that flexible layout reflowing the components was like, I don't know, 30 lines of code. And an old website, we would have tried to have done this without using CSS grid before and there would be like 100 lines of code and maybe some JavaScript to get the same sort of effect. So because CSS grid has opened up these options, we can now kind of return back to the oranges of grid and print design and like more graphic design principles and start to bring that back into our design practice. And I expect to see better, more graphic layouts and websites in the near future because a grid tool is becoming viable. Yeah. I would have tons of questions, but I don't wanna. I was just curious, going back to your beginning of the process, when we were talking about generating those personas and the user journeys, how did you come up with that user journey? Like how did you get to those specifics? Did you interview the stakeholders or? Right, so the question is how do we come up with the specific user journeys on the personas? And so that was definitely done through very close interactions with the stakeholders. And so in the case of someone who's answering all of the inbound student calls, they kind of know what the major problems are that the students face. So we actually start out with the goal. We know that the students need to figure out how to pay their tuition, right? And because these are common inbound questions that those folks are fielding. And then we know that the Woodsworth website is in a continuum of U of T websites. So it's unlikely that the first point of entry into our website is actually just going to be someone typing in, you know, wdw.utoronto.ca. And so because of that, we can kind of know where we can have a reasonable guess. It's going to be the arts and science website. You know, certain other websites are inbound traffic in Google Analytics showed that these are our top traffic sources. So we know that a lot of people are coming in here. And so the user journeys don't need to be perfect and they don't need to cover every possible scenario. Really what you're trying to do is cover the most common and most important scenarios and make sure that those experiences are optimized inside of your information architecture. It's actually a way of prioritizing the features and content in your website itself by the very nature of agreeing that this goal is important. It means we put time and energy and testing to make sure that that ends up being easy. And you know, it's possible that there's, you know, a ton of other goals that a smaller percentage of the website users will need to accomplish. But really it's just trying to get that idea of prioritization. And that requires a lot of work amongst different stakeholders because they'll have different ideas about what's most important to a first year student depending on whether they're on the program side of things or the registrarial side of things or in residence, that kind of thing. So it's definitely a discussion process. You go through tons of iterations. And really it's creating these stories that we review with everyone. It becomes a process of going talking with everyone and saying, hey, is this story realistic? Like, have you met someone who's kind of like this? And that sort of gut check that comes with the subject matter experts is really the only way without intense firsthand user research to get at that information. How do you keep track of things that when the clients want to change a single component and you want to check if that change contradicts in the places the component is in? Right. So the question is, when a client request comes in where there's a change of component, how do you ensure that it doesn't harm the existing structure or design integrity? That is where having, it's a tricky process where actually part of the process when you get to the content writing phase is that your component UI library might not include everything you need. So it's actually kind of baked into the process itself where someone says, oh, actually I need a table display of stuff and there's no table display in the component library. So that's something that actually came up. And so really the one way to mitigate the risk is you take a component that's already existing, you don't touch it and you make a variation of it, which is a new sort of cousin to the original component and you leave the original component alone and now there's a second option which is in the same family but maybe has additional features or fields or elements so that you can leave the original one in place. Yeah. And again, thank you very much for your session. I was curious, what was the structure of the theme and what was the time and investment from the very beginning of the process till launching the website in hours or per week? So I don't have the top of my head. No, the hours per week, but it was a seven month project but U of T basically shuts down in December. So we took a break in the middle there but I think it was about seven months from start to finish to get the project out. And so our team structure was myself doing UX, UI work, two developers and our art director working on the components of the site. So discovery phase of the site? So discovery phase doesn't involve any developers and really it was two of us mapping through most of the work in the discovery phase. So in your UX and UI work, were you doing content strategy as well or were you relying more or working more collaboratively to all of the content with the U of T standpoint? Right, so the information architecture process was blended with the content strategy. So we weren't gonna come back and be like, your messaging needs to follow these lines. We came with the assumption that the stakeholders for each group would be responsible for their own sort of messaging strategies. And then, but it's sort of an indirect way when you're hashing out an information architecture to get through what are we prioritizing, what's the first and most important message of each page, an indirect way to get through that content strategy sort of component without a formal sort of separate step. So I think a lot of the process should scale or grow with different projects. Right. If you were working on a smaller project or a bigger project, what would you do differently? Would you just spend less time and kind of remove details or add details to each of those sections? Or would you cut something or add something more for a larger project? So the question is if we were to scale to a smaller or larger project, how would we change this process? And it even isn't scale that would dictate whether we change the process. If we had a central command and control in a non-democratic environment where someone's just gonna make the calls on things, we'd actually probably modify the process a fair amount. Generally, the larger your information architecture structure needs to be, the more testing you're gonna need to do because there's more things to kind of go wrong. On a smaller, a 30 page website, we still do it. Still wanna do a round of UI testing, but you might do great on the first round and you're like, okay, good. The labels make sense, our audience are happy with it. We can now be confident that this is a good structure. And later in the project, when someone comes back and says, hey, let's change the navigation structure, you can go back and say, well, happy to do that, but remember, this is validated and tested and we know what's gonna work. So if you change it too much, we should probably do another round of testing, make sure we didn't harm anything. In a larger project, yeah, it's basically, you would probably start adding in more formal phases like content strategy sort of approach, maybe formalize the writing component more so that there's multiple different phases or step to go through the content. So in other projects, we've had challenges with content where the first pass was to write everything in bullet points because we had to do a whole bunch of brand new content, get everyone to approve it, and then the writers come back and rewrite that as pros. So yeah, so it's really important to be flexible and adaptable to the nature of the stakeholder teams to adapt those processes. Also, in other projects, we've had our in-house writer, so that phase is done. We don't worry about it. We say, you guys got a tutorial style and we're like, oh yeah, and they're far more sophisticated than we are with regards to that craft and so we can just sort of delegate it to them. In this project though, we did actually have a phase at the end where a writer came back and reviewed everyone's content for consistency and style, just as a last pass to make sure it felt like it was from the same person. So that was a good element to introduce into a project that's like this because no matter how much, someone, it's gonna drift a little bit. So you wanna make sure that it sounds, all the content feels like it's coming from the same place. When you showed the actual wireframes, I'm curious to know if you showed it with your client in a formal presentation like this one or was it more that you're standing, send us your feedback, so how did that? Yeah, so design elements and user interface elements, we always present in person because there is so much subtlety that comes out of, especially because everything's so subjective, that reading the body language at the table is super important to make sure that you can get alignment with folks. If someone's not happy with something and not mentioning it, we wanna know that, bring it to the front, be like, what are you concerned about and not make it, we've done this upon you and it's not something that we, we want it to be something we all built together. And so if someone doesn't, if someone's gonna be told no, it's by consensus and it's not us just saying no to that design choice. So definitely, we wouldn't have a presentation for like wireframes because they're interactive. So we fire it up and browse around the website and talk about how that works and then questions will come about individual pieces. The content brief and the, you know, in creative reviews, definitely a formal presentation that we run through to sort of craft a story about even when presenting the creative, we make sure that we reiterate everything we agreed upon in the creative brief before showing them anything so that because it's been a couple weeks or whatever, so we wanna make sure that we remember that we agreed to do certain things and that the deliverables that we're looking at are created within that framework we all agreed to. Yeah. Just something specific to main spring IEL. Cause I know we're both at U of T in Scarborough, by the way, and we're kinda in-house laying sort of everything. And I was willing to adopt a framework like this. I was looking at something, we're still a little bit established by that. Right, right. I was looking at Zen at the time. Right. And I found it quite steep in terms of everything that you need to understand to it. Like, do you have any sort of advice as to how it would be easier to adopt or to migrate and adopt such a framework? So the question is, is there any advice on how to adopt either a base theme or a framework into a Drupal 7 site? So that's a tricky question. As an organization, we do not actually use popular Drupal base themes because we find that all of the assumptions that have gone into how they're coded and structured don't work well with this component approach. So that's why we ended up spinning up MainSpring because nothing out there really did exactly what we were looking to do. I also feel that Drupal 7 and Drupal 8 are two very different beasts when it comes to theming. And so in Drupal 8, there's way, way less dependence on using a base theme than there was in Drupal 7. Just across the boards with different teams, it's kinda rare to see too many websites using a base theme or in the same way that was very popular in Drupal 7. So I would say you kind of need to think about what general approach you wanna do and whether you want to really create your theme from the ground up or whether you want to just adopt and learn someone else's pattern. So it's two different exercises, right? You have to, learning how someone else does something is in some ways harder, at least for me, than imagining what we want and building it from the ground up ourselves. So I would suggest checking out, so these are all Drupal 8 themes. Are you guys thinking of going to Drupal 8? Yeah, I'm not sure of the time, but we want to go there for sure. Right, so there's a starter theme called a Mulsify and then a company called Phase 2. Both have these starter themes that are worth looking at. And check out MainSpring as well and we don't have the most amazing documentation or anything in there. It's really like a tool that we're using for ourselves and it evolves and changes fairly rapidly. So a Mulsify by Four Kitchens and I'll forget the name of their theme, but check out Phase 2. The company has their own base theme and basically they both use and are different ways of using pattern lab inside of your Drupal theme to let you worry about building those individual components and then you can use Drupal to sort of plug those pieces together. And I really do truly feel that that's the best approach for a theming strategy because it makes sure that you don't reinvent the wheel. You don't make 15 different kinds of buttons randomly throughout your website and it avoids problems like CSS naming conventions sort of colliding where you name two things titles and somewhere else in the website you accidentally change the font in an unexpected way. Great, so we're totally over time. So thank you very much everyone. Take care, have a great lunch. So lunch is being served upstairs in the main room.