 Right, hi everyone. Welcome to Unsiloing Your Project Team with Collaborative Sketches and Digital Prototyping. We're going to be talking a bit about how you can use Collaborative Sketches and Digital Prototyping to supplement your existing UX approach and how doing this can benefit your project team, your clients, and your company. So we'll be talking a bit about how we made the change, what challenges we were trying to address originally, how we incorporated these two approaches into our existing approach, and finally the success stories and benefits that we've had during this. First, a little bit about us. We come from a DC-based firm, Rock Creek Strategic Marketing, and I'm Kat Kuhl, our Director of Technology. With me are Ika Lestari, our Senior Graphic Designer, and Michelle Chin, our Senior UX Strategist. We put this presentation together to show how this approach could benefit three main groups of people. UXers and designers who get more engagement from other people on their project team up front. Developers who tend to have more well thought out requirements by the time this reaches the development phase, and who can have early input into some of the deliverables that they might have had changes to if they had an opportunity to review them. And project managers who tend to get better thought-out products early in the project timeline, and who can have savings in their timelines when this is implemented. We put this together to address some of the challenges of our previous approach, which had been using only wireframing. While we still use wireframing selectively, we found that using wireframes only can lead to some problems because of the way the process works. By default, you're going to have a UXer who spends some time putting together wireframes, revising them, presenting them to the client, revising them, and has that happen a few times according to how many revision rounds are specified in your contract. This leads to lots of revisions, and ultimately we act like we're trying to make a static artifact perfect with our performing wording changes and tweaking that really could be done during the development and design phases of the project because we want to get this right. It's the deliverable the client is expecting, it's in our contract, and it takes on more importance than at times it necessarily should have. We also find that when you're working in a siloed environment where the UXer makes wireframes, hands them off to the designer, they get handed off to the developer and ultimately put into QA, there are lots of handoffs that happen along this process. There are lots of opportunities where the UXer might be saying, I really want it to work this way telling the designer that the designer passes it along to the front-end developer, gets passed along to the back-end developer as well, and you end up playing a game of telephone because you're trying to communicate complex functionality with what boils down to a paper concept. Because you're having a lot of revisions and a lot of handoffs, you're going to have a lack of engagement throughout the project from people who don't get involved quite as early as they should. This is a problem because when everyone on the team understands what's happening at the project, there's opportunity for input. Your accessibility analyst might end up red flagging the fact that that map concept you just proposed is going to have some serious challenges for keyboard-only users and that you need to invest time up front thinking about a fallback. Your designer might say that that approach you're putting into place is really going to look difficult, really challenging on a mobile phone to get that much information on the screen. And your developer might say that that's going to take a lot of time and effort to implement the way that you've laid it out, but with some few small tweaks, it could be a lot more easy to do within your existing timeline. When these people don't get an opportunity to contribute to the project until later, you miss the opportunities to hear your subject matter experts give this kind of feedback and incorporate it into what you're putting forward. This is something that's faced as broadly as a company, but there are also other changes that have faced individual teams. Probably the most frustrating part for developers is that we end up having a lengthy wireframe phase followed by a lengthy design phase and then an equally lengthy development phase that we're cramming quite a lot into. You end up doing your site building, module installation, module development, theming and migration all in a fairly small window of what can be a significantly long project. This means that you're crunching a lot of things in at the end that you could be starting a lot sooner when you're planning for them. And it also means that when you get down to crunch time, you're going to be some things that are overlooked that wouldn't have been overlooked if you've been spending more time with the development along the way. The other development challenge that we've had a lot is hearing the phrase, but now that I see it, once things are actually taking shape, if you're working on something responsive, there's no way that a wireframe or even a design can communicate the full scope of the functionality you're going to be putting into place. Even with heavy annotations, annotations can be misinterpreted, and people have assumptions that don't always necessarily connect during this time. Your designer might think that you're going to have a great-looking design on this mobile phone, a great-looking one on this tablet, and Fablet's probably going to work itself out more or less. So when they end up seeing what their responsive site looks like on a Fablet, they can be a little bit horrified. And you might have misconnections as well between your UXers and your developers about how things are actually going to be powered during this phase. So for designers, even though we were involved during kickoff, we don't really come into mid-stage of the project. And what that means is we often end up asking a lot of questions about why are things being placed in that location? Why are things supposed to function this way? So we find that we waste a lot of time just trying to play catch up. And instead of doing the real design work, we just try to gather a lot of information. Also, having to deliver a JPEG mock-up, it's really easy to misinterpret functionality because it is nothing that's fully functional. You don't really design something that's for a browser. It's really hard to be transparent about how visually, how your visual elements are supposed to work when it comes to functionality. And when it comes to responsive designs, you have, let's say, if you have a carousel design that's really elaborate on your 27-inch monitor. If you have this mesh up of two images together and you have header text, you have caption, and also a link on top of that, it doesn't really translate as well when it comes to mobile. So you spend a lot of time and effort just getting buy-ins from time members because you do have to spend a lot of time explaining what your vision is. How do you want these visuals to work? And you just have to make sure that everybody is on the same page about how your visuals are going to work. So from a UX standpoint, I often face challenges that include designing wireframes in a vacuum. I have to get my concepts down on paper, and I have to get them far enough along so a developer can understand what I'm trying to explain. And that often takes a lot of time. Not only that, I create high-fidelity wireframes. And these wireframes are pretty complicated. So I have a lot of interaction, a lot of details listed in them. So when they go to review, maybe a developer has a suggestion, say we'll have to use another module instead, I actually have to go back and update them. And that's a lot of work. So that can be a little taxing for me. As you can see, I heavily annotate wireframes. I'll add lots of, because these are paper-based wireframes, they're static and they have no interaction, I have to annotate all the interactions. So I have to say what's going to happen when you roll over one item, what happens when you click the submit button, I have to do a lot of explanation. And I take my time trying to explain all these interactions so everyone can understand them. But even with the hefty annotations, they still get misinterpreted. Sometimes Dev might misinterpret what I said wrong. And the designer will feel the same way. And it's really frustrating for all parties involved. In terms of accessibility, wireframe concepts make it difficult to identify accessible trouble spots. So we can go ahead and wireframe something else and the accessibility analyst will say, yeah, I think theoretically that's going to be accessible. This should be cool. All right, awesome. So then we go on, get signed off from the client, and then we go to development. And all of a sudden, when we're developing it, we realize it's not exactly accessible. So it's the 11th hour. We're having to find an alternative or adjust things. And that's just adding more stress to everyone. All right, so with all these UX challenges, Dev challenges, design challenges, accessibility challenges, you know, we thought maybe there's some other way that we can do this. What's something else that we can do? But first, what did we really need? We needed something easier to understand. We also needed something quicker to iterate upon. Something more realistic. Something that involves everyone earlier. So what could that be? For us, it turned out to be collaborative sketching and digital prototyping. So collaborative sketching brings everyone on board, your entire team on board earlier on in the process. And digital prototyping presents something that's easy and very realistic to understand. So we'll talk about how we got to the collaboration process and how you can implement that at your company. So first off, it's a little bit of a paradigm shift. Making the change to collaboration involves a lot of steps and here are some of them. So you want to pick a small project and not just, you know, it could be a small website or a smaller portion of a bigger website. And you want to pick something that's small because it's less risky. When it's less risky, more people are willing to try it out. It's also manageable in size. So you don't want to bite off more than you can chew when you're trying something new. Because if all this fails, if this collaboration exercise doesn't work out, you still have some time it's quicker to recover. You also want to get buy-in from your teammates. So what I did when we tried this project out, I went to everyone on the team and said, hey, would you be up for trying out the sketching approach? I think it might help us. I think it might make things easier. And people actually were really into it. Even people who I thought weren't going to be into it were really up for trying this out. All right, so who do you want to involve? You actually want to involve everyone. That includes UXers, developers, designers, accessibility, analysts, content strategists, project managers, everyone. This way you get everyone started on the same page and you guys can get a glimpse of what everyone else does. So for example, the project manager when we tried the sketching, she was just like, wow, I've never tried wireframing. Now I kind of get why it's really challenging. And when Kat provides a solution to a really complicated problem instantly, I'm like, wow, I don't really have a programmer's brain. I can definitely appreciate her insight. All right, so you also want to set expectations when you're establishing this process. You want to tell people sketching is going to lead to a prototype. It's going to be different. There's not going to be any paper wireframes. And let's face it, wireframes are only great for UXers. This could make your life easier, maybe. You know, we're all trying something new to make improvements to our process. But since it's new, it could be a bumpy road, but that's okay. Everyone's willing to try it, so let's get pumped. All right, so how do we sketch collaboratively? There's a couple things and I'll go into the stuff that you need. When to sketch, what to sketch, how to sketch, and some pro tips on sketching and leading the discussions. So what you'll need, you'll need markers, all colors, sizes, everything, paper, eight and a half by 11 to 11 by 17 paper, lots of paper, because this is a sketching activity. Masking tape to post up the designs to a wall. Scissors, some people make mistakes and like to cut them out. Sticky notes, because some people make mistakes and like to cover them up. That's my personal choice. Snacks, so this is a new process for everyone. And in order to get them kind of relaxed, we provide food. We also provide music, because we want them to be into doing this activity and we kind of want to, you know, take away some of the apprehension that they might have. So choosing the right space. When you choose a space to do these sketching sessions, you want an open area, something that has plenty of space where you can stick up designs, and you want it free from distractions. So here we are as our conference room with a big whiteboard wall and we're all sketching together and posting our designs up. So what are you going to sketch? And this is where the UXer comes in. You take your site map and evaluate the site map. You want to look for things like main pages, like a homepage, landing page. You want to do pages with unique features and functionality, so anything that might be complicated or something that could really be really cool, like a gallery, and responsive design versions of the above. So you want to keep that in mind. You want to avoid like saying, oh, we're going to sketch this like interior page, because interior pages, you know, some basic interior pages are kind of boring. All right, so what are you going to sketch? And I like to do a three-part process. So the first part is the pre-sketch meeting. It's about 30 minutes long. I like to actually do this on a Friday and then have people have the weekend to think about it and then start sketching on the Monday. So in the pre-sketch meeting, we'll just go over some ideas and some basics about what they're to expect when they actually do the sketching. So the second part would be the actual sketching sessions. I'll start off small and have like an hour and a half to two hour sketching session, and if needed, we'll add another sketching session. Some people like to do like eight hour sketching sessions. That gets to be really long and really tiring, especially if you're trying out a new process. So you want to start small. You can always add more sketching sessions on if you need it. And lastly, after the sketching, we do a discussion session. And again, I break that up into an hour and a half to two hours long, and sometimes we might have an extra discussion session if we still need to have more discussion. All right, so the pre-sketching meeting. During this meeting, you're going to set expectations. You want to talk about what site you're sketching, the goals of the sketching, the types of pages you're going to be sketching. And also, if you're trying out this process for the first time, you want to explain to your team members what's going to happen when these sessions. So you're going to say, you know, we're doing this meeting now, we're going to do some sketching, and then after that we'll follow up with some discussion. Also, during this pre-sketch meeting, I provide background information. So that includes stuff like the site map, so they can get a lay of the land of how this site's going to work and the pages that they're sketching. I'll list the pages that they're going to sketch, but I'll also add features that should go on those pages. So I'll say keep in mind, you know, at the home page, we need to have a Twitter feed, an events feed, and a recent blog posts feed. I'll also include any user research, so like personas, scenarios, anything that can give them an idea of who the users of this site will be. And previous project work. So one of our clients is Education Pioneers, and prior to that we had done a lot of print collateral for them, and they wanted us to do their website redesign. So I took a lot of the print collateral, brought it to this meeting, and showed everyone, hey, this is kind of the look and feel that they're going for, this is the kind of tone that they're taking with their materials, so let's transfer this to the website. All right, so now we had the pre-sketched meeting, and now we're onto the sketching. So here's a picture of us sketching wildly. There's music going on, snacks to be had, lots of sketching, so we'll go ahead and sketch a couple ideas. We don't have to sketch every page indicated in the sketching session. Some people will pick two or three to sketch, some people will try to do all of them. After you make a sketch, you post it on the wall, and you might be thinking, well, if I told people what pages they need to sketch and what should be on them, aren't you going to get the same sketches? Sometimes you'll get some duplicate sketches, but sometimes you'll get other ideas. So for example, we had an upcoming meetings page and a lot of the sketched grid calendars, and then some of a sketched list view, so you do get quite a variety. So we'll do some more sketching, and it's a very iterative process, lots of back and forth, and it's pretty fun. Here are some pro tips for sketching. You want to encourage everyone to sketch. This is going to be something new to a lot of people. Some people might be intimidated because they're sitting next to UXers and they're sitting next to designers. They're like, oh, you know, I don't want to have to pick up a marker in front of them, they're going to critique, they're going to judge, I know this. Creating a relaxed environment, encouraging everyone really helps. And remember that no idea is a bad one. So maybe you have someone that's sketching out a video gallery, and you're a project manager going, oh my gosh, we don't have any budget for video. We can't use that sketch. You know what? You can repurpose that sketch. So maybe instead of using a video gallery, you have a photo gallery instead. And one of the biggest things for sketching is pay attention to everyone's energy level. If you've scoped out an hour and a half sketching session, but people are starting to fade after 45 minutes, maybe you cut that sketching session short and regroup again later on the afternoon or the next day. You really want everyone's engagement because this is really important to have them all on the same page and not really hating what they're doing. All right. So we're on to the discussion session and here we have everyone's designs posted. So what are we going to do with this? For to facilitate discussion, we all pick a page. So say we'll start with a home page and we'll go over idea. So it's kind of like a show and tell. Everyone will stand by their idea and say, well, I have a carousel doing this. I have a Twitter feed here. I have this functionality and we kind of explain how things are going. People can ask questions. You know, what did you mean by this? You know what happens when you click this link? After we go over all the discussion of all the ideas, we'll pick one sketch. Maybe one sketch isn't perfect. So we'll end up taking parts of some and we'll kind of put together the best of to make something really cool. It's a little Frankensteining and that might make people, some people nervous. But that's where the UXer comes in. So the UXer should really use your UX skills. You want to make sure that all the ideas are being properly vetted, that they're using good UX practices and that they're presenting a comprehensive functionality. And also it's really important that someone take notes. There's a lot of discussion that goes on, a lot of ideas that get yade and a lot of ideas that get made very instantaneously and change directions very quickly. So it's really important that you have someone taking notes to figure out what the final determinations were. Some pro tips for discussion. So UXer and project manager use your facilitation skills. This is a great way to practice facilitating group discussions. And it's also really important to make sure that everyone is heard. This is a collaborative event. You definitely want to make sure everyone is heard so they can get more buy-in and more say with what's going on. And this is probably the biggest part of discussion is vet the ideas with your teammates. So we're all in the room together. We are all sharing ideas and so rather than you know walking over to my desk like in a traditional method of having to wait and pass emails back and forth I can ask my developer right then and there hey can we do this in the timeframe and they can say yes or no the accessibility person can flag it saying I think we're going to have to adapt it for better accessibility. All the experts are in the room right there. They have a say and we can navigate the challenges very early. So what's next after we've discussed stuff it's your turn to have the UX designer. Take those idea and what I'll usually do is create lo-fi reference sketches for the developer. So this usually means I'll take you know whatever the sketches are maybe take some post-it notes and annotate what we finally decided or if I feel that it's easier I'll take make really low low fidelity omni-graffle sketches and just make annotations for the developer. So the developer was already in the sketching session so they pretty much know what to prototype but this is a good final reference checklist. This isn't actual client deliverable it's just an internal resource. And then I'll take those sketches and then I'll work in tandem with the developer to begin building the prototype. So as you're hearing about this you might be wondering whether we never wireframe. That isn't the case. Wireframes are a communication tool and when used properly they're a good way to get sign off and a good way to spell out what's required for different ideas. If we're going to be prototyping if we're going to be doing the UX for a mobile app that's going to have a lot of functionality that would be extremely difficult to quickly prototype we'll put together a wireframe for that functionality. We have a very contentious homepage that we know is going to go through a lot of changes but the point when the client sees it and would rather go ahead and block out the major elements on paper we can do that. What we do try to stay away from is creating a lot of wireframes for different sections of the site that would be much faster to prototype with proper site building. Ultimately wireframes are a quick and dirty communication tool that are going to give you a lot of connection with your client if you do show it to them but they don't think out everything and you need to make sure that when you're building out an interactive site you're paying attention to the medium you're going to wind up working with. I really liked this quote from a Brad Frost recently about the static artifacts kind of clouding the fact that you're ultimately designing for a real website. When you hover over that dropdown something's going to happen. When you click that photo it's going to get bigger. When you play a video it's going to respond and that's not going to happen on your wireframes unless you are crazy good at wireframing. So ultimately we want to get people into the browser as soon as possible and have these connections start getting made in an interactive way. Some people like HTML prototypes. There was a point when we worked on these we were attracted to them because they're quick to build. Once you start putting content on the page you add in your HTML elements add classes style those classes add in some JavaScript functionality. It's not instantaneous but it is pretty quick and pretty efficient initially. The problem is that they're not underpinned with any sort of content management. So when you need to go in and make changes based on your usability testing or based on internal review it's pretty painful to change 30 different pages than a prototype especially when the way that you're changing things is changing across all of them at once. If you're linking to an event and you're initially not providing a description when you do your event linkages and then you realize you really should it's going to take you a while to go back and add that everywhere an event is featured. And that additional time you're going to be spending is extremely frustrating because you know that at the end of the day you're building something throw away. You're not going to be reusing this code in a meaningful way in your final product because while you might have some semantic elements and classes that you can move forward in the process your designer's probably going to change a lot of things during the design phase and you might end up doing a lot of recoding anyway. By contrast if you are making a Drupal prototype it's going to be slower to build up front. You're going to sync a lot of time into site building but you're also going to find that now it's being underpinned by a real content management system. So when you need to change something you can do it quickly. If you need to reorder the blocks on all the pages that are news release template at once you can just do that. If you need to go ahead and change how your views work by adjusting a view mode you can change it once and have it update everywhere it's being used in your prototype. As you might imagine you're going to be syncing a lot of time into this so it's a good thing that it is laying the groundwork for your site. You're going to keep using it as you move through the process and when you finish the UX phase you're not just going to have a prototype or a wireframe you're going to have the beginnings of your site built. This is great because it means that as you move forward you can start immediately doing content migration. You can immediately work on some backend functionality you might need to build a custom module for. You're not emerging from it with an idea you're emerging from it with groundwork. The last time we did an HTML prototype was for the Federal Trade Commission Center the Federal Trade Commission site that we launched in December. This was a pretty comprehensive HTML prototype that had about 30 pages in it. As you can see here it's got a lot of dynamic content being pulled in this is the news and events page show it shows the news and further below some of the events and they're also featured in the right sidebar the very important upcoming events. You also have a content being pulled in in the drop down and featured throughout other places of the site. So if you're using your news releases and your events elsewhere then you're going to need to be updating that. We have topic pages that also reference these and every time that you load in a news release or add a new news release to your prototype you have to make sure that it's getting added to the relevant pages. We did build this out we had a successful usability testing phase and we went back and made modifications it's fairly time consuming. The lesson we took away from this process was that doing these prototypes in the content management system you're going to ultimately be building them in gives you a lot of time and efficiency that you're saving. For the commission of fine arts which we're going to be talking about a little bit later we built out a fully functional prototype all the content types taxonomies and views and masonry photo gallery and some map functionality in about two days and put that in front of the client with great results. They were thrilled with it and we were able to let them navigate through the prototype and the pages of content that we've loaded in a fairly organic realistic way. So at the point when they signed off they had a really great sense of how their site was going to work not just what it was going to look like. Another great thing we found as we're implementing this is that you're going to end up seeing your timelines look a lot different. Unlike the original timeline we showed where you have your development kind of happening at the end this way you have your development spread out through the process and collaboration points throughout that. So during the prototype phase you're collaborating heavily with your UXer and your designer and everyone else on your team and you're doing your site building your module installation and a little bit of migration so that you can support these content types and make sure that they make sense. This lays the groundwork for you to do a much heavier migration phase during the design part of the timeline so as your designer is working on tweaking the final look and feel of it you're making sure that you actually have the functionality built out and that it's working really well. It gives you a lot more opportunities for testing. Then when you get to your development phase which as you can see is now a little bit shorter you can handle your theming and your module development anything else that you need to do and you have more time for testing and QA. There's a warning that goes along with this though because you are not throwing away this product when you're done it gives you a tremendous amount of responsibility to get rid of the things you don't need. So when you're prototyping and you're saying I think the piece of content I think this content type would work really well if it had an event association then you realize later that if you put the association on the event content type and point it to the news release it's going to work better you owe it to yourself to go back and remove what didn't work out. You also need to make sure that if you installed several different modules that do the same thing you turn them off and uninstall them when you're done. This means that you'll end up having a better product and you're doing the same kind of curation that you would be doing on your final site because this is going to become your final site. As we're creating digital prototypes just like creating a Drupal site it's going to fall into a handful of buckets with one notable exception. We have front-end tasks site building tasks and content migration tasks but not back-end tasks during this time because we don't want to be sinking time into doing a lot of custom module development during this phase. The intent is still to have a fairly quick touch point for your client to take a look at not to have your entire site complete during this point. Your front-end tasks should be fairly minimal. You'll go ahead and install a prototype theme. You don't want to be doing too much customization to it because your designer is then going to have all kinds of changes and we usually tend to install a bootstrap something like that that we're not going to put in our final build but it quickly gives us a professional look and feel to show the client and make sure that they're going to be pleased with what they're seeing as opposed to turning on bordering all the boxes in zen. During this you want to consider your source order and your positioning making sure that you understand how your sidebars are going to degrade during the design phase and giving your designer some structure to work with. This is a heavily collaborative effort between the developer, the UXer, and the designer because it's pretty major decision point whether your sidebar is going to end up rolling down beneath your content whether your menu is going to roll up above your content you want to start answering some of these questions now and you're going to sink some time into adjusting the mobile experience as needed. So if you're using a prototype theme that doesn't really handle your mobile menu very well this is a good time to make sure that you tweak that before the client sees it so that you can give that organic experience of resizing the browser and having them understand roughly how it's going to end up working. Your site building tasks are slightly more intense. The first is that you need to build out the site map in your menu structure. Doing these menus is going to be a lot faster if you use a module that will allow you to place content within the menu without actually migrating that content up front. I like the module's special menu items because it allows you to put non-linked items in your menu and then clearly know you need to go back and load that in later. You'll set up your content types your taxonomies and your views during this and make sure that you're setting up those fields on the content types in a way that you can live with later. So this is where you're going to add a lot of functionality that's going to get reused and you can see it taking shape in front of you. We came out of our last prototyping effort with nine content types 10 views and five taxonomies built out fully so that we could continue iterating on them during the rest of our effort. We like to make persistent block associations whenever possible so that as you're doing the site building that's going to make different blocks appear on say your news releases. When you change themes later those associations are going to stick around. I like context for this personally because if you're going to place them with the core Drupal functionality as soon as you switch your theme all your block associations are going to go away. You'll set up your aliases and breadcrumbs during this so that you can see where your content is going to end up living and how people are going to navigate between it. So if you have your news events path set up so that it's just content slash title that's not really useful for anyone and it doesn't reflect how people are going to navigate in your site. Spending the time to set that up and make sure your breadcrumbs are functional here it's going to give a great authentic experience of how people are going to interact with it long term and it's going to force you to address any logic errors you've made if you said that your news releases were going to have a path that put them under about but you forgot to stick them there this is where you're going to be able to catch that very easily. And of course you'll install modules to provide more complex functionality. Some modules are very basic and they're always going to be on your site like views. Others are going to be added to prop up some of the functionality that you might be building out even further later. For example in one version of the site we had a calendar that we knew we were going to end up doing a bunch of custom work with to leverage the calendar a library but we just put in the generic views calendar for our prototype because there was really no need to get to that level in our prototype it was something we could iterate on later with the client as we got them introduced into it. During this phase I do tend to use the occasional alpha or beta module so long as I'm flagging it for later and we know very clearly when it's going to be removed and are keeping some way to track that so you don't have direct winding up in your final product. This is a screenshot from the prototype we're doing for the federal trade commission site you'll notice it is not black and white like a wireframe because we're building inside the theme for the main FTC.gov that we'd already done. What this does is add in the main elements that are going to be in the final product it's extremely functional we went ahead and imported content before we did just about anything else and this helped us catch some logic problems really early in the process so under here you see you might also like along with a short description that was in the content we originally provided and I talked to to the UXer a lot about this because having related content appear here is no small feat and I initially got the response that it was going to work based on taxonomy so we looked at the taxonomy to see if it was going to support some relevant associations here because there was a fairly a fairly large taxonomy and a fairly small number of publications we ended up seeing a lot of reuse of that taxonomy so that what would have appeared here if we just said show things tagged with the same items it wouldn't have really been coherent and it wouldn't have populated the right content onto the page so we took this back to the client asked them how they would like to have this function and it turned out they actually wanted complete fine-tuned control over this so instead we have a node reference that points to what publications are associated with this publication this is something that we wouldn't have found out if we'd just been looking at a wireframe we were confronted with it early and we were able to work with the client to make sure that they knew how they were going to be putting content in here and that if they wanted to set it up like this they needed to provide that information things like this only work really well if you're looking at real content so the most important thing we do during our prototype arguably is to migrate content all the content we put in many pieces of content for each content type and if we have access to a database we can simply import we go ahead and do that to the extent that we can with scripts or with feeds occasionally so this is going to make it so that when you're looking at this product you have a very realistic idea of what your client's content is going to look like when it goes into your prototype now inevitably you are going to end up putting in some Laura Mipsum as you're building this out I we try to avoid this really really hard but if you are knowing that you're going to put in some test content I like to add a Boolean checkbox value to the content type just for test content so that I can check that off and then go back and remove it all later that way you have it tracked and you don't run the risk of having it wind up there when you really weren't intending for it to happen so we'll talk about some of the success stories we've had with this approach probably one of the bigger ones was the Federal Trade Commission site this is the original site that they did the prototype we put together and as I mentioned this one was an HTML prototype and the final site that we ended up with and the reason we're talking about this even though it had an HTML prototype when really what we're advocating is the Drupal prototype is that the reason this effort was successful is that we did a ton of Drupal prototyping along the way we did our initial 30 wireframes but at the time when this site launched it had about 60,000 nodes of content and many different landing pages all a lot of them with unique searching and filtering functionality we'd rolled in some external databases that really expanded and were tweaked to take advantage of the new Drupal content management system this was challenging because with that much variation happening in the site the fact that we had so many content stakeholders became kind of an issue there are many people who were subject matter experts in the FTC content within the FTC and all of them had thoughts about how their content should look so rather than trying to make assumptions based on the wireframes that weren't complete for the sections that we were showing we worked with them to prototype in Drupal present it explain how it would be maintained and what kind of features we built in to make management a little bit easier for them and have them come away with it with a good understanding of how the site was going to work in a lot of cases we showed this to them and found that there were certain distinctions between pieces of content that we wouldn't have come up with organically and that we needed to tell them we need to work with them to find out how they would be pulled out in the content in the final product this has been a really successful engagement for us and as we've moved on to doing additional sites for the FTC like the commerce site that we're rolling into their site now we've relied increasingly on prototyping wireframing out complex pages like the home page or things that would be very difficult to prototype quickly like a modified checkout process but leaving prototyping to do the rest like the faceted filtering for the publications the publication view itself and the language switching between these all right so for one of my projects I worked on education pioneers which is a non-profit placement organization that has a fellowship and partnerships that they pair potential fellows with we originally had a nine-month timeline which already seemed pretty compressed but then that got squeezed even more narrow into a six-month timeframe so that's how this digital prototype really helped us it helped us get further faster we quickly sketched some ideas and then threw that into a prototype which laid the groundwork for the actual site another benefit of this was to demonstrate our client to our client that there was a lot of cross-referencing from pages to pages so you know city pages would show up their fellow display their fellows and upcoming events related to that and they had a hard time understanding that that's how the approach we were going to take with the site but once they saw the prototype they got it oh I see you know these events that are related to the Bay Area are going to show up on only on this page yes and only the people that went to the Bay Area are going to show up on the page so it really helped them understand how their content was going to be used throughout their site so another example that we did digital prototyping for was for U.S. Commission of Fine Arts this is actually their current site and as you could see it's very static so we thought having a digital prototype would really help them kind of transitioning towards the more dynamic content and kind of reel them in during the transition process so this was the digital prototype that we have internally we made sure that we strip off any visual elements that say we make sure everything is very gray there is no color elements and even for fonts we make sure everything is very basic we don't want any elements that the client will kind of get hung up upon even for little things like the logos we did not want them to kind of focus on that and we really want them to make sure that all the structure on the homepage is clear to them so with this we also have an upfront discussion internally that there is nothing that designers can't change we could still move around the positioning and having all this structure established upfront we were able to kind of push the design to the next level so we had to actually present three different designs this was one of them so we were still able to push it and we kind of curate more on the user experience what could we do to kind of push their side to the next level so we come up with three different with the carousel where we have a little bit of the next and previous slide and we where users could have that bigger experience of what the agency is really about the next design is really different instead of having the bigger image we have a set of thumbnails and it's very open and minimalist in the next one we actually tie in all the content with a bigger image bigger visual component and we were able to bring three different design solutions that wasn't at all tied in to the prototype and that was great so the benefits of collaborating, sketching and digital prototype is one you were able to navigate challenges early since we no longer work in our own little corners we're actually able to talk to each other more openly we could we don't wait till issues to come up during 11th hour we could tell them oh what happened if we want to do this FAQ when there is no content all those issues actually come up front and we could iterate more quickly on the design concept we no longer have to come up with a new design component on a layout since all of those little things were established we could actually focus more on the UI elements and if you're doing your prototype interval you could actually reuse your work since you already have your views content types modules and even general configuration all of that actually took place early on and will save a lot of time for your theming and you could actually content migrate your content early on so having a fully function prototype easily demonstrate your responsive behavior so let's say we have an event or a table you could easily see what things would collapse ahead of time as it was waiting later on so you could use your functional prototype to get buy-in from your team because you have actually collaborate and talk to them about it faster and get what it's going on and you could get buy-in from your client since they understand what's going on they understand what's the functionality is so they could actually give their approval in a timely manner and you could do usability testing upfront all right so we have some key takeaways from this presentation that we would like you for to remember the first is smart start with a small project first it's easier to manage and if all this fails you can recover from it quickly keep communication open so this is a collaborative process this is going to be a little bit different than a traditional siloed process you're going to be talking a lot more so make sure that you're keeping those communication lines open that might mean that might mean working sessions with a developer if you're a UXer or a design you know working session with a UXer or we all just get together and hash out more stuff after we've done the wire framing when we iterate upon the prototype this is also a great way to establish collaboration as a company culture so you have new staff bring them into sketching sessions we've done this with a couple new people they have you know they weren't UXers we had them you know come in and wire frame with us they had no idea about UX and they loved it and it's just a great way to prepare them for when it's their turn to sketch that they're ready for it and the biggest thing is that you need to remember that this is a process and to be adaptable so when we first tried this out we started small I actually didn't give anyone any background information I was worried that it was going to give them tunnel vision as to what they were going to create and then after that I realized that you know people were hesitant to sketch because they were like I don't really know what's going on I want to make sure I'm doing this right so I provide a lot of background information so every time we've done the sketching process we've taken lessons learn and applied that to our next sketching session and being adaptable really helps so part of being collaborative is being adaptable and that could be anything from a small as you know someone doesn't want to sketch with marker they want to use pencil instead you know that's cool but it also could be something bigger that the timeline shifts you know for example you might need an extra sketching session or maybe an extra discussion session so being adaptable is really important in order to make this work the more adaptable you are the more this process is going to work for your company and that wraps it up if you guys have any questions feel free to ask you can come up to the microphone and ask do you yeah okay have you ever involved your clients in the sketching discussions so far we haven't and part of it it's we want to make sure that we know what we're doing ourselves and sometimes a lot of clients start to dictate things and as we started this process everyone's still getting comfortable with themselves to end up discussing the minute you bring a client in everyone's demeanor changes thank you so I had a question on the whole sketching process you're involving everyone on the team for a particular project when you get together to sketch is that right yes so we'll have we have a cross-functional team so it's usually a front-end designer or a front-end developer back-end a designer maybe two designers a UXer depending on how big the project is but basically whole the entire team like content strategist everyone even like project manager yes okay so you know presumably one of you has more experience or expertise in the whole idea of of UX and I was just curious what if you how it benefits your team to have everyone producing sketches versus maybe just one person doing sketches and then maybe asking the team for some feedback well so that's a really good question you know this is a great way for us to get to know a little bit about how we all do our jobs so for example you know I'm not a developer so I'm not up on all the latest modules but Kat is so when she's sketching she might sketch in a module that she's just heard about that she thinks is going to be really great for the site or Ika who's a designer knows some design tips that I don't really know so we'll go ahead and collaborate all those ideas so even though like they're not UXers by heart they do know a lot of information and they're great resources and they bring a lot of ideas to the table this is a follow-up to that first question can you talk a little bit more about at what points in this process you're showing things to the client and at what point they review it and sign off for example do you I know you don't bring the client into the sketching process but do you show them the sketches at all? so it varies based on our relationship with the client some clients want to see something a little bit more formal so we might hold off until we see the prototype at times if we're producing some lo-fi reference wireframes as a result of this we'll certainly show them at that point but the main thing we're trying to get at is what the goals of the client are and how we're going to serve that by showing it to them so if we're demonstrating a lot of interactivity then we're probably going to wait until the prototype so that we can show them really how it's going to work but if it's more informal and we're trying to say we think it would be a great idea for you to pull some of this content up and surface it on your home page or on these other pages then showing them a sketch gets them on that page faster it's not formalized in terms of when we're going to show them things but it's usually at the prototype phase always and often a couple of reference documents before that when needed and can you also say a little bit about usability testing and where that fits in so our usability testing process tends to come in when we have a functional prototype we don't usability test our sketches but we do try to usability test when the contract calls for it with the prototype as much as we can and that's dictated by the contract that we have so we've had a lot of success with walking people through that in the same way that they would interact with the site it lets you get a lot of that data much sooner than you ordinarily would and in a more meaningful way than when you're using like a clickable PDF great thank you do you have any ideas on how you would handle the sketching process with a fully remote team I would imagine that would be challenging we don't we haven't had to implement that with a fully remote team because we are working in the office with the exception of some backend developers so the sketching has been in person I imagine you could do something like like screen sharing to put that together and work in something prototyping tool there are quite a few out there but since we're trying to keep things more informal it's not a challenge we've had to tackle yet thank you so with these projects are they project based or are they hourly how do you have you noticed like a change that going over budget because you have such a collaborative team how does that work so we actually we have a mix sometimes they're hourly and sometimes they're project based but what we found that anyone wants to contribute what we've found on that is primarily that we're front loading a lot of the work we would have been doing anyway so while we are having a lot of these discussion sessions as you can see a lot of that time is time that we would have spent getting people up to speed later in the project anyway so we have people in the room who are contributing and kind of for stalling problems that would have been spent afterward our accessibility analysts for example get to contribute early and say you're going to want to watch out for this as opposed to doing an extensive review later and finding a lot of problems they need to document and then work with us to fix so our idea is that we're not creating additional work we're front loading work that would have been done in the later stages anyway I've worked on a lot of projects where there's a lot of similarities do you guys find yourselves using some things over and over again from project to project and kind of recycling things how do you work between keeping things silent from project to project or being more efficient and saying hey we use this in the past and it's a good solution and we're going to use it again I think that's actually helped by having more people in the room when you're doing this because what we're bringing to it is the knowledge of the solutions that we've used in the past we know for example we've gotten really experienced with maps and calendars lately so we're not going to re-imagining how they work every time when we do need to use a calendar a map we tend to use previous projects as reference points when we comes down to actually blocking that out but pulling in different layout elements we're trying not to be constrained as much by what we've done previously and be open to new ideas while relying on previous solutions when they've been time tested and shown to work well Do you package any of that into like a feature that you could then transport from side to side? We have not been packaging any of it into a feature at this point we do have sometimes we'll produce modules during the process of working on previous sites so we might take a module we produced and plug it in to move forward but we don't tend to use features to create new content types for example or to pass views from site to site because generally speaking these things have been pretty unique to the project it would be hard for us to apply for example something we came up with for the FTC Drupal prototyping process to the commission of fine arts because it's wildly different contents and different goals Thanks Quick question on Let me try that again Quick question on migration What happens in situations where you don't have say you're moving from unstructured information to structured where you can't actually migrate it or there's been a strategic change in direction of what they want and so the content they had before really isn't relevant So that's always it's always painful on any project when you're going to be making a big migrations shift like that what we found is that doing this has actually made it easier for us to communicate with our clients when we especially when we have a large migration effort but their content isn't going to map one to one because it allows us to see what we're going to need to do in order to get the migrate to get the content in the site and it also we get to work with them on how they're going to be working in a new content management system as opposed to in a static site so for the prototype purposes we're only moving over a few pieces of content for each content type so copying and pasting and mapping it to fields is not really that terribly painful a process although it's of course easier if you have a some sort of structured data you can pull from but having these conversations during this prototype phase as opposed to assuming yeah it's all going to come in and it's going to be fine we're just going to script it is makes things a lot easier later because you're realizing how much of a change your content is going to have to go through in order to make it in when they're writing content from scratch it's really pays to have your client understand what it is that they need to provide for you at this point and how their content is going to change and if you have a content strategy phase on your project which hopefully you do your content strategies is a huge huge resource during this time yeah thanks so the biggest prototyping tool that we've been using lately is a Drupal I don't know sorry that's a terrible answer what we've been using is mostly just laying setting up the site building the way that we're going to want it to function ultimately on the site I know we've used some other prototyping tools in the past but we've found that they haven't communicated the interaction on the back end as much as we've wanted we haven't been able to create those dynamic relationships and ultimately we are not huge fans of creating throwaway projects so I'm sorry okay the question was what about wire framing tools Michelle you want to take that one sure so I've been just using the sketches as what we keep as a record and then I'll annotate with post in it so I don't actually use software sometimes if things are more complicated we'll use Omnigraphl I found that's been really helpful they've got a whole nice stencil pack so that's primarily what we use but we try to throw things into the prototype into like a Drupal prototype as soon as possible one one quick note on that there was a session yesterday if you're really interested in prototyping in wire framing tools it was wire framing smarter and he had a lot of hey there's my login screen he had a lot of great suggestions for tools that you can use I think the video of that is online now if you want to check it out okay so the question is what modules we use to help in the prototyping process go to the microphone Lauren and we've been using a lot of different modules that have helped out with that as I mentioned special menu items has been helpful for building out the menu really quickly we use views obviously I really prefer context for block associations because it makes things more straightforward and I we spend actually a lot of time importing content with feeds when we need to rather than if scripting it isn't a graceful option any other questions okay thanks so much