How to handle a complete UI redesign of a web product? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 4 years ago.

Improve this question

Sorry for the codeless post, but I am wondering how to handle a complete UI redesign for a big web product? Maybe somebody have experience and could actually determine the steps on how you would do this?

Should it be done incrementally? Should it be redesigned at once and delivered to production? What could be the steps in order to achieve this (making visual guidelines? Applying new classes?). In what smaller steps I could possibly split the tasks for the team of developers?

Would help a lot valuable insights. Thanks.

Answer 1

Your question is really broad but I'll try to provide a few tips. I've been through three gigantic ($10M+) UX "refresh" projects in the past few years. Won't be fun I'm afraid. These should help, a little bit.

• Insist that functional capabilities be frozen for the duration of the project. Make it a "look and feel" project only.
• Maintain a server that runs the older version of the UI. You will need this for defect arbitration.
• Insist that all functional flows be documented in the full, even if this means reverse engineering the old site. Do NOT document only the changes, document the target state after all changes have been applied. Note: This is considerable work.
• Use an industry standard style approach in the new site, e.g. Bootstrap. This will get your responsive design and WAI/508 compliance very easily.
• If possible, move key business logic out of the UI tier and into middleware or business layer, before the UX upgrade project even starts. This will ensure business rules don't get lost during the project. Keep the business layer fixed throughout the project.
• Write a global style guide that lays out the color and font scheme; get this reviewed and approved ahead of time.
• If time allows, develop a "proof of concept" site (two or three pages) that demonstrates proper markup for all controls, panels, etc. that will be used in the site. Get this fully vetted (including cross browser testing, screen reader, mobile devices, etc.) and approved before starting development on the site proper.
• Use semantic markup, unobtrusive design, and progressive enhancement if possible.
• Build your out-of-session, login, and landing/home pages first, and get this thoroughly reviewed by the end stakeholder (not just internal QA) before building the rest of the pages.
• Go live on new hardware, and on a different subdomain if possible (e.g. if your old site was on www.MySite.com, go live on a slightly different domain name like online.MySite.com). This will make deployment (and possible rollback) much simpler. Don't forget to order your SSL certificates well ahead of time.