Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, it is not physically possible for us to be more excited to be speaking with Toby Greenwalt and Matt Griffin, who are going to be telling us a little bit about the Carnegie Library of Pittsburgh. Toby, Matt, thank you so much for joining us.

Toby:

Thank you, excited to be here.

Matt:

Thanks Ethan, thanks Karen.

Karen:

But before we get started, I’d like to say a few words about our sponsor, Media Temple. If you’re a web designer or developer, you need solid hosting with great customer support. Media Temple focuses on the needs of the design community, and is constantly improving their products to make hosting simple for you. That’s why they have one of the highest customer loyalty rates in the industry, with the average customer sticking around for years. If you’re looking for WordPress hosting, shared hosting, virtual private server hosting, or just want something better than a crappy $5 a month hosting plan, you want Media Temple. Go to mediatemple.net and learn about their hosting services and award winning support team. Use code RESPONSIVE to save 33% off the first three months of shared or Wordpress hosting.

Ethan:

Before we actually dive into the CLP website a little bit, maybe you both could just introduce yourselves and tell us a little bit about the library and the new website, tell us a little bit about what you do for it. Toby, why don’t you go first?

Toby:

Absolutely. So, I’m the director of digital strategy and technology integration at Carnegie Library of Pittsburgh, and this is a relatively new position that the library created about two years ago as a product of its most recent strategic plan. The library was in pretty severe financial straits back in 2009, and as a result, they pushed for a referendum from the city to provide for additional local funding. And when that referendum passed with over seventy-two percent of the vote, they realized that they had a clear mandate to bring about some transformative change to the organization, and part of that was looking at the library’s role within the virtual environment. There’s a lot of tech changes happening in Pittsburgh and they wanted to make sure that the library had a place within this whole ecosystem. So they brought me in and part of this process was to make sure that the website followed suit.

Ethan:

Nice. And Matt, how about you?

Matt:

I’m Matt Griffin, the founder of Bearded, which is a web consultancy, and we’ve been working with the library for about six months to work on the redesign of this website and make sure things go swimmingly.

Even though it was sort of implicit that we were going to go responsive with our redesign, we had done some other background research before we even put out an RFP to help us flesh out that case.

Ethan:

Well, swimmingly it seems to be going. I’d love to hear a little bit more about the original decision to go responsive. When you were first talking about this redesign, were there any questions that came up around the approach? Were any stakeholders asking any hard questions about responsive design as a methodology?

Toby:

I had been gearing up for a battle when I started writing the first proposals for this website redesign, and it turns out that there was no need. We had realized that just looking around the building of how people used the library, both the website and the library itself, that it was very platform agnostic. We see people coming in using the building, and they’ll bring in their laptops but they’ll also have a tablet or a phone or any combination of those devices. And we knew already that our previous website had no responsive qualities and became increasingly difficult to use as you shrunk the site down. We had done some work with a mobile app that provides some limited functionality, but even that created more work to maintain and was very limited in what it offered. So, going responsive really lined up with some of the goals of the strategic plan that I mentioned. We needed to really meet our users where they were and speak to them on their own terms using the language that they use, using the devices that they use, and so on.

Matt:

And in my experience, Ethan, when this project came to our attention, it was actually through an open RFP, which is not something we usually respond to. But Patrick here at Bearded, his wife is in the museum and library space and brought it to his attention. And we love this library, I’ve been going to this library since I was a kid, so we really wanted to work with them. But rather than responding to the RFP in a standard fashion, we thought it would be better to just be personal and give them a call and see if they were in the same space as we were. So I called Toby, who I’d never met before, and explained who we are and what we do and we just had a conversation. And it became clear pretty quickly that we didn’t need to sell Toby on anything, that he was on the same page as us, he reads the same books as us, he listens to the same podcasts and reads the same articles, and we were just sort of kindred spirits about how one goes about the web at this point, which for us has been a responsive approach ever since I read your book. So, that seemed like a thing worth pursuing at that point. So we bid on the project—actually just a short research phase rather than the whole project initially, just so we could get to know each other—and then it worked out from there.

Toby:

