Jordan Hudgens: In this guide we're going to learn what a sitemap is and how to construct one. We'll talk about some of the goals you should have when you're building one and how you can translate those into building the user experience. We'll also discuss providing the sitemap to your developers so that they know what screens to build.

Jesse Cook: The frame of mind that you should be in when you approach a sitemap is that it should answer all of the user stories. We've created all these user stories, so I'm going to create a separate sitemap for each user. Whatever those user stories are, I start going through them. Jim needs to be able to message, so I need to make sure that there is a messaging page. Once I create that page in the sitemap, I indicate the main unique actions that happen on that page.

There's a lot of "dealer's choice" here. Most people are going to build their sitemaps a little bit differently. They're going to use different programs. I really like Lucidchart because of its team aspect and that you can have multiple people participate on it. Then it becomes about how you indicate what a page is, and what actions are.

Another thing is: how granular do you get? You might think, "OK, I have all these pages, and I can click 15 things on each one of these pages." Well, sure, but you don't have to indicate that on every single page. That's a little too granular. In my opinion, it's not very productive, because you could click the logo on every single page and it'll take you to the home page. But I don't need to indicate that on every single page of my sitemap.

Here, you can see that there are two main shapes: rectangles and diamonds. This is my own personal thing. You may be working inside of a company that already has these conventions established, or you'll be coming up with them yourself, but I like using rectangles for pages and diamonds for indicating user actions that solve user stories.

You can see that these actions either take you to other actions or to another page. When you map it all out, you should be left with a picture of all the pages that need to exist and the key actions that can be taken from each of them. This will really give you a clear idea of how you're going to solve all of the user stories you've already created.

JH: That's awesome. It's a great example of how you've translated user stories directly into something functional that you can use.

Now, Jesse, after you've built the sitemap, which stakeholders do you meet with and get feedback from? Obviously, I'm assuming the client, but do you also take this to the developers? Who else are you connecting with?

JC: It'll hit the developers after it's been approved by the client (or the product owner or whoever is running that). You'll work through the sitemap with them, with the user stories right alongside it. A lot of times, clients will get kind of glossy when they see this. It's not the sexy thing that they see in their mind. But the main thing is that you're saying: here's our list of user stories for Jim. Jim wants to be able to message. Bam, this is where he goes to message. What else can he do? He can send a message, he can receive a message, and he can flag a message, so let's indicate those. What happens after the flags a message? Does he go to another screen? Does he go to an approval screen, or something else? We can indicate that. We have our messages screen represented in our sitemap, and we have an action under it: "flag message." Then we can have an arrow that takes us to review flagged content, and I can represent that.

When I get into later phases of the development I'll have a very clear idea. It's so much better than just taking notes, or even skipping past it. You might be inclined to say "I've got my user stories, let's get this done," but this is helping you fill in the gaps so that you don't have to rework your designs. You don't end up saying, "Oh dang it! I totally forgot about this entire thing. I've got to go back through all my designs," because design is a lot harder to manipulate than just going in and adding rectangles and diamonds.

JH: That brings up a great point. We talk about stakeholders and how important it is to have this kind of foundation to look back at. I remember, for one pretty large-scale application, I had a client who was not technical whatsoever. I had already built close to half of the application, and, while I thought it was going well, this client had nothing to look at that he could understand. He couldn't go look at my code, the application wasn't ready to prototype, and because of that he kept asking for what was essentially a sitemap. He wanted to see lines going to boxes to see what one user could do and what another couldn't. I ended up having to build something like this halfway through the project. If I would've done it at the beginning, it would have helped me in my development, but even more important is that it would have helped the client understand all the processes that were taking place.

JC: Right, right. And obviously, after this has been approved by the client, you're taking this to team leads, and the team leads are taking it to the developers. So, regardless of how interested you are in sitemaps, as a developer you will need to know how to understand them. And they're not terribly complicated. Of course, that may also depend on who's creating the sitemap for you, but I don't like making mine terribly complicated because that's just miserable.

JH: Right.

JC: It's important to be able to understand this because, the better the communication bridge between creative and development, the smoother every project is going to go. The better you can understand the sitemaps that are being created, the more valuable you are as a developer because you won't have to walk through it over and over and over again. You're going to see holes and all the things we talked about before, and you'll be able to get a quick picture of the project and know what's being communicated.

JH: Absolutely. I love the tools we have now that we didn't have a few years ago. You could see in the example sitemap that there are spots for comments. When I was working with the design team on this specific diagram they would ask me questions like, "What type of functionality are you looking for right here?" when they didn't have all the clarification they needed. And that's a great thing, because, not only are these tools good for building the sitemap initially, but they're also good for collaboration while it's being built. You can clear up a lot of mistakes in the very beginning by being able to communicate properly with all the stakeholders.

JC: Right! I definitely get pinged every once in awhile by developers asking, "What is going on here? What is this page? Where did this come from?" It's really nice when you don't have to cut through anything, you can just go right to the question and you're all on the same page really quickly.