Safetygoat

Redesigning BView part 1: It’s all in the past

Wednesday, May 20th, 2009

I’m in the process of redesigning our website at work.

It’s a project I’m really excited about, and I thought my experiences with it would be helpful to anyone approaching a website redesign. A lot of the design in this post is quite embarrassing for me, as I made so many mistakes in both process and as a designer, but we are better designers for the stuff we’ve done in the past, and it makes the new stuff look oh so much better.

A daunting start

I have been working at BView for over a year and a half now, and I have learned so much since I’ve been here. Being in a small company (there’s only 6 of us now!) means that each role is important.  When I started out in October 2007, we had up to 16 people (a lot borrowed from another company), and I inherited a logo, and a basic design for the few key pages.  I was asked to work on this project as the designer 2.5 days a week (with the other few days on the parent company’s site).

The development was already over a year in, them working solely off complicated wireframes, but the design could change (ie. I could change colours and icons), making sure functionality didn’t. Therefore user flow couldn’t change.

Here’s the original screenshots I inherited:

Original methods meant a doomed design process

BView had a LOT of functionality to start off with:  we wanted to launch with the ultimate resource for business owners (very ambitious).  We had lots of tools that solved every problem (even before anyone thought of it), and scope creep had been rampant.  We had too many features, not a lot of design or usability experience (from me or from anyone else), no time to do proper usability on any of it, and we were launching in March 2008 (5 months away).  Working only 2.5 days a week meant that I wasn’t always in the picture, and the design process was completely dominated by old school management and tech sign-off processes (reems of paper, reems of screenshots, all requiring stringent sign off on them).  We were about as agile as an elephant in a London apartment.

I knew there should have been some processes in place and made a few attempts to implement some, but unfortunately had no experience implementing them in the past and had also come into the game very late.

We all made design decisions haphazardly, and we changed our minds all the time. I know I changed the button style more than 10 times before our final launch. There was more than 25 required screen shots for the business profile alone (each page had 5 tabs, plus you needed to show ‘logged out empty’, ‘logged out full’, ‘logged in empty’, ‘logged in full’), the same again for the user, and then there was a lot of search related stuff.  We also wanted everything in there and we didn’t pay enough attention to what the site looked like when it was empty.

With no hierarchy, a very flexible grid, an obsession with getting everything above the fold, a personal dislike of the logo design, no ability to change functionality or userflow and requiring sign off from everyone and their mother, the design came out, well…..  It lacked coherence.  It lacked polish. It was not that good and it was very very blue.

Doomed design lead to doomed front end implementation

Our front-end developer was also just working 2.5 days a week on implementing it, and because of the disorganization, hap-hazard design decisions and complicated nature of the site, couldn’t even get close to getting all the design into code on the site (and because of these constant changes, we ended up with a bloated style sheet that was pretty much completely unusable).  He’s a great front-end coder but (not surprisingly) became really frustrated with the whole thing, and a few months before launch, he left the company. We were left with a temp worker, who did his best to finish implementing the site in a very short period of time (less than 1.5 months left).

Day before launch, I cried.

The front end didn’t even look close to my design (which wasn’t exactly amazing to begin with), and I refused to tell anyone I knew which website I worked for.  Frankly, I was incredibly embarrassed.

It’s darkest right before dawn though…

Since our front-end guy had left, and the search for a competent front end coder was a barren one, our java developers were nice enough to pick up the front end a bit.  I had been begging to at least go in and clean up some of this code for months, as I was fairly competent at css and html at that point, but was met by a “tech lock-down” (also known as, “Don’t let the designer near our beautiful code!” and to be fair, the backend is pretty good looking and efficient, so I can understand the concern).

Finally, our head of tech (who is fantastic at tech, and the backend of BView is incredibly well built because of him), bless him, said that I was to take over the front end coding completely, because “there wasn’t any more work to do on design”.

Excuse me?  Anyone who looked at our site would realize what a farce that comment was. No more design work?  The look I gave him. haha!

But I did it, and with a lot of hard work by both me, the head of product, Colin, and the wonderful support of the entire dev team, we’ve made the whole site a lot simpler, and a lot easier to use.

BUT it’s still not EASY to use.

It’s too busy, we have to repeat ourselves over and over (buttons need to appear twice because they’re not thought out) and styles are still created hap-hazardly based on personal preference.  People look at the site and go “AHHH!” and don’t know what to do.  I know I do.

And, frankly, the site could be a lot more exciting and beautiful.

This is ME saying it, who’s built it from scratch. Not everyone sees the available functionality we’ve actually got some really good functionality in there.  The css is also still a bit bloated (although I have shaved a few thousand lines off of it already) because of random ‘designing as we go’ decisions.

I’ve been learning all I can about webdesign in my free time too, which means that I am now 1000 times more capable of making the site work well.  All my other designs since I’ve started here have been at least a bit fun, and had some character.  I wanted that for BView.  I also want to, when asked, “Who built this site?” to be able to proudly say, “I did.”

So, kids, what have we learned?

1. Design should be involved in designing the functionality from the start.

2. You should make it as easy as possible for people to interact with your site and give you content. Functionality is nothing if people can’t use it.

3. Sites should start with a few key features and do them (almost) perfectly.  Add features as needed: you don’t need to start with EVERYTHING

4. Doing technical work actually makes designers more disciplined (which is fantastic for big sites).

5. Planning is important, and everyone should be involved.

6. Personal preference for how something looks should take a backseat to usability.

7. Designers need to gain their tech and their management’s confidence so they are trusted to do the job properly without being micromanaged.

8. Design by committee leads to dull, dull, complicated websites.

9. The broken record every designer goes through: Not everything needs to be above the fold, not everything is required on every page, white space is very important and links don’t need to be link blue and underlined to look like links.

10. Most pages on a website will be empty (so those should look just as good as a full profile), and you can’t trust users not to put THINGS IN ALL CAPS AND MAKE THEM REALLY LONG SO THEY WRAP OVER 3 LINES.

11. Designing things simply and well takes time and talent.

12. Designs are never perfect the first time you implement them.

13. Your website has a brand and a personality, and you should make sure they’re good ones.

14. No one will care about making things perfect as much as you, and it’s your job to be anal about the details.

Next:  priorities for the redesign!

bviewlearning designredesign Uncategorized art