We had some evidence to sort of support that, and even though it was sort of implicit that we were going to go responsive with our redesign, we had done some other background research before we even put out an RFP to help us flesh out that case. We had created some personas for our users, we’d mapped out some core tasks as to what we wanted people to get out of the website. Of course as a library, we’re a source of thousands of different types of information, and so we needed to be able to boil that down into what sort of actions we wanted our users to actually be able to follow through on. And then we performed a content audit. Our previous website sort of came as a byproduct of the age when librarians thought they were going to adorably index the internet, and we quickly realized that that’s not something that’s sustainable. So, we brought this research to the table in our conversations with Matt and his team and used that to further the implementation process.

We had looked at that through the way people use our mobile app, and we knew that there was a need to have some really quick calls to action, or some really quick follow-through on the tasks that people wanted.

Karen:

I’d be interested to hear how you conceive of the needs of a mobile user and how that might be different from what someone needs on the desktop. Sometimes we’ll talk to organizations that have a particularly in-person or local context to the interactions and that indicates to people that mobile should be something different, and maybe that’s something that’s handled through an app or maybe that’s something that gets handled through the mobile web. Can you talk about how you discuss the needs of mobile and desktop, and do you think they’re different?

Toby:

I think they’re different in some ways and there’s definitely different expectations that come with people approaching our website through a mobile device. We had looked at that through the way people use our mobile app, which again, provides some limited functionality—access to our catalog and materials, directions and hours and contact numbers, some other connections to e-books and other materials—and we knew that there was a need to have some really quick calls to action, or some really quick follow-through on the tasks that people wanted. And so we took that experience of how people use the mobile app and contrasted it with the list of core tasks that we provided and we found some definite overlaps, things like people wanting to find how to call the branch that they were looking for, how to see if their books were available, how to donate if they need to give something to the library. We wanted to make sure that those were front and center at all of the breakpoints that we’d mapped out on the website and then quickly reinforce that through user testing and other gut checks on the design process.

The challenge for us wasn’t acquiring data, it was actually parsing the data and synthesizing that data into something that was usable and actionable so we could figure out what the website really needed.

Karen:

I’m always interested when I talk to people who are working with an outside firm: How did you plan this project? How did you scope what needed to be done, how did you identify what you were going to roll out first if it was a phased rollout. Matt, maybe you want to address how you scoped a project of this magnitude.

Matt:

Oh, sure. Yeah, they’re always scary, the big ones, right? And I think acknowledging that truth was a really important part of the scoping process. When we went in and talked to them initially, there was that big RFP that said, “Scope this big project,” and one of the first things I said to Toby was, “I have no idea how to scope this project. We need to spend more time really digging into it and understanding it before we can even begin to sketch that out.” And I think that resonated with Toby as it would with most sane people, like, “He can’t imagine scoping the project yet, so why should I?”

So we did I think a four-week research phase, something like that, where luckily the library—this is interesting, but when you go to work with librarians, you are going to work with people that are very comfortable gathering and assembling a large amount of information, and they had done that, they had done a lot of research. They’d actually built a microsite, and maybe I’m misusing this term based on the amount of content that was on this microsite, but they had just reams and reams and reams of data and information and personas and everything. So, the challenge for us wasn’t acquiring data, it was actually parsing the data and synthesizing that data into something that was usable and actionable so we could figure out what the website really needed. So we did that research phase, we did a big kickoff with all their internal stakeholders to make sure that they were heard and that we understood what they needed, and we actually came up with a set of priorities that was based around users from that initial engagement.

We got a really strong correlation across all demographics about what people want out of the library’s website and what they want out of the library and where those things don’t meet up.

But then there was another layer that we did that I think was very useful. We got the library’s sense of what is important to users and then we decided to fact-check that against actual users. So luckily we’re here in Pittsburgh, there are a bunch of library branches filled with library users all day long, so we set up a couple of sessions of intercept interviews at two different libraries in very different parts of the city, and we talked to I think around thirty users in total and asked them a few simple questions about what they value at the library, what they do at the physical library, do they use the library’s website, what do they use the library’s website for, what’s valuable to them. And we got a really strong correlation across all demographics about what people want out of the library’s website and what they want out of the library and where those things don’t meet up.

