I was asked this past week to consult for a company embarking on a huge new website redesign. I thought I’d write up some thoughts that I would share with anyone in that position.
You cannot neglect mobile.
Look at any graph of mobile usage and it will tell the tale for you. Millions of mobile devices enter the world every day. Ignore this to your own demise.
You’ll need to decide if you are going to build a mobile-specific site or not.
Mobile is a whole different world. There is literally less room on their smaller screens. They often have lower bandwidth. They often have user input that desktops doesn’t have (think: swipe, pinch, or shake) and vice versa (think: mouse cursor, right-click, or modifier keys).
Can you handle all of that in a single site? Maybe you can. Responsive design can help with this and is an awesome solution for a lot of sites. But don’t force it at the determent to both desktop and mobile experiences. You might have to split into two - which ensure speedier and easier-to-dev sites. But now there are two sites to keep in sync which comes with its own struggles.
Your CMS needs to be in good shape.
You should be able to ask your CMS for anything you want and get it. I need a full size image of that product - here you go. Now I need thumbnails of related products - here you go. I want the title, subtitle, and intro paragraph of that article - here you go. I want a bunch of content inside of this template - here you go - now the same in a different template - here you go. I want to request some content via Ajax and get just the content back, no markup - here you go. At the outset of a project is a perfect opportunity to build/choose/customize a CMS that works for you.
Need a guide? Try the book Content Strategy for Mobile by Karen McGrane.
Karen says in her talks there are companies that will go out of business because they are so bogged down by their CMS and can’t accomodate mobile and the future of content delivery. I’m sure she is not wrong.
You need a plan for your CSS.
You have options for just about every other technology you choose for a project, but you always need to use CSS. CSS is simultaneously very easy and incredibly difficult (day to learn, lifetime to master). On a large project, you really need to develop a design system. That means re-usable parts and design patterns that help you build quickly and keep you consistant.
Everyone is happier when the code we interact with is clean and consistant. Even if it doesn’t match your own style perfectly, consistency is the most important thing. Establish a style guide. Here’s some to peruse.
You should be preprocessing your CSS.
Design systems are a lot easier to build (and CSS is generally a lot easier to write) when using a preprocessor like Sass. You can set variables for colors to keep those consistant. You get CSS3 mixins for free with Compass or Bourbon. You can break up patterns into individual files to keep sane and organized. You can compress your CSS as you author so essentially performance is part of your workflow (small concatenated files = fast).
Need a guide? Rebecca Murphey writes about this kind of thing.
You’ll need to think about version control.
Team development requires version control. Git is a solid choice. I’m no version control master, but the popularity of it and resources to be found about it speak for themselves. Branching and merging is fairly easy.
Have a pristine master branch that nobody works from. Then a staging branch. Then individual “feature” branches. You can “merge up” from staging anytime into a feature branch to keep in sync. Then “merge down” features into stage when they are ready. Staging is what you test and where all features come together. Then when ready, that goes to master.
Beyond the obvious advantages of keeping code in sync and tracking changes, it gives the whole team the ability to see what everyone else is working on by looking at commits. This helps team accountability.
You’ll need to think about staging and deployment.
That staging branch I mentioned above? That would be good to have auto-deploy (deploy = move files to a live server) to a testing server. Ideally this testing server is as identical to your live server as you can make it. Do your testing there. Then when it’s good, move staging to “production” (you’re live server that your user’s actually use).
Deployment itself is an entire big topic. Likely you are caching assets, so you’ll need to break that cache on assets that change and not break it on assets that don’t.
You’ll need to think about robust hosting.
Can you upgrade your servers on the fly? How do they handle heavy load? Are you load balancing? How is the customer support at your hosting provider? Will they respond 24-7? What are the costs? Are they substantial enough to bring hosting in-house?
Do they monitor your server performance or is that up to you? Your host probably has tools for monitoring server performance. New Relic is an app that can help with that.
Most big websites have someone (or a team) just for handling servers. It’s a unique skillset, different from development.
You should let UX steer the ship.
Every decision you make should be about making things better for the people who use the site. Try to never make a decision based on technical difficulty. That might mean you specifically have UX people. Even better, everyone on your team understands and cares about UX and makes it a priority. This isn’t just a design thing, it’s everything.
Think about performance from the start.
Performance is often this thing web teams do “later on.” You have a good opportunity here to make smart decisions about performance from the beginning. Load as few assets as you can. Compress them as much as you can. Cache as much as you can both on server and client. Make sure your server guy is on top of things like response time.
Need a guide? Steve Souders’ books and blog are fantastic.
Make sure your team is excited.
Building a big website is huge and all-encompassing endeavor. It’s hard to do at all and much harder to do well. You need a team with a fairly wide array of proficiencies and likely someone steering the ship who’s proficiency is ship-steering. It takes time and patience. It takes money. Beyond all that, you all need to be excited about it. You won’t make good decisions if you aren’t excited about what you are building. Struggles are harder to overcome if you aren’t excited to get past them.
I asked on Twitter: “What kind of advice would you give someone about to start a huge new web project?” I got back some good stuff.
Pantone Name Number HEX code
- Emerald 17-5641 00A78D
- Dusk Blue 16-4120 7DB6D3
- Tender Shoots 14-0446 BFD74B
- Lemon Zest 13-0756 FFDF5E
- Linen 12-1008 F8DFC9
- Poppy Red 17-1664 D9302B
- Grayed Jade 14-6011 98CCB6
- Monaco Blue 19-3964 154478
- African Violet 16-3520 B995C5
- Nectarine 16-1360 F68E51
Responsive Web Design is more than just adjusting a web experience to different screen sizes. Becoming device-agnostic is an important step for creating future-proof websites and here are a couple of thoughts on that.
Apple just released the iPad mini; yet another mobile device to deal with and design for. The real purpose of responsive design is to get to a point where your web design is completely device blind. Your design shouldn’t really care about the pixel dimension of the device it’s being viewed upon. That is what device agnostic design really is, it’s not just a new web buzzword for sales and SEO reps to exploit — it’s a real design concept.
The big, huge, gigantic question is how to design a device-agnostic web site? Honestly, we’re not going to be able to answer that question fully in this article. It’s kind of a complicated thing, but it’s not too early to start designing in an agnostic way.
Now is a great time to start designing or at least thinking about how your designs can be device-agnostic — get in on the ground floor and stay ahead of the game, don’t let the devices run your life. It’s important to start thinking in a different way even if all solutions aren’t truly present yet.
read more on the source: