How do you redesign something

Over at HackerNews “prateekdayal” asks:

I run an online music community with decent traffic and usage. When we started out, I had no background in web (and usability) and have learnt a lot in the last two years. I can now tell whats lacking in the current design (aesthetics/usability/interaction wise) but still don’t know if I can design from scratch. I do have a designer (to help with graphics) but he is good only with skinning so I have to do the usability and interaction design work.

What is the best way out of this situation given that I can’t hire external help (for financial reasons of-course). I have been thinking of reading some good books on web design patterns and following standard practices. Does that work well?

The biggest thing to manage in a redesign is risk. Risk you alienate your user base or do something that negatively impacts revenue, or whatever you’re most afraid of.

The easiest way to manage it is to shorten your feedback cycle (not user feedback, any type of feedback) to the smallest possible interval. When talking about design, this means you need to spend the least amount of time on the design you can before you put it in front of someone that exemplifies your average user (persona).

CC Kyle Steed

CC Kyle Steed

This is usually done through some sort of lo-fi mock up or wireframe first. To do an effective job at that, you probably first want to evaluate your information architecture. However, this whole process shouldn’t take more than a day or two of work. That means you may only “waste” a day of work if your direction ends up not working out. You haven’t involved a designer, you haven’t pushed a single pixel, and you definitely haven’t written any code, but you’re already getting into a feedback loop.

To test a wireframe in front of a user, you want to do something called “wizard of oz” testing. This is a process where you take paper versions of your wireframes, and put them in front of a user. You can cut up hte prototypes to make the pieces easier to change out as you let the user “use” your wireframes. Don’t worry about how rough your wireframes are as you’ll find that people are pretty forgiving when involved in woz testing.

Another great thing about wireframes is that it’s extremely fast to iterate on a them. You can sometimes make small changes while you have the user right there doing the test. Larger changes will probably only take a few hours. Again, this is a feedback loop on changes of 10 minutes to 4 hours.

This whole process might take you 3 or 4 days of work, but the feedback loop it creates may save you 3-4 months of work down the road. It’s probably also going to save you money when it comes time to actually do a design (which you want to again test with the users) and implement your changes (which you can test through bucket testing).

Each time you can create a feedback loop throughout the process, you’re decreasing the risk of the redesign. It’s not dissimilar to writing unit tests to make technical refactorings more manageable. Unit tests are the ultimate in development feedback loops and decrease the risk that changes you make to your code base are going to break unexpected other parts of the code base. The same things can be said for user testing feedback loops for visual and UX designers.

  • Hi BJ

    I just saw your reply on my thread in HN. I am still trying to figure out how to subscribe to replies there 🙂

    Thanks for the detailed post. I think what you say makes a lot of sense. I will probably use Balsamiq and put up the mockups online for users to comment on. Will let you know how it goes once I am done with the experiment.

    Thanks again!

    Prateek Dayal