What we tended to find was that the mission of the library’s users was much more narrow for the website than it was for the library as a whole—and, in fact, more narrow than many of the library’s stakeholders were thinking. So we got everybody that information and we managed to get the whole group rallied around this concept of just a few core actions that were really important, and then that helped inform the scope of what content was going to come over, what kind of content types we needed to model through the CMS, how many templates we would need to create. And everything really just sort of spun out from there, these core important user actions and then as well some more niche services the library provided that were still important for a smaller number of users that really needed to be represented as well.

When we actually scoped it though, we still kept that sense of vagueness that I think is necessary for something of this size. We were really clear that we couldn’t define everything right upfront, we would sketch it out as best we could from the beginning and we would accept that there were a lot of unknowns and put in a lot of wiggle room for when things did in fact change, which we knew they would.

We divided up the scope into basically groups, I think it was three major groups of deliverables. We had group A, group B, group C, and they would each have different kinds of pages or content types or templates or whatever, and then we would iterate through this process over and over again where we would say, “Alright, we’re going to work out content models and IA and workflows for group A, and then we’re going to set those aside for a bit and we’re going to move on to group B and do the same thing,” and during those down periods, they could shop that out to internal stakeholders and then come back to the next group. But because we left those fairly open-ended, and the same thing with feature development, we knew what the big high-level features were, but we didn’t know all the little eventualities with, say, third-party APIs that we’d have to integrate that were going to come up with later, we kind of guessed at the scope but we agreed that some would be harder, some would be easier and we’d sort of push and pull the schedule as we went and just meet every single week throughout the project to reassess where we were at and how we were going to change before moving on.

By focusing on making those content types as strong as possible from the beginning, we were able to then go deeper with some of these more specialized subjects.

Toby:

Yeah, I think the more we worked on that, the more we were able to find that those content types we created kept feeding back onto themselves. We were able to further flesh them out not just for the site itself but for the services that we were designing around them. Matt talked about wanting to represent a few core services, but at the same time we wanted to represent the depth and breadth of all the materials that we had. So, by focusing on making those content types as strong as possible from the beginning, we were able to then go deeper with some of these more specialized subjects. Things like our Pennsylvania history department or our music, film, and audio department, using those templates provide a strong foundation from which we can then go deeper. And of course the ultimate failsafe there was to connect people with staff so that once people got the resources that they needed, they could then connect with a staff member for more of an in-depth consultation and the kind of service that we’re trying to provide.

Matt:

I’m going to jump in briefly there on the end because I think one of the important things to acknowledge about this approach to scope where we’re a little more open-ended on what we were doing, we knew how many weeks we would be working but we didn’t know exactly what we were going to be doing every week until we got pretty close to it, was establishing a lot of trust between the library as an organization, all the people in the library, and then everyone at Bearded as well. I think that research phase really sets you up to do that. Those four weeks working together where we learned about each other, we understood each other’s values, everyone felt they were being heard and listened to at every level of the stakeholder process. By the end of that, they felt like they could say, “Okay, we trust Bearded enough to know that though we don’t know exactly what they’re going to do, that they’ll have our best interest in mind throughout the process.”

Toby:

Yeah, no disagreement here. And being able to point back to that research was essential because, again, a lot of these elements didn’t quite come together until we got closer to the end since we were working on individual pieces at a time. But once they did, we could then point back to the initial goals that we created and say, “This is what that meant” and remember you had a lot of say in making that happen.

Ben Callahan likes to say that there’s one deliverable that they work with and it’s the website, and I think we approach things in a similar way.

Ethan:

Talking a little bit about the end of this research phase, it might be a good time to bring up the design process. Matt, tell me a little bit about how this was actually structured with the library. What kind of deliverables was Bearded planning to show them at different points? If you could paint a picture of how the design phase was actually structured, that’d be really helpful.

Matt:

Absolutely. A good friend of mine, Ben Callahan, likes to say that there’s one deliverable that they work with and it’s the website, and I think we approach things in a similar way. We’re looking at increasing levels of fidelity of the same fundamental deliverable throughout the entire process.

