 Good afternoon folks. Thanks for joining us at the coveted after lunch spot. I hope you're not feeling too sleepy. I would like to warn you that we do not have any code in our slides and we only have a couple of bullet points. So if you love bullet points, I'm sorry, we'll try to entertain you some other ways. Anyway, this is, if I only had a framework, crafting experiences across third-party systems, we are going to talk about the reality that we all face that we're not just building Drupal websites. We have to take into account that our clients are using all sorts of systems. So to craft a user experience, we have to consider those other systems and not just the websites that we're building. I am Brett Meyer. I am the director of strategy at ThinkShout and this is my co-presenter Lev, our CTO and one of the co-founders. ThinkShout is a digital agency. We do digital strategy work and Drupal development primarily for nonprofits. So to get this started, we're going to start where so many stories begin in the parking lot of a Safeway. When I was in college, I had a job at a movie theater as a projectionist, which is not nearly as cool as it sounds or as I thought it might be. So sometimes when I got off of work, I would go to the Safeway next door, mostly because it was convenient to get some beer. Anyway, one time I went there, chose my beer, got the six pack to the counter and the checkout person looked at me and said, are you drunk? And I said, no, I just got off of work. I'm trying to buy some beer. And she said, I'm sorry, sir, I can't sell you any alcohol if you're clearly intoxicated, which did not make me very happy. And the only thing that I can figure, because I've thought about this and the many, many years since this happened is that she noticed that I had come in with my girlfriend who was only 20 at the time and she was hanging around near the door and she thought that the best way to not sell me beer when I was going to provide it to a minor was to accuse me of being drunk. So I asked her to talk to her manager, the manager came over, they kind of huddled and whispered together and the manager said, I'm sorry, sir, once we accuse you of being intoxicated, we cannot sell you any alcohol. And this is one of the few times in my life when I have been like shakingly, furiously mad. So I yelled at them a little bit and then I walked out of Safeway and I didn't go back for 10 years. And not just this Safeway, but any Safeway. And there's research out there that shows you that the top reasons customers leave a brand, poor quality, and rude customer service. And you might just say, oh, Brett, you're just out of control. But there's surveys, 39% of respondents to as in-depth surveys show that they avoid vendors for two or more years after a bad experience. The lesson you can take from this is that I hold a grudge a lot longer than most people. But honestly, the reality is that one bad experience can negate dozens of good experiences because as human beings, we expect things to work out the way we expect them to work. This is true in commerce, this is true when you are going online and having experience with the website. If I go to Amazon because I want to buy a new album and I am unable to do that for some reasons of technology, I am not going to be happy with that and I'm probably going to take my music buying experience elsewhere. So you might be wondering what this has to do with you. So for the most part, I am guessing that most people in this room are building websites for your clients, for your organizations. But you have to take into account the wider space that their brand occupies. It's not just the website that's going to create a complete user experience. Not when they outsource things like their online stores, their marketing automation, things like that. Marketo and things like that, they're great at what they do. But if you have a rogue marketing associate who makes dozens of landing page with no relationship back to the brand and this website that you just built, you're running the risk of ruining the user experience that we're spending so much time crafting. So we can't just limit ourselves to thinking how people are gonna interact with the website. We owe it to the people that we're doing work for to think about the whole experience that people are having. So I am going to quickly run you through this website that I had absolutely nothing to do with building. And it's always a little dangerous to critique a website in public. I've done it before and if you have even the hint that you're saying something negative about a brand, they will track you down. I've gotten phone calls before, even though I never said anything bad. Anyway, it shows LiveStrong because they are a very good representation of what we're going to be talking about here today. And I have to say that for the most part, Lance Armstrong aside, I think they're doing a pretty good job. So they have a pretty good looking website. I mean, it's not responsive, but it looks pretty professional. They've worked on the information architecture and they've got a nice strong brand design here. It is built on, as far as I can tell, .NET. They also have a blog and this blog is running on WordPress. It's actually on a different sub-domain. So it's blog.Livestrong.org. They've got a store and the store is running on top of Yahoo stores, which I actually didn't even know was a thing until I was doing research for this presentation. But it is yet another system. This is at store.Livestrong.org. Then they've got this event system where they're encouraging people to sign up for their events. It's built using Django, so it's a custom application and it's running on top of Yahoo Store. Incidentally, if you haven't used Built With, it's a little website where you can plug in any URL and it will tell you all of the underlying technologies for a website, builtwith.com, pretty nifty. I recommend you check it out. And Livestrong is also a nonprofit, so they accept donations and this is yet another custom application built using Django. And then there are all the things that we don't see. We have to consider that they probably have an email marketing campaign. They're probably got some sort of social media presence. This is a nonprofit, so I can pretty much guarantee you they have a direct marketing campaign because as far as I know, the mail still works better than the internet for some reason. So every one of these is another engagement with a constituent and the constituent is not going to care if they have a bad experience with an email or a bad experience with the website. As soon as they have a bad experience with the brand, they're going to remember that. It's gonna stick better and it's gonna stick in the back of their minds a lot more than the consistently good experiences that they're expecting from the Livestrong brand. And you have to think about the site administrators too. They're going to be using data as much as possible to improve all of the user experience across the full variety of properties that they have in play. But if you've ever tried to track data across all of these systems like this, you probably know that it's a pain in the butt. So what's the solution to this problem? Well, the snarky answer and one that I'm sure that we would like to give everybody, why don't you just do all that in Drupal? We can do everything that I just showed you. You can use commerce. You can have blog functionality. All of this is pretty basic within the Drupal framework. But we're not always talking about being reasonable. In this space, in the space that ThinkShout works in, we have the particular issue, for example, of nonprofits using Convio or BlackBod as their fundraising platform. And if they've been using Convio or BlackBod for 10 years, we're not likely going to convince them to switch off of that platform just because we tell them that we can give them a better experience. They're going to have a certain amount of organizational investment in this third-party tool and we have to take that into account when we're building websites for them. So we have to accept the realities our clients or the organizations that we work for are working in and figure out how to solve the problems in front of us without being able to turn to what we might think is the best solution. So to do that, we need to have a good understanding of all of the technologies that are in play from the very beginning. Thank you very much, Brett. So I'm going to talk a little bit about developing a solution. So like any good project, before we start implementation, we have to go through a discovery phase and do some requirements gathering. Now when we're dealing with these types of projects, requirements gathering is also known as the hunt for secret spreadsheets and like all good discovery exercises, we know it has to involve lots and lots of sticky notes. So the first step in doing discovery around integrating these third-party tools is understanding what all the different data sources are. So the way we usually approach this is we get all the stakeholders in a room together and we hand everybody a stack of sticky notes and we say, all right, write down five or so of the data sources that you can think of where you guys keep all of your data. And you might want to kind of give folks some clues so say things like spreadsheets and email and inboxes and old systems and really kind of get people thinking about where all these different data repositories are because it may not be really a traditional databases that people think of. So then we group related or similar items together in balloons on the whiteboard and we then go ahead and now that we know where our data repositories are, we want to also understand what the sources of those data are. So we do a similar exercise where we then give everybody again a stack of sticky notes and they write down five or so of the data sources that they can think of where the data comes from. So examples here could be donations, event registrations. Email is perhaps not actually a valid answer in this case because we're not really concerned about the fact that you received an email but more, what does the email contain? What is the source of that email? Where does the data come from? So now we've got our data repositories and our data sources, but we're still missing a key piece of the puzzle which is how does data go from one place to another? So now we, on our whiteboard here, we've got our bubbles containing our data repositories and around them we have bubbles containing our data sources. So what we need to fill in there is how the data flows between these two systems and this really gets at the heart of how a lot of these organizations operate. So what we'll then do is we'll usually get three different colors of sticky notes. One to represent manual data flows. One to represent automated data flows. And one to represent constituent data flows. And what that means is when you have constituents filling out forms on your website most typically. So when somebody registers for an event, makes a donation, et cetera. So we'll go ahead and use arrows and labels and we'll put these sticky notes on that whiteboard in between the data sources and the data repositories. So we begin to have a complete picture of the data model for an organization and that picture might look something like this. So you can see here we've got a big complicated situation with lots of data repositories, lots of data sources and crisscrossing data flows that might resemble a Los Angeles freeway. And much like a Los Angeles freeway here we can have lots of bottlenecks and efficiencies and things to get stopped up in a hurry. So at this point in the process we want to step back, do some analysis and present a recommended solution that might look more like this. So you see here we have streamlined the number of data sources and repositories and the flow of data between those systems and then this becomes the starting point for us flushing out the solution for this particular project. All right, so now we've got all the pieces in place. We got the data repositories, we got the data sources, we know how data moves around, we got the whole thing diagrammed and designed. What do we do? How do all these random parts fit together into a gorgeous steampunk airship like this? And luckily for us, a lot of us here are technologists and there are technical solutions to help us kind of get through this challenge. So we're gonna kind of go through a few different, this would things get a little bit opinionated here in the sense that we think there's kind of good, better and best ways to begin to stitch these things together. For many cases, the best approach to start with are to use APIs to keep the entire integration hidden behind the curtain. And why is this a good approach? So number one, it leads to a seamless user experience. That's a dangerous buzzword to use but it's actually appropriate in this case. We want the user's experience with your website to be consistent, to have consistent branding, to have consistent messaging. And it doesn't matter, like Brett was saying earlier, if you're using a third party system for event registrations or donations, for example, all they know is they're visiting your website and interacting with your brand. So in this type of an example, when using these APIs, all of the integration happens on the server. So again, as far as the user's concerned, there is no integration taking place at all. And what this ends up giving you is maximum flexibility over the user experience. So here's an example that we often like to talk about. Let's say that you have an online donation form and Jane Doe last year, she donated $100 to your organization. So if you are using a third party system to accept these donations, that form is gonna look the same to Jane Doe every time she visits your website. But if you control that experience and have the ability to alter that form, depending on Jane Doe's past contributions to your organization, then you could, for example, start that ask at $150 rather than $50. So that's an example of the kind of powerful customization you can do and you've got full control over that user experience. So a couple of examples in the Drupal space that are near and dear to our heart that take this approach. One of them is the Salesforce integration. So there's a module called the Salesforce Suite, which allows you to synchronize any Drupal data with any Salesforce data. So this is a screenshot of the mapping form where you map these two objects together. And you can see here we've got a Drupal contact, first name, last name, email being synchronized with a Salesforce contact, first name, last name, email. So when somebody makes a donation or signs up for an event or even just registers for a profile on your site, that information is sent to Salesforce. The user has no idea it's happening, but your CRM administrators could then have access to that data and reach out and engage with those constituents as needed. Another example is the Drupal MailChimp integration. So full disclosure MailChimp is a client of ThinkShots. We've been working together for years now to manage and maintain the MailChimp Drupal integration. So the module has a lot of rich set of functionality, none of which is visible to the end user. At its core, what the module lets you do is manage the subscription of your MailChimp list with Drupal data. So here's a fun fact. This is a screenshot of my Drupal.org user profile. So for those don't know, Drupal.org recently started using the MailChimp module. And this is the user edit page. This has your email, first name, last name, and it has a list of the newsletters you wanna sign up for. And this is all part of that same experience of managing your profile. Nobody has any idea that this form is being, this data's gonna be sent to MailChimp behind the scenes to manage your subscription in those MailChimp lists. And it really creates a lot, you know, having this integrated into your profile creations, whether you're registering for a site or updating your profile, really increases the likelihood of users being engaged in interacting with this data. If you had a completely separate form on a separate part of the website where you manage those subscriptions, you would have a drop-off in terms of the people who are updating that data. All right, so not every situation will allow you to do these deep integrations with these third-party APIs. Perhaps the APIs are not available at all, or perhaps it's just going to be way too expensive to build out that custom integration. So another approach that can be really solid in many cases is to embed third-party widgets into your website. So these embeds usually take the form of JavaScript widgets or iframes or sometimes direct forms that post to a third party. A really good example of normalization taking advantage of this is CharityWaters. So this is CharityWaters' website. This is like the same, you know, Chrome and branding experience that you get on the rest of the website. But this form that we're looking at is actually coming from the Stripe payment processing platform. You never know it. It responds to different platforms just like the rest of the site does, and it's a really great, you know, when you go ahead and click the sign-up, you get this nice pop-up. From a user standpoint, there's no drop-off at all there in their experience of donating to the organization. Once again, though, not every situation will give you the option to do embeds. Some tools you're using may not have those types of tools available, and maybe they are available, but they don't work well. So for example, sometimes when you're doing embeds, you lose the ability to do really effective styling of those tools, especially when you're dealing with iframes. It also may be that those embedded widgets don't respond well to the different form factors of your website, and you don't have a lot of control over that. So it may be a good idea to simply send people off to that third-party tool to accomplish the task you need them to do. If you're gonna do that, the most important to keep in mind is really clear messaging. Don't try to fool your users. Don't try to pretend they're staying on your site. Be really clear about what's happening. So a good example of an organization that's doing this is actually the National Park Service. So they started an initiative where they want individuals to share compelling stories they had while visiting national parks, and they have a third-party tool that does this. You can see over there where that big rainbow park sign is there. You click on that to share your story. Well, what happens when you click on that button is you actually get this pop-up right here. And obviously this really clearly states, hey, you're about to leave the website. Thanks for visiting. Here's what's happening. Thank you. And that way there's no confusion about what's going on. So that's a really good approach. Finally, what we don't recommend is to fake it. So we've all probably been to websites that do this. You're browsing around, you click on a button to do something, and all of a sudden, boom. You had no idea what happened, but clearly something's wrong. Things don't look quite the same, but they're kind of trying to look the same. You look at the URL, it's a different URL. Maybe it's secure, maybe it's not insecure, maybe you've got some type of SSL certificate issue. The organization there really risks losing your trust and having a huge drop-off in terms of constituent engagement. All right. And then there are the human systems. Arguably the human systems are the much trickier ones to deal with than the actual technology solutions that you're going to be putting into place. But if you're not addressing the human elements, then you are probably not giving your clients everything that they need from you. A lot of this has to do with making compromises. So you understand now what the actual technical requirements are. You understand what the technical limitations are. Hopefully you've taken all of these technologies that are going to be at play. You've taken a look at their documentation and understand what it is that they're capable of doing in the first place. And that is going to help you figure out what you can actually do when you're trying to build this integrated experience that is not actually integrated into the website itself. It's always going to require some sort of compromise. So let's go back and take a look at Livestrong again and see what they're doing. They've got pretty standard navigation system and they are using a drop-down menu system. Say what you will about drop-downs as a user interface element. This is the way that they decided to go. I imagine that they have good reasons for this and they're paying attention to how well it's actually performing. When you go over to their blog, they have the same top-level navigation system and some of the same branding, but they have taken away the drop-downs in this case. It's moving from their .NET website to a WordPress blog. So if they were going to maintain the entire navigation system, the entire information architecture across those two different platforms, it would require them to manage navigation in two different places. And I imagine that some of you have done this before. Anybody had to manage a system where the navigation was set up in two different places? It is a pain in the rumpus, is it not? And it's easy to miss changes. So if you change the navigation on one site, you have to go to the other system and change it there. At larger companies, it's probably going to be somebody else who is responsible for making that change on the other system, so it requires coordination with other people as well. So Livestrong has made the determination that the easiest way to solve that problem is to just stick with the top-level navigation on their blog site and let people use the blog for what the blog is for, reading articles. So for the store, they've actually changed things significantly, and this makes perfect sense. People are using the website itself for one thing. They're probably looking for content, the content that Livestrong provides. When they go to the store and they're browsing through things that Livestrong is trying to sell them, like the little yellow bracelets, you don't want to distract them with opportunities to go back and read about whatever it is that Livestrong is trying to inform you about, which is generally cancer issues. But once you're in the store, you want to be in the process of browsing the products in the store. You don't want to go from, say, looking at that yellow tank top back to an article about how you're going to deal with cancer as somebody who has just discovered that you have it. You want to focus on the shopping experience. So the choice they have made is to craft this experience with the information architecture to focus on the functionality of the store. And you can see a similar thing on the donation page. Once you get somebody as a nonprofit into the donation channel, it is a pretty good idea to take away all of their opportunities or to make it more difficult to get out of the donation channel. You want, of course, that donation to come through. And if you're giving them all of these things, wait, do you know that we did this? This is a really good reason to donate to us. Once you get them on the donation page, they've already made an indication that they're probably going to donate to you. So strip away all of the elements that might distract them from completing that action. Now, it's entirely possible that Livestrong didn't do it for that reason. Maybe it is a technical limitation of what they were working with. But the key is to understand those technical limitations. So, as Lev was saying, you know the requirements. What is possible and then what is the user experience that you can craft across these various systems that you're doing without distracting people and really trying to get the best out of the technology that is available to you. By focusing on the capabilities and use cases of their various properties, Livestrong has compromised some of the elements of the user experience to focus on what's important for the given use case. And the more cynical person might draw a comparison to how Lance won the tour, but let's move past that. So again, and we really can't emphasize this enough, when we are doing this work as user experience designers and website developers and building the Drupal platforms for our organizations and our clients, we really need to understand all the systems at play so that we can make the right choices when we're designing the user experience itself. You can only design for what you understand. And design is going to play a big role in that. You saw in the Livestrong example that they maintained a certain amount of branding across all of those various technical platforms that they had. Design's always going to play a big role. And I will say that while Lev and I, I believe both of us have played the role of designer in the past, we would not get to work on the projects that we're working on now if that was still the case. So these are really going to be kind of high level recommendations that we're talking about here. We can get Josh up here afterwards if you have any specific design questions. So, I mentioned Josh. Hi, Josh. Josh is the user experience lead at ThinkShout and we've talked about design in the browser recently, which I think you've had something of a love-hate relationship with recently, probably because GitHub ate one of your projects. But design in the browser has become a very common way to design websites these days. Common criticism is that you can generally tell when a website is designed in the browser because when you're using pattern lab or patterns and such, it tends to create a certain design that is recognizable as such. It's not, it doesn't have a lot of niceties. It usually looks pretty blocky. It is pretty popular across the web at this point. But it does give you the opportunity where if you have to make a change to say the navigation system or something in the header, you don't have to go back to 20 Photoshop or Sketch files and make the change in those 20 places. You make it in one place when you're designing in the browser and it happens everywhere. And that's fantastic. But more importantly for what we're talking about today, if you're designing for a third-party system, say a donation platform, you understand what the technical requirements are. Designing that code in the browser itself is going to force you to stick to those technical requirements. You can't say just because Sketch or Photoshop makes it easier the whole, well, wouldn't it be nice if we could? No. If you know that you can't, don't do it. And focusing on the actual HTML, the CSS, that you are actually allowed to use with that third-party system is going to force you to stick with the design patterns that are actually going to make sense in the real world. I'd also note that when you are developing these design patterns in the browser, hopefully you're going to be doing it in such a way that the CSS, the JavaScript, the components that you're designing are going to be portable across platforms to a certain degree. So what we're doing a lot these days is component design. So we will do a couple of full-page comps, of course, or a couple of full pages in the browser because our clients demand it. They have to have some sense about what the website is going to look like. But we can't reasonably wireframe or prototype all of the pages and page types and systems that we are going to be building for our clients. So we have turned a little bit towards designing the components that are going to make up all of those pages. And when you have a good understanding of what the technical possibilities are across all of the systems that are going to be used by these digital ecosystems, then you can have a sense of which components are going to work on the website, which you can transfer over to the blog, what you might be able to use on the store, and really focus on what is going to be compatible to build the brand across the systems to make sure that you're maintaining a consistent visual voice across all of the pieces that are in play so that we can avoid, as Lev said, faking it. And in the end, you really want to make sure, if you're not doing it already, and I imagine that a lot of you are, that you are providing a style guide for your clients or for the organizations that you're working for that writes down or delineates what you have designed for them. So what's the typography? What are the heading styles actually going to be? The consistency across systems is only going to come from patterns that people can apply. And by defining everything that you have done to make this brand and this voice consistent across these systems is going to discourage them from freelancing and, say, highlighting some text in a WYSIWYG editor and making it bold and red when they should not, in fact, be doing that. Just the simple act of writing it down and having a style guide with clear examples is going to give them the guidance that they need to make sure that after you turn the keys over to them, they're going to stick with what it was that you designed. Which brings us to a biggie. And that is the idea of governance. A style guide is just part of a broader governance plan. Human systems are going to run amok and ruin your most carefully designed or carefully planned designs if they don't understand the intent you had in building them in the first place. There has to be a system. There has to be some sort of rules that tell people, and you can think of this just as the generic documentation about how to use all of these things that you are building for them. If people don't understand what it is that they're using, they're going to force it to do what they want. And that's often bad. Creating a governance plan involves establishing three things. You need to establish the roles and responsibilities. You need to establish the workflows that are going to be at play. And it's always helpful to come up with the evaluation and review standards that are going to help you and your clients and your organizations understand whether these things that you've built for them, these really fantastic things that you've spent all of this time thinking about and working on whether they're not actually meeting the needs of the organization and the end-users, and if not, how you're going to change that going forward. So roles and responsibilities. Unless you're working with a very, very small organization, you have to assume that different people are going to be responsible for different things. The LiveStrong blog, they're a pretty big organization, so I imagine that they have a couple of content creators, and they have an editor. Hopefully they have an editor. So the writers are going to have certain permissions. They're going to be able to create their blog posts. They're going to put it into the queue when they hit submit, and it's going to go to the editor who is going to review it, compare it to the editorial style guide and figure out what needs to be changed before it should go live on the web. All of these things involve kind of, it can be a really basic diagram, it can be an org chart with arrows pointing to who, but you have to come up with this for all of the systems that are at play. So who is going to have super admin rights on the Drupal site? Who's going to be able to control everything? Who is responsible if you make a change to the top level navigation on the main website? Who is responsible for making that change on the WordPress site? You need to have a sense of what happens in a timely way to keep the user experience as consistent as possible. This is kind of the idea of what cross functional teams are for. When you're building this governance model you need to know who is going to be involved with updating the website in all of its various capacities so that you can ask them to do their job essentially when it's time for that. And that's involved with the workflows too. You need to make sure that you have a system in place for that say you're creating a blog post. What is the review cycle? What are you going to do? Are you going to write this? Are you going to publish it? Is it going to be done in Google Docs first before it goes into the website? Are you, heaven forbid, going to actually write your post in the WYSIWYG editor? Don't let people do that please. Or are you and who's going to publish it when you get to it? Are you going to bog people down with picky and rules and rules that don't have a reason? But good workflows always have a purpose. It's going to make it streamlined. It's going to make it easier for people to understand what it is that they actually have to do when they perform a task. I'm sure you're going to have some creative people working on the website. But it's always helpful for them when they don't have to learn what it is each time that they are responsible for doing. If they have a clear understanding of what's going on within them and it's going to lead to a more consistent user experience in the end. It's also part of the formalization of any organization. You think it'd be nice if everybody is going to stay at your company or at your client's company forever, but the truth is that people come and go. And when you have this written system of delineating how everything works and who's responsible for what, if somebody leaves, it's a clear place to go to learn what it is that they actually have to do to succeed at their jobs. It's just part of formalizing any organization. And of course it helps to review how things are working. We're all just making our best judgments as user experience designers as to what that user experience should be. Especially when we start thinking about all of this more holistically. Not just the website, but all of the systems that play. But once these systems are in place, you need to have a way to go back and check how these judgments are playing out in real life. By establishing these metrics and goals before anything is actually launched, you're creating a plan and a system in advance for understanding how to make improvements going forward. This is not a launch it and forget about it experience. It makes it easier on us as developers if we turn the keys over to the client and then never deal with them again. But a website is a living thing and a digital ecosystem is a living thing. And as their needs change they have to have a way to understand what's working and what's not and how they can make it better. So what I'm saying basically is you need to write shit down. Don't let make people, don't allow people to make assumptions about how something might work. That's how sites and user experiences get ruined. If you make the processes clear and highlight the underlying assumptions that we're making, you give them a plan to make it to improve going forward. And I've had some variation on this slide in most of the presentations that I've done over the past year. And I've actually gotten some follow-up from some pretty big nonprofit organizations that have told me, you know, we went and we took your advice and we wrote down this plan and things are somehow working better now. So don't assume that people are going to understand this to begin with. It's part of our job as designers, as developers, as user experience engineers to help people understand the best way to do things. And if you're not writing stuff down you're running the risk that they're going to forget how to do it. I've seen several sites recently, like sites that we are in the process of redesigning where I can see the information architecture in place is much more robust than the client actually ended up using probably because people left and forgot what the functionality was actually for. They didn't have documentation on what this entity reference field was for, so why should they use it? They'll just throw it in the WYSIWYG. By establishing these documentations we can help make sure that the site's going to serve them well for a long time. Because really, is there anything that's more annoying than handing over the keys to a shiny new suite of online tools and then watching in horror as they slowly crumble over time? I'm sure it's not just an in-joke-at-think-shout where we sometimes struggle with we know that we're going to turn this over and if they do something wrong if you have three call-to-action blocks and somebody decides that they want four sentences on one and only one on the other it's going to totally unbalance the page and there are easy ways to prevent fat from happening. Mostly, writing it down. So, by writing it down you're helping your clients and yourself make the most out of what is probably a pretty expensive investment. And we're talking about people. So, you have to understand that when you are creating these new websites, when you're creating these applications and you're turning it over to them you are creating, essentially, revolutionary change in their lives. If they've spent their five years at this organization say, using throw at, what's a really terrible website platform? Don't say WordPress. SharePoint. Somebody has spent five years using SharePoint and suddenly they're going to be using Drupal it is going to change the way that they do their work. Like, fundamentally change the way they do their work. They have to understand these new systems and how they work. So, when we are launching websites when we are building these applications and turning it over to them we have to have this recognition that we are really changing their lives to a very large degree. Not just the end users who are going to be using these products but the people at these companies who are using it just as the way that they're making their livelihood and trying to change the world in the case of the people that we work with. So, new systems force people to do things in new ways and it's often scary. It's a scary thing to have to learn new things for the most part. And that can lead them to resist all of this change that you think is going to help them do better work. It can help them understand that changes are going to be for the best. And I would also remind you that you're smart. Everybody in this room is a smart person. But that doesn't mean you're always right. So, part of the change management has to be working with your clients to understand what it is that they are after and really being willing to change our assumptions about the work too. And a lot of this comes down to people's habits. Humans are creatures of habits. There are books, shelves of books at the bookstore that you can read to learn about what habits are. I think there's a session after this one that is going to talk about behavioral psychology and how that can play into the user experience. People build up these habits. You wake up in the morning, you have your breakfast, you go to work, you sit down, maybe you check your email for 10 minutes. When you start to develop these habits, they become ingrained in the way that you are interacting with the systems that you're building. And when you introduce this revolutionary change into their lives, this new system that they have to learn, it is going to force them to change their habits, which is going to make them grumpy. But if you've done a good job, if you've really mapped out the requirements, if you've written down all of the ways that they're going to be working on this and really giving them a clear understanding, you're going to help them develop new habits and the habits that are going to help them use these new systems to the best of their ability and hopefully going forward, making sure that they can go back and improve them over time. I don't think I need to say anything about that slide. Nothing so needs reforming as other people's habits. We all have them. When we are forcing people, essentially, to change their habits, we owe it to them to make sure that we're doing the best job that we can. And finally, I would say that when you meet this resistance, in my experience, you often meet some sort of resistance when you're introducing this. I love Drupal. The back end is somewhat challenging sometimes, particularly for people who have never used Drupal before. So you need to get it across to them that this new way of working is actually going to improve their lives and a good way to do that is with data. Hopefully you have spent all of this time building those measurements and the KPIs and the ways that they're going to be able to judge whether or not things are successful. If you can quantitatively show that these qualitative changes that you've made to their lives are making a difference in the work that they're doing, they will usually, humans are reasonable, rational people except when they're being emotional, you're going to get past that by showing them, well, we said that this was going to do this and I can show you that it has led to a 30% increase in this. It's good, it's working better. If it shows that things are doing worse, well, then you have to roll with the punches and do what you can to help them improve the experience. Anyway, that's what we got for you, we got through it in 45 minutes so we have plenty of time for questions and we are certainly happy to entertain those now. Thanks for coming in and question and answer is always my favorite part so let us have it. I have a question. Excellent. When I do this work with clients, I generally co-write it with them. They are going to understand their needs even the most robust requirements gathering process is not going to make us absolute experts in what they do so I usually do it in Google Docs. I encourage everybody to use Google Docs and really make these living documents. Once you get to a finalized piece like a style guide that is really going to codify what they should be doing on a regular basis then it makes sense to turn it into a PDF but while you are actually developing the documentation I want to get as much input from their staff as I possibly can. Yes. Excellent. For the recording that was a question about budgets and clients just wanting something to be good enough and the kind of sense that this is a lot of additional work potentially so if it is out of budget how are you going to help your clients get to that point? Excellent question. Our clients are nonprofits so we meet the budget challenge and it is just a matter of fitting in as much as possible and working with them to develop this because they don't have a lot of money but they do have the staff and they do have the time and for our budget challenge clients I present them with these concepts and I explain what it is to accomplish and while it is not necessarily in budget for us to write down all of this we try to give them the tools that they can use themselves to get to a good place. We always provide training and documentation in the end it is always part of our budgets but for the governance plan for making sure that you have branding that is going to work on this third party system we just make sure they understand and then it is just a matter of using collaborative tools like Google Docs to encourage them to develop these themselves and just give feedback and guidance where we can without really eating into the budget very much. One thing to that statement I think we can also especially in that discovery phase help steer folks towards value conscious decisions maybe their dream solution requires deep API integration but they can get 80-90% of what they need simply by linking off to a third party tool so it could be that we want to reserve budget for the things that a third party tool can accomplish and following some of the best practices that we talked about using those third party tools can still be a really effective solution so we can kind of carve out value engineering choices in that way. There is a microphone in the middle if you want the recording There must be more questions out there. Okay. If there are no more questions thank you, we release you into the cavernous hallways of the Los Angeles Convention Center to maybe grab some coffee and then head on to your next session. Alright, thanks everybody. And Lev and I will be up here if you just didn't want to posit your question in front of folks. I will note that we are hiring a UX designer right now so if you would like to live in lovely Portland, Oregon and work with us with great people doing really good things feel free to come talk to us.