Where to start on a redesign
August 17, 2010 1:43 PM Subscribe
Redesigning website. Where to begin?
Well they put me in charge of redesigning our corporate site. Yea. I'm excited. But without any help, where do I even start?
They want a content overhaul first but I also feel this is the time to start thinking about directory structure. But we also have no goals for the site (we're still trying to reassess our point). So I feel like there is so much to tackle but without a mission, I don't know where to start.
Also, any sites/links helping with strategy/project plan to tackle this?
It feels totally like I'm playing Pick Up Sticks while blindfolded
Well they put me in charge of redesigning our corporate site. Yea. I'm excited. But without any help, where do I even start?
They want a content overhaul first but I also feel this is the time to start thinking about directory structure. But we also have no goals for the site (we're still trying to reassess our point). So I feel like there is so much to tackle but without a mission, I don't know where to start.
Also, any sites/links helping with strategy/project plan to tackle this?
It feels totally like I'm playing Pick Up Sticks while blindfolded
Totally wait on the content overhaul.
Not seeing why you need a different directory structure other then:
Root
I guess you could also divide large sections of pages into their own directory if you think it'll be easier.
posted by royalsong at 1:51 PM on August 17, 2010
Not seeing why you need a different directory structure other then:
Root
- Media
- Images
- Video
- Other
- Scripts
- Downloads (pdfs, etc)
I guess you could also divide large sections of pages into their own directory if you think it'll be easier.
posted by royalsong at 1:51 PM on August 17, 2010
This comic rings so true to my job, I wish I could personally print it out and hand it to the persons in charge of redesigning our website. I second Amtho- what do people need to see when they reach your home page?
posted by pickypicky at 1:57 PM on August 17, 2010 [1 favorite]
posted by pickypicky at 1:57 PM on August 17, 2010 [1 favorite]
Response by poster: Sorry by directory structure I mean the content is in this hodge podge of navigation. Most of it is misleading to the customer. They think "oh here is where I'll find X" based on the nomenclature. They get to it and go "WTF. This isn't what I wanted."
To me, doing content first seems odd. One would think establishing what this site should be is the first step. But they think differently. Feels like I'm doing this backwards.
posted by stormpooper at 1:58 PM on August 17, 2010
To me, doing content first seems odd. One would think establishing what this site should be is the first step. But they think differently. Feels like I'm doing this backwards.
posted by stormpooper at 1:58 PM on August 17, 2010
Response by poster: Pickypicky--you know our site/organization. Thus is the challenge.
posted by stormpooper at 1:59 PM on August 17, 2010
posted by stormpooper at 1:59 PM on August 17, 2010
If you have a budget, I strongly recommend hiring someone, if you don't know how yourself. If your budget is very small, you can sometimes cut a deal if you do the upfront work (described below) and present it to a developer.
This(bad stock photography warning) might be a good place to start.
Know what the web site is for before you do anything. If you don't know--or can't agree--on what the site is for, you're probably going to end up with a mess.
Write down a list of all the stakeholders in the web site; anyone within the company who has a stake in what the end result will be. Schedule a one-on-one meeting (could be 15-20 minutes) and get them to answer a few questions: what do they want from a website, what do they think it's about, what's their worst-case scenario. Look for big ideas like, "I want it to be useful to our sales team," and less things like, "I want a calendar." The first might mean that you want surveys, A/B testing, and Google Analytics built in. The second means you have a calendar.
Write down common themes in goals and insecurities and figure out how to maximize the first while mollifying the second.
If you have a direct line to the people using your website, try to get in contact with them. Ask them what they would like in a new website and what their points of frustration are.
Next, figure out what content you will need. Twist arms to get it written. Often the best way to get something written is write something you kinda know is bad, then pass it by the desk of the person who's been putting off writing that same copy for three weeks. Assuming they care at all, they'll dive into editor mode and start hacking.
If you're editing copy, remember that most internet users move extremely quickly through web pages, reading only the first line of a paragraph. "Frontload" your paragraphs with sentences that clearly describe the information contained within; a skimmer's content detector will light up and they'll slow down to take in the information they need before launching into skim mode again.
Once you have the copy, figure out how to arrange it in a way that makes sense to the users of the site. Information Architecture can be hard, but don't be afraid to be daring. If you only need six pages, only have six pages. Simplify as much as possible--it will make maintenance easier, make it easier for users to comprehend the whole, and lets you spend more time on each page. Push back against bloat--a half-used or half-realized feature is worse than one that doesn't exist at all.
If you don't have design or markup experience, this is where you box up all the work you've done with some nice documentation and send it off to a web developer. Be nice to them, they work hard.
If you're rolling your own, there's a lot of resources on getting started with web design and development. I recommend books over websites: books tend to provide a better overall narrative and a consistent tone. A decent book will also not be guilty of huge omissions that wouldn't be obvious to a newcomer.
posted by TeslaNick at 2:08 PM on August 17, 2010
This(bad stock photography warning) might be a good place to start.
Know what the web site is for before you do anything. If you don't know--or can't agree--on what the site is for, you're probably going to end up with a mess.
Write down a list of all the stakeholders in the web site; anyone within the company who has a stake in what the end result will be. Schedule a one-on-one meeting (could be 15-20 minutes) and get them to answer a few questions: what do they want from a website, what do they think it's about, what's their worst-case scenario. Look for big ideas like, "I want it to be useful to our sales team," and less things like, "I want a calendar." The first might mean that you want surveys, A/B testing, and Google Analytics built in. The second means you have a calendar.
Write down common themes in goals and insecurities and figure out how to maximize the first while mollifying the second.
If you have a direct line to the people using your website, try to get in contact with them. Ask them what they would like in a new website and what their points of frustration are.
Next, figure out what content you will need. Twist arms to get it written. Often the best way to get something written is write something you kinda know is bad, then pass it by the desk of the person who's been putting off writing that same copy for three weeks. Assuming they care at all, they'll dive into editor mode and start hacking.
If you're editing copy, remember that most internet users move extremely quickly through web pages, reading only the first line of a paragraph. "Frontload" your paragraphs with sentences that clearly describe the information contained within; a skimmer's content detector will light up and they'll slow down to take in the information they need before launching into skim mode again.
Once you have the copy, figure out how to arrange it in a way that makes sense to the users of the site. Information Architecture can be hard, but don't be afraid to be daring. If you only need six pages, only have six pages. Simplify as much as possible--it will make maintenance easier, make it easier for users to comprehend the whole, and lets you spend more time on each page. Push back against bloat--a half-used or half-realized feature is worse than one that doesn't exist at all.
If you don't have design or markup experience, this is where you box up all the work you've done with some nice documentation and send it off to a web developer. Be nice to them, they work hard.
If you're rolling your own, there's a lot of resources on getting started with web design and development. I recommend books over websites: books tend to provide a better overall narrative and a consistent tone. A decent book will also not be guilty of huge omissions that wouldn't be obvious to a newcomer.
posted by TeslaNick at 2:08 PM on August 17, 2010
Having done two major overhauls of our site in the past five years, I can see both sides: content overhaul vs. directory overhaul. We needed both.
You will never convince the others in your job that a directory overhaul is needed, because they don't know, don't understand, and don't care about the back end of the site. Don't even use the terms "directory structure" to them, because they will get confused. All they see is the content of the site, so that's what's important to them.
Phrase it this way: we need to identify the large content areas that our site contains, and to sort all the content into these X content areas. (We arbitrarily picked four, because the rest of the committee was adamant that we not clutter the home page.) We also identified our main users and their needs, and why they came to the site and used those to create the content areas.
Those content areas will give you both your base navigation and your directory structure. You can then set others (assuming you're part of a committee) to the job of overhauling the content within those areas.
We didn't do any real user testing until after the site went live, because we were under deadline. We've done a bit since, and it's mostly working, although one of the content areas that we thought would be most used isn't used at all, it seems. So it may be eliminated and replaced with something else in a future re-do of the site.
MeMail me if you want more info on what we did and to see the site.
posted by telophase at 2:10 PM on August 17, 2010
You will never convince the others in your job that a directory overhaul is needed, because they don't know, don't understand, and don't care about the back end of the site. Don't even use the terms "directory structure" to them, because they will get confused. All they see is the content of the site, so that's what's important to them.
Phrase it this way: we need to identify the large content areas that our site contains, and to sort all the content into these X content areas. (We arbitrarily picked four, because the rest of the committee was adamant that we not clutter the home page.) We also identified our main users and their needs, and why they came to the site and used those to create the content areas.
Those content areas will give you both your base navigation and your directory structure. You can then set others (assuming you're part of a committee) to the job of overhauling the content within those areas.
We didn't do any real user testing until after the site went live, because we were under deadline. We've done a bit since, and it's mostly working, although one of the content areas that we thought would be most used isn't used at all, it seems. So it may be eliminated and replaced with something else in a future re-do of the site.
MeMail me if you want more info on what we did and to see the site.
posted by telophase at 2:10 PM on August 17, 2010
Adding: I really, really, really, really wanted to design the content and structure of the site before I designed the look of it, because I wanted to let the content inform the design.
I could not convince anyone else of that. So after we picked those four main content areas, I then produced several designs and the committee picked the one they liked best, and we shoved everything else into that. Not the ideal way to overhaul a site, but there's a compromise between getting it done right and getting the damn thing done at all.
posted by telophase at 2:13 PM on August 17, 2010
I could not convince anyone else of that. So after we picked those four main content areas, I then produced several designs and the committee picked the one they liked best, and we shoved everything else into that. Not the ideal way to overhaul a site, but there's a compromise between getting it done right and getting the damn thing done at all.
posted by telophase at 2:13 PM on August 17, 2010
Ooh. Okay, I follow.
I would worry less about navigation until you have a storyboard/flow chart laid out of what content you will have. Then divide that up into your navigation areas. It would suck if you were dead set on this one navigation and then the Big Boss wants you to have a huge section about birds.
If you're in charge, and sounds like this is a one-person job, you ultimately have the say about the actual design - including navigation. You need to do the prep work first.
posted by royalsong at 2:19 PM on August 17, 2010
I would worry less about navigation until you have a storyboard/flow chart laid out of what content you will have. Then divide that up into your navigation areas. It would suck if you were dead set on this one navigation and then the Big Boss wants you to have a huge section about birds.
If you're in charge, and sounds like this is a one-person job, you ultimately have the say about the actual design - including navigation. You need to do the prep work first.
posted by royalsong at 2:19 PM on August 17, 2010
A Practical Guide to Information Architecture is useful, it assumes no prior knowledge of information architecture.
posted by AlsoMike at 2:59 PM on August 17, 2010 [1 favorite]
posted by AlsoMike at 2:59 PM on August 17, 2010 [1 favorite]
I took a class that covered web redesign awhile ago and we read this book. It's admittedly a little old, but I think the basic process and sequence of steps they lay out might be really helpful for you.
posted by grapesaresour at 3:19 PM on August 17, 2010
posted by grapesaresour at 3:19 PM on August 17, 2010
The book I always wish everyone involved with me on a web project had read is Don't Make Me Think. Not so directly useful with your information architecture questions, but definitely helpful for the 'consider what users want from the site' mindset.
Also do you have access to log files or any sort of analytics for the current site? When you're having those discussions about what needs to be prominent on the landing pages having hard data around ican short circuit a lot of arguments. Particularly useful data is what people are typing into the on site search (if you have it) because this tells you what visitors were looking for from your site but couldn't figure out how to get to with the current structure.
posted by robertc at 4:36 PM on August 17, 2010
Also do you have access to log files or any sort of analytics for the current site? When you're having those discussions about what needs to be prominent on the landing pages having hard data around ican short circuit a lot of arguments. Particularly useful data is what people are typing into the on site search (if you have it) because this tells you what visitors were looking for from your site but couldn't figure out how to get to with the current structure.
posted by robertc at 4:36 PM on August 17, 2010
Start with the content strategy, this involves, among other things, a content overhaul. Seriously, without really understanding what content you have, the content types, etc. you're likely to run into problems with the information architecture.
I second AlsoMike's suggestion for reading A Practical Guide to Information Architecture, though I have not read that one, Five Simple Steps generally produces good books. A second book would be Kristina Halvorson's Content Strategy for the Web.
If you can, I would really suggest bringing in a good outside content strategist. In large part because a professional outsider view will not have political baggage an internal person may have, but also because it's useful to bring in someone that specializes in this stuff. Redesigning a website is no small task and this is your company's public face with your customers.
posted by thebestsophist at 5:29 PM on August 17, 2010
I second AlsoMike's suggestion for reading A Practical Guide to Information Architecture, though I have not read that one, Five Simple Steps generally produces good books. A second book would be Kristina Halvorson's Content Strategy for the Web.
If you can, I would really suggest bringing in a good outside content strategist. In large part because a professional outsider view will not have political baggage an internal person may have, but also because it's useful to bring in someone that specializes in this stuff. Redesigning a website is no small task and this is your company's public face with your customers.
posted by thebestsophist at 5:29 PM on August 17, 2010
Site goals are as simple to determine as to know what you sell. What you sell can be a physical thing or a conceptual thing. Facebook, for example, sells the ability for friends and acquaintances to network.
If there already is an iteration of the corporate website then you should have an idea of what you are selling. You should know what works to sell the "product" and what doesn't. If you are not getting feedback, start now. Send out emails with questionnaires or make a form on the website trying to get a feel for what they want. Get an intern to navigate the site looking for particular things, as a customer would. Have them comment on their experience. Use your Google Analytics stats to see what pages are important and who your customers are. Where do they enter, where do they leave?
Like an architect, structure is important only after you have already determined the conceptual flow between spaces.
posted by JJ86 at 7:06 PM on August 17, 2010
If there already is an iteration of the corporate website then you should have an idea of what you are selling. You should know what works to sell the "product" and what doesn't. If you are not getting feedback, start now. Send out emails with questionnaires or make a form on the website trying to get a feel for what they want. Get an intern to navigate the site looking for particular things, as a customer would. Have them comment on their experience. Use your Google Analytics stats to see what pages are important and who your customers are. Where do they enter, where do they leave?
Like an architect, structure is important only after you have already determined the conceptual flow between spaces.
posted by JJ86 at 7:06 PM on August 17, 2010
Like TeslaNick said, if you don't settle on a goal for your site, you'll spin your wheels. Even if a content rewrite is the extent of this phase, you'll probably make some big improvements and cut down on needless pages. That alone might get you a budget to do a proper site redesign as part of a phase two.
I'm overseeing a site redesign now. Had we done it right the first time (ie, had a budget, goals, deadlines, etc.), we would've saved ourselves and users a lot of frustration. The more we get into the project, the more I'm convinced that user expectations for website usability, design, and functionality are too high to roll the dice on on-the-job training. If you don't know where to start, you'd probably be best used in site strategy, content writing, and project management.
Good luck. It's a challenging, but visible and hopefully rewarding experience.
posted by tenaciousd at 8:12 PM on August 17, 2010
I'm overseeing a site redesign now. Had we done it right the first time (ie, had a budget, goals, deadlines, etc.), we would've saved ourselves and users a lot of frustration. The more we get into the project, the more I'm convinced that user expectations for website usability, design, and functionality are too high to roll the dice on on-the-job training. If you don't know where to start, you'd probably be best used in site strategy, content writing, and project management.
Good luck. It's a challenging, but visible and hopefully rewarding experience.
posted by tenaciousd at 8:12 PM on August 17, 2010
Content rewrite, new navigation labeling, goals, and directory structure are all things to be considered during the planning phase of a project like this. In order of importance however, goals should be at the top of the list.
Typically, a project like this starts with a somewhat vague sense of "what it will be like when it's done," and the documentation gets progressively more detailed, always building on what was done before.
If you're working with management (that has veto power), make sure you get iterative approvals along the way. And always restate the objectives as you're presenting updates to your project / planning.
Some other best practices include:
Don't make your visitors wonder what is behind a button/link. The descriptions are important and should be indicative of the content behind the link. This typically means dropping your industry vernacular and instead thinking like a customer.
Search engines reward sites that are logically structured and do not try to do too much on any single page.
If your site includes static html pages, the naming of the pages is extremely important to search engines. Do not skip the planning step of actually listing the names of the HTML pages, what their, META Keywords, and META descriptions will be. Not only will this make your programmers happier, it will help ensure that you're site is complete and correct (because you've of course thought of everything).
Include as part of your deployment phase alerting the search engines to your new site.
Spending more time planning can reduce the amount of time actually doing. My own rule of thumb is 60% - 70% planning, and 40% - 30% doing. (by doing, I mean the actual building of the pages, the functionality functionality, etc that was identified in the planning phase).
I do this kind of work for a living (self-employed). Memail me & I'd be happy to give you some time to answer more specific questions.
Cheers.
posted by bricksNmortar at 8:52 AM on August 18, 2010 [1 favorite]
Typically, a project like this starts with a somewhat vague sense of "what it will be like when it's done," and the documentation gets progressively more detailed, always building on what was done before.
If you're working with management (that has veto power), make sure you get iterative approvals along the way. And always restate the objectives as you're presenting updates to your project / planning.
Some other best practices include:
Don't make your visitors wonder what is behind a button/link. The descriptions are important and should be indicative of the content behind the link. This typically means dropping your industry vernacular and instead thinking like a customer.
Search engines reward sites that are logically structured and do not try to do too much on any single page.
If your site includes static html pages, the naming of the pages is extremely important to search engines. Do not skip the planning step of actually listing the names of the HTML pages, what their
Include as part of your deployment phase alerting the search engines to your new site.
Spending more time planning can reduce the amount of time actually doing. My own rule of thumb is 60% - 70% planning, and 40% - 30% doing. (by doing, I mean the actual building of the pages, the functionality functionality, etc that was identified in the planning phase).
I do this kind of work for a living (self-employed). Memail me & I'd be happy to give you some time to answer more specific questions.
Cheers.
posted by bricksNmortar at 8:52 AM on August 18, 2010 [1 favorite]
« Older It'll look great next to my Scarface poster and... | Alternate to Don Alverzo's tweezers? Newer »
This thread is closed to new comments.
posted by amtho at 1:47 PM on August 17, 2010