So I mentioned we broke things up into groups. That’s just to make it digestible for us so we don’t have to be designing all the things all the time, but also to give a chance for the organization to review and give us feedback without stopping us from working, because we want to work continuously throughout the engagement. Each one of those groups, though, goes through a very similar process. It starts with the lowest possible fidelity, which is just words; we describe what the content is going to look like. So let’s say, for instance, a library branch is one of the things that we’re looking at, right? A library branch has certain elements which translates eventually to fields in a CMS. So, there’s the name of the branch, there’s the address of the branch, there are the hours that they’re open, there are its accessibility options, there are its parking options, there are the bus routes that lead to it, there’s a description of that branch and sort of a history about that branch, things like that. So we describe that first, then we describe how all of those different content types will be defined. So for instance, there are locations, there are events that can happen at that location, there are staff that work at that location, there are staff that can create staff picks of books, there are the books, there are all these different pieces and how they relate to each other, right? And then we construct different workflows that a user might go through interacting with that content. So that’s all very low fidelity stuff, we’re talking about words and line drawings.

The next thing we want to do is say, okay, how does that information manifest itself in a browser to a user? And the quickest way to get at that, we found, is just with paper and markers. So we do sketches that are very low fidelity and very ugly that first start to suggest what is the information hierarchy on a page of these bits of content, how do they manifest on different views? So you might have a detailed view of a location, but then you probably have a list view of a location where you have brief versions that only show some of the fields in the content type, right? So we have to define all of those things, and we do it all on paper, and with all of these things, no matter how ugly it is, whether it’s a list of words, if it’s a sketch on a piece of paper, we’re talking with the library and their team every single week. So there’s a core team that we met with I think every Wednesday and then we would share new deliverables every Friday. So basically we’d share on Friday, we’d actually have a call on Monday to review what we had shared with them, just walk through it, but they’re not giving us feedback, we’re just making sure we all understand each other. And then Wednesday they’d come into our office and would sit down for half a day and we’d go over what has been done and what we’re working on that week, and we’d have sort of a progress update, they’d give us feedback, we’d talk about ways we might fix things or adjust, and then they go home for the day and we spend the rest of the week finishing things up for the next Friday deliverable.

Once we get through sketching, the next thing we did is let’s get this in a browser now that we’ve all agreed that the layout of things is in a good shape. Then we just take those words from the content types, put HTML around them, and we have a starter kit that’s basically a static site builder, it’s a middleman site, where we can spin out wireframe-looking sites very, very quickly. So we have base-level wireframe styling that sort of takes care of most of our styling needs. So we quickly get into an ugly wireframe-looking prototype in the browser. Now, that’s something that a library can view, but we can also run usability testing on, which, of course, we did. So we had people try to perform all the core tasks of the website by clicking through this ugly version of the website. Then we take all the feedback that we got from that, things that are working, things that are not working, we make assumptions about what would improve the things that aren’t working and then we test them out by rolling those revisions into the next deliverable, which is a high fidelity design.

Now, I’ve skipped one thing in there, which is that while we’re doing the wireframe-level prototyping, we’re also creating these things called element collages, which is a term that Dan Mall coined that’s sort of like a more involved style tile, which is Samantha Warren’s term. So we have bits and pieces of a website to get look and feel, no information hierarchy, doesn’t look like a website, nobody’s telling us to move the logo to a different spot and make it bigger because it’s clearly not a website. And we used that with the organization to check, look, and feel. Have we translated your very established brand well to the web? Are we using good conventions that make sense? Does this feel like you? If not, how does it not feel like you, and how do we adjust it back to somewhere else before we invest a whole lot of hours applying it to a website?

Once the prototypes are in a good shape, element collage is in good shape, those start to merge together and we start to get more detailed with the look and feel. How do we apply the suggestions of the element collage to a real, refined website? And for us, that was a combination of styling directly in the browser and also just doing rough Photoshop comps, where we’re not worried about the details and the tweaking, we just want to get enough down quickly that we can then translate into the browser. And that’s really a designer’s discretion here. Sometimes—all of our designers code, so coding directly in the browser is the quickest way for us to get our ideas out into the world and end up with real code at the same time. Other times, we feel more comfortable just dragging things around Photoshop until it feels right and then switching back to the browser. So, there’s a lot of bouncing back and forth.

