-2

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.

  • 1
    "Your questions should be reasonably scoped..." (help center) – gnat Sep 9 '16 at 16:55
  • 2
    That's really too broad and without knowing the project can't really be answered. IMHO at least the design phase should be finished and a complete new design exist before implementation. But that's from my experience with a not that large project. (Also maybe unless that site has functionally very clearly distinct parts). If you then implement everything in one go or in parts may depend but chances are old and new design & usability won't fit together very well anyway. – thorsten müller Sep 9 '16 at 17:07
2

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.
| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.