And from there on out, it’s really just refining that code in the browser to the final website. At some point we translated it over to WordPress and, instead of working on a middleman site, we’d move it all to CSS and markup over into WordPress templates, and now we’re working in WordPress. But it’s basically the same thing except now we have a CMS that we can throw real content in there a little easier and we’re also working towards the production site, and we just keep refining that all the way ‘til the end until we’re ready to run QA, do browser testing, and go live.

Moving to a CMS allowed us to really take some more strategic planning over how the content came into the overall workflow and then how we distributed it throughout multiple spaces on the site.

Toby:

Watching those pieces fall into place really helped us kind of help to develop the content workflows that we needed. Our content creation process was very sort of one-dimensional. People would come in, they’d have a request for a page, they’d type it out on a Word document, they’d submit it to our web person via a form, they would go code it into a static HTML page on our old ColdFusion site, and then the thing would appear. So there wasn’t a lot of planning over how this monstrosity turned into what it was. It grew very haphazardly based on whatever the requester wanted it to see.

Moving to a CMS allowed us to really take some more strategic planning over how the content came into the overall workflow and then how we distributed it throughout multiple spaces on the site. Before we even started designing content, we really worked on a robust taxonomy of categories based on the locations, based on materials types, based on research topics, and based on a few other themes that we had that we were trying to push through the website. And now that we have those in place, it’s become much easier for people to create new content and then feed it into multiple spaces throughout the site. It might show up on a blog feed, it might show up on a specific library branch page, it might show up within a scoped research subject page that also includes the subscription databases that the library provides. But being able to put all those materials together and provide the right content at the right time really—thinking through this modular style and through these workflows really helped us to rethink this entire online service model.

Karen:

Well, that is music to my ears. I’d like to maybe follow up on that and ask broadly, how did you share work in progress with the rest of the organization and even among the design team? So, were you looking at mock-ups or prototypes, or were you in the CMS itself? How did you share this with everyone else?

Toby:

We were working off of mock-ups for a fairly decent amount of time. And at the library we use Slack a lot for internal communication, and any time we received new prototypes or wireframes from Matt and the rest of the Bearded team, I’d make sure to put that out there and share it with the rest of the leadership team. We also have the smaller web working group we called it, these were the people who participated in the kickoff space. We made sure that they got to see relevant parts of the site as they came through. We also had a number of gutcheck meetings with that web working team several times throughout the process where we brought everybody to the Bearded offices and they would meet with them in person and provide feedback on how the designs all fit together, because sometimes just seeing one element to the site didn’t quite work until you saw it in context.

Matt:

I think something that worked very well for us was basically having—you can imagine sort of two frequencies of check-ins. So we had the immediate, what we called the web team, which was Toby and two of the other folks in his group that were directly working on the site. So we had somebody that was really focused on systems administration and then someone who’s actually a WordPress developer that was going to be extending our work and helping us build out features throughout the process. We would talk with them all the time, so we were all in a Slack channel together, we were all in Basecamp together, and we were meeting in person once a week. That’s not really desirable or efficient to do with everyone in an organization of this size when you’re talking about potentially dozens of stakeholders.

So, we identified a few other groups. We had the web working group, which was multiple representatives from different departments, so someone from, say, the music department, someone from kids and teens… Different groups from throughout the website needed to be represented; someone from accessibility. And we would meet with them periodically throughout the process, so maybe once every two months we would basically push out to them, “Here’s where we are,” and we might do that through an in-person presentation or just sharing out on Basecamp or Toby would share it out over email and make sure that everyone was on the same page, they knew what was happening, and they had a chance to give input. But they really didn’t have the time or headspace or inclination to do that every week.

Then we also had executive leadership that we’d do a similar thing with, and we’d go through cycles with them where we would show up for a board meeting or a directors meeting and present where things were at at that point, get their feedback. We’d ask some very pointed questions. I remember at one point in the process, we were getting close to the end and we could feel people getting kind of nervous, like, “Is this going to be okay?” We added two questions at the end: one, “What are your biggest hopes for what’s going to go right in the next month?” and two, “What’s your biggest fear for what’s going to go wrong in the next month?” And then we didn’t talk about it after that, we just had them write it down on note cards, we brought it back, we looked at all the trends, and then we were able to address that with them again and say, “Great, here’s what on the whole you guys were worried about and here’s how we’re going to address that.” So, that’s sort of how we dealt with it at the executive level.

There’s another group which is the library users, and those had to be checked in with, too. So, we’d use usability testing, intercept interviews throughout the process, again every few months for them, to make sure that we were still in line with the user’s desires and we were still making things that they found useful and usable.

Ethan:

I’d love to know if performance was a consideration at all with the redesign of the library’s website. And if it did come up, how was it defined, how did you evaluate it? Tell me a little bit about that.

Toby:

Well, Matt mentioned that we have a systems person on our team, and of course it goes without saying that this project wouldn’t be what it is without the contributions of the other members of this web team. There’s both Dominic, our IT manager, and Matt, who’s our WordPress developer, along with our content folks, Carly, who oversees our content strategy, and then Molly, who oversees communications and creative services. For all of us, making sure the site ran quickly and smoothly was really key. And configuring things, making sure the caching was set up the right way, making sure our servers talked to one another the right way, making sure things were set up across the network the right way was essential. And then making sure that as much of the dynamic content that we had happened within WordPress as opposed to calling from external sources, which is what happened with a lot of our previous website, that went a long way towards making sure that it moved as quickly as it could.

Matt:

In fact this was something that we talked about at the very beginning of the project. So, we set up big checkpoints. We had our weekly reviews, which became a pattern and would evolve throughout the process, whether you’re talking about UX or whether we were building WordPress features. But we had three big checkpoints that were a two-week thing. So, the first week of the checkpoint we would have our progress review, which was meant for everybody to sort of stop what they’re doing, lift their heads up from the computer and say, “How is this project going? What are the big capital letter things that we’re worried about or that we’re excited about? Let’s make sure that we’re all on the same page and nothing big is getting missed.”

And then the next week was the performance review, where we were specifically sitting down to talk about performance. What are we concerned about at this point in the process? If we’re in the design segment, what are we worried about the designs with regards to performance? Are we using too many images on the page? Are we worried about too many requests? Are we worried about putting too much of a load on the API of some service and making too many requests through that and we’re going to have a slow response with that? Whatever our concerns were there, this would also happen during development and we’d start talking about that. And then by the end of the project, really it was off to Dominic worrying about things like server performance and caching and load balancing, or Gabe worrying about caching and WordPress. So really, I think performance does play a role from the very beginning to the very end of the process. And certainly with visual design, that’s something we had in mind. How do we render things in a way that is as performant as possible? And then all the way through the process for different elements.

The one thing that I want people to understand is the idea that the library and the library website is something that gets better with use.

Karen:

Let me ask broadly, how do you know if this redesign is working for you? How do you measure success or evaluate different aspects of the responsive design?

Toby:

So, we’re in a position where we’re just launching the site, and one of the rules that I’ve sort of put forth to everyone in the organization—because this is a pretty dramatic change for just about everybody—but the one thing that I want people to understand is the idea that the library and the library website is something that gets better with use. This is a concept that was put forth by Aaron Schmidt, who’s a guy that writes a lot about user experience and libraries. And the whole point of the way that we’re realigning our service model is really built around responsive in-person service. How do we recognize what are the changes happening in the city? How are people’s information needs evolving as they have a lifetime relationship with the library as an organization? And how does staff change its own behavior in order to meet those needs? We wanted to apply that same principle to the website.

So as we develop, I think our real goal is that as the site becomes more and more used, we identify more opportunities to create these sort of customized experiences for the other types of users that we have. We’re actually going to be doing this in a fairly extensive manner with our music, film, and audio department. How do we create the right spaces that meet some of their really specific audiences, the people working with film scores or the other folks who want to come in and connect with the various performance groups in the city. So, we’re going to have a very similar design process that we went through with the whole website with some of these departments, and I think the more of those that we have, the more successful the site is going to be.

Matt:

I would add too, to Toby’s point, what we’re looking for really is users doing the things and accomplishing the tasks that they want to do, and that’s what’s going to make the library happy. And when we really sat down with users, there were things that will not be surprising to you. Users wanted to find books and check them out that they were interested in. Users wanted to know, “Where is my library? What’s the location of it and what are the hours? Is it open right now? How can I get to my library?” And we found, particularly if they have kids, they’re interested in going to events that the library’s putting on. Those are the core tasks that sort of appeal to everyone.

As Toby’s describing, there are also these ancillary tasks that happen for a lot of smaller groups of people. For instance, if someone’s a researcher, maybe they’re working on their PhD and need to do a lot of serious research, there aren’t a lot of those people, but they really need to do those tasks. So, helping them to do that was certainly one of the biggest goals. I think one of the interesting ways that came out of the research that we were doing is simply making sure that the language that real people use is aligned with the language on the website. So an example would be, for researchers, that previously the library would talk about databases and getting database access, and what we found was, not surprisingly, nobody knows what a database is and thinks that that relates to them in any significant way. [laughs] What we found is people talked about research. “I want to do research.” So we just reoriented that language; instead of having a navigation item called databases, we have a navigation item called research. I think those kinds of changes should result in higher engagement, and if they do, then we know we’ve been successful.

The success of the entire thing really hinges on the communication between the people on the side of the organization that’s hiring you and the people that are doing the work.

Ethan:

Matt, Toby, it’s been wonderful speaking with you for the last half hour or so. But before we let you go, I have to ask, if there’s anyone in our audience who’s either just about to start a responsive redesign or are early on in the project, what advice do you have for them? What’s a thing or two that you’ve learned over the course of the library’s redesign that you think would be valuable to share? Matt, do you want to go first?

Matt:

For me, one of the most important things to keep in mind when you’re starting especially a large-scale responsive project like this is that the success of the entire thing really hinges on the communication between the group of people on the side of the organization that’s hiring you and the group of people that is part of your organization—in this case, the folks at Bearded—that are doing the work. We needed to have a clear understanding of each other’s goals; we needed to have a lot of empathy for each other and what we were trying to accomplish and what would sort of satisfy our organization’s goals and their organizations goals, and make sure we were aligning those as much as possible. That helps you sort of prevent things from going badly as much as you can, just talking and being open and being sensitive to the other people.

I think the other thing to acknowledge is that things will go wrong. In every project, especially a long project, bad stuff’s going to happen. Whether that’s a miscommunication and somebody’s feelings get hurt, or whether someone goes about building a feature in a bad way that produces a bug that’s upsetting to a stakeholder. Whatever it is, something’s going to happen, right? Us particularly, maybe around scoping, right? You scope a project a certain way, it doesn’t turn out the way you thought it might, and now you need to adjust.

I think the trick in all of those circumstances is just connecting to the human beings on the other side of the organizational divide and being reasonable. If you screwed up, you call them up and apologize and say, “I screwed up. How can we fix this?” If you think you’ve miscommunicated and someone seems upset, ask them, “Are you upset about this right now? Can you explain to me what’s going on and how can we work it out?” I think having those sorts of things in place, just being real human beings talking to each other rather than sort of abstractions of people in your mind that you blame for things, which doesn’t really get anyone anywhere, that’s how you make sure that a responsive project, or any other project I suppose, goes well.

Toby:

And to pick up on that, I think using that communication process to basically pick a side, as far as the decisions that you’re making, is essential. The library exists as a space for everyone, and that’s led us into some blind alleys in the past where we tried to provide too many pathways to too many services on the website as possible. We’ve run into some issues, our previous site had almost dueling navigation that was almost exactly the same in certain spots of our site, and we realized it’s because we were trying to sort of please everyone at once. We realized that by having the open process, it really enabled us to come to a decision point and then be able to communicate why we’re doing something one way and not the other back to the various stakeholders and hopefully use that to keep people on board and keep morale high.

Karen:

Well Toby, Matt, I want to say thank you from the bottom of my heart for coming on our little show here today. This has been really a winner all around. I think you have an impressive site and that is reflected in how impressive the process is. So, thanks for talking about it.

Toby:

Oh, thank you.

Matt:

Thanks so much Karen, and thanks Ethan. We’re happy to be here.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast. Thanks also to our sponsor, Media Temple. Go to mediatemple.net for easy to use hosting and 24/7 customer support.

If your company wants to go responsive but you need a little help getting started, Karen and I offer a two-day onsite workshop to help you make your responsive design happen. Visit responsivewebdesign.com/workshop to drop us a line—we’d love to hear from you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every episode at responsivewebdesign.com.

Thanks so much for listening, and we’ll be back next week.