So I gave it a try….my verdict? Won’t do it again….

Now this is no criticism of the company that does it, because they are good at what they do and serve a purpose. The only problem is that their purpose is not my purpose Its a good solution if you are not intending to work with the templates they provide, and possibly just use it for a static website.

Problem is that they don’t think of their CSS in a way that is re-usable, they create CSS styles for absolutely everything and don’t think about optimising the CSS for re-use across pages. The end result is that your XHTML is nice and concise, but the CSS is very verbose and long (100’s of lines).

I have ended up using their XHTML and re-creating most of the CSS so that I can re-use it in my application as a template. I am still going through this process and therefore, something that would have taken me a few days to do (create XHTML/CSS from Design), is still taking me a few days to do, but I have the added complexity of working with code that was written by someone else.

Oh well, a lesson learned

So what’s a wireframe? A wireframe in software design (particularly web applications) are mocked up User Interfaces that emulate the key elements of the User Interface. Such as what needs to appear on the screen, roughly where to position it and understand what the focus for that screen is. The next step is to make the wireframes interactive, so when you click on a button it ‘emulates’ taking you to the next screen – these are prototypes.

Wireframes for me replace the old ‘back of a napkin’ concept, where you convey enough of an idea to be able to have a meaningful conversation without completing the vision to stifle any creative imagination the viewer needs. Wireframes serve many purposes, and below I go through some of the methods and benefits I have discovered.

Sketching the UI

I know some people like to put the wireframes together using interfaces that look like the end product. I actually like using sketch like interfaces to promote some creativity when people are viewing the interfaces. When I used to build Java Desktop apps, I would use the Napkin look and feel to try and accomplish the same thing. A sketched look actually means you don’t have to be so strict about positioning of elements or be pixel perfect. As long as you are communicating elements such as where buttons and headers appear, you are getting the message across.

Interactivity

Its important to be able to transition your Wireframes to prototypes. Prototypes are working versions of the wireframes. Why go to all the effort of designing screens if you can’t navigate between them?! Again, sketched prototypes are a powerful (and quick way) to communicate interactivity. Demonstrate the flow a user needs to go through and communicate what should be displayed when a certain button is clicked.

Focus on What’s Important

Wireframes and prototypes help you focus on what is important in the design. What should the page focus on; is it the form, the search box, some content or something altogether different? By wireframing it first, you are communicating what are the important elements on that screen. This is another benefit ’scribbled’ screens have over screens that are attempting to look like the finished product. If you don’t fill the finished design with all the elements such as add banners or images it looks, well……unfinished! Wireframes are supposed to look unfinished so placing a box with a cross through it as a place holder for an ad is perfectly fine.

Testing

In my opinion, this is the single most important benefit you get from Wireframes and Prototypes – the testing. You get to test your interface before you spend a fortune building the real thing. You can test it yourself and challenge your concepts or you can work it with a focus group. You cannot underestimate this benefit. Start testing concepts like; should this 3 screen flow be achieved through Ajax? Is it dumb to complete this form through Ajax? Is there too many screens in a sign up process? or is the main focus on the screen a Search Field, but everyone is missing it!?

Wireframe hugely benefit what is done day to day when building the application. With the Its4aCause project, after I completed the wireframes, I was able to pass them over to a designer and basically then prioritise which screens I want them to work on. And I can always come back and make changes within the wireframe and completing the interactive model before building the real screens.

This concept is part of a development model that I use called “Top Down” Development that I will be writing a blog about very soon. Also, the tools of wireframing can either make this task enjoyable or a chore. I will be discussing that in a blog soon too.

So I reached out to a good buddy of mine over at emediacreative. He’s got some great people, and wanted to get him to help me with the logo and brand. Even though I had spent some time working on the logo myself, I was too close to the project and decided that I best leave it to the experts when comping up with the logo

So what I did was spent some time thinking about the brief. And I focused on the image I wanted to portray. And there were two elements to this. Firstly since that the site had a charitable and philanthropic angle, I needed to make sure that came across. But when looking at some comparative sites and logos, the general overtone to these was to be heart wrenching and have an element of sadness. They are trying to get you to donate money I guess.

But I felt that this was wrong for Its4aCause.com. I believe that I wanted to add fun, hope and optimism to the vocabulary. I wanted people to feel good about the web site and what they are doing on it.

And the vocabulary is a good place to start. That is something that EmediaCreative took me though. They helped me identify keywords that described the site and concept. Based on that I had several dozen logos to choose from.

I sat on these logos for about a week and showed a few people.  After getting a few comments back, I narrowed those logos down to 2 I liked that in my opinion, truly represented what the concept was about.

EmediaCreative then went away and provided some alternative concepts and colours for my 2 preferred logos. And after another few days of pondering and sharing the logos around, I came up with my final choice!!!

Who knows, it still may change, but I am happy with it at the moment. I am still pondering on the colours, but I think its the orange and brown that I will go with.

So I have come up with a method that has treated me well over the years, and I have found it to be the most effective and simplest way to get the message across. Firstly, lets clarify what this ‘message’ is. With lots of people getting involved in the project, you need a way to describe what it is about, particularly from the point of view of the user. Once someone sits through your PowerPoint presentation, wireframes or screenshots you want the audience to say “I get it, I see what you are doing” They may have questions – but the questions should actually clarify that they understood. So here is my method.

I use something that is called a Scenario, and this is not anything unique, but I have a very clear method that works for me. A Scenario is a creative writing piece, written in prose. You are writing a story where the “stage” is your web site. And you are describing the most likely path a user(s) would take in your site. It is the 80/20 rule and we are just focusing on the 80 side. Don’t get distracted by the “what about if this happens?” questions, you will deal with them later. Focus on what you WANT the user to do. A Scenario has three main parts; the overview, character introduction, and the Scenario itself.

The Overview

The overview is really straight forward, and it sets the scene. I like to describe what is going to be demonstrated in the scenario. For example, if I were to write an overview for the popular site digg.com (one of my favorites), I would say something like;

“This scenario will show how Oscar has found a news article that he would like to share, and he posts it on digg.com. Mary then comes along and reads the article that Oscar posted, and votes it up by digging it”.

Now, you will probably put a little more detail than that, but you don’t want the overview to be longer than a paragraph. You will notice a couple of important things here. Firstly, I am only concentrating on the core story I want to tell, I am not mentioning digging down, subscribing etc. You may want to mention these things in the body of the Scenario, but only if it is considered part of the core story. The second thing you will notice is that I have introduced real characters. This is important, don’t use names like User1 and User2, use real names as they help people visualize the scenario. This brings us to the second part of the Scenario.

Character Introduction

In the previous section we named a couple of characters, and now you are going to describe them. In this section, you outline all the characters in you scenario and you talk a little about them. Make sure you don’t have too many Characters; I prefer 2-3 and never more than 5. If you have more than 5, your story is too complex and you should consider breaking your scenario out into multiple scenarios. To carry on with our example above, lets see what Oscar’s Introduction might be;

“Oscar is considered a power user of the net. He is a professional in his mid 20’s and spends much of his spare time looking for anything he thinks is exciting on the web. Oscar blogs a fair bit and is on top of technologies such as Twitter and uses his iPhone a lot to communicate with friends”

So in those few sentences we have a pretty good idea of who Oscar is. And we can visualize him and what motivates him. Again, use the 80/20 rule, make sure the character your describing, describes 80% of the users that you think would use the site. There is no point describing Oscar in this way if most of the users of your site are going to be under 18 year old high school students. Also, some people like to give their character a “purpose” of what they are doing on the site – I don’t like doing this, as I use a scenario to describe the options, not to be concrete about what this user is going to do.

The Body

This is where we get into the meat of the Scenario. This is where you are going to start telling a story. Now the format you want to follow here only has 2 rules. First rule is that you need to break out your Scenario into parts if there are clear parts (think scenes in a movie). So from the overview above, there are clearly two parts here; Oscar posting his news item and Mary digging it later on. You may want to add parts for becoming a member on the site as well as commenting or other things that you want to describe. But clearly label the parts as “Part 1″, “Part 2″ etc.

Second rule is that you want to write the scenario in numbered bullet form. Where every process or series of steps is a bullet. So again, continuing with our example;

“PART 1
(some other steps about logging in)
d. Oscar  clicks on the Post Story link. He is taken to a page that describes the process for adding a news story. Oscar pastes the link to the story, provides a title and short description, and clicks on the ‘Post Story’ link.”

Notice that we don’t talk about spell check or other things on this page, as they are just not important yet. You just want to get a clear flow of what the story is, and describe in as much detail as you think is relevant to tell the story. You will find this pretty easy, as you will start to draw a picture in your mind about what this should be and you just describe it.

The only thing that you may want to do in the body of the scenario is add the odd comment that is not part of the core story. Try to avoid this, but if you think that it is important to get certain points across – then do. For example, I usually add technical comments here. If there was a payment processing page; “Need to determine if PayPal will be sufficient or need to process Credit Cards directly”. This is perfectly fine and is a place holder for the future.

What to do now?

OK, now that you have the scenario, you should find that this is adequate to circulate to get feedback from parties on the flow and what the expected user experience should be. You will also notice that a few interesting things happen. The first is when you are writing the scenario, you will certainly hit some hurdles. And these are probably because those aspects of the application are not detailed out as yet. And that is fine. The Scenario is a living document that you can constantly update.

We use Agile as our development methodology. So once I am happy with my Scenario, I usually print a copy off and start going through it and scribble “story cards” out. You will find this real easy to do. You will start to see things like; “User Creates new Article Posting” or “User Diggs story by clicking on vote button” etc. These things not only become blatantly obvious, but there is also traceability. Meaning that they are there for a reason, they were in the Scenario, it was not something that was added for the sake of it.

And don’t stop at one scenario, write a scenario for anything that has a user process, even admin functions, it will help you understand and visualize the end result. And it is a low cost way of doing it and anyone can do it with a few simple guidelines.

The Scenario also gives you the opportunity to start detailing out parts of it. In my example Scenario above, the ability to post an article might be quite complex, but in the Scenario it will be a simple overview. But now you can start discussing, arguing, creating wireframes etc to get the detail out.

So think of the Scenario as your application blueprint, the reason why you build the functionality that you do. And it is also a sanity check. You should be able to go back to your Scenario to see how a feature fits. It may fit and you have to rework your scenario (or create a new one), or you might just say “Why the hell are we adding this!?!?”.

If you are new to this blog, I suggest that you read the typical pre-amble about what this blog is about.

You have a great idea for a new web site, you think its the best thing since sliced bread, you’ve worked out what it needs to do on paper, you’ve worked out the business model and you have some pictures in your head on how it is going to look. But when do you actually start working on the look and feel and get the User Interface (UI) right?

There are two schools of thought here. Some believe that it is best to start working on the functionality and features that you need to develop and then to work out how the UI should present that. Or the other view, that I personally agree with, is that you start visualizing your features in a UI, and let the UI define the details of your features.

Your user is going to have their first interaction with a site through its UI, not its functionality. For example, they will come to your home page and within seconds will decide if they will stay or leave – so it is important to get this right. You will go through many iterations of getting this right, so don’t always think the first thing you do is going to be the right thing. But start on it now!

Home Page Objectives

The first thing I like doing is to write down my objectives for the home page, and here is your first challenge; I like to have ONE clear message on the home page, and I believe that all home pages get this right (even complex portal pages like Yahoo!’s home page clearly says “I am a portal”). So start off with a piece of paper and write down what the home page is supposed to achieve. Is the user supposed to click on a link, perform a search, or provide some input? What is this objective? Then what is the message you want to get across? Be clear not cryptic, remove any vague references, and test, test and further test your message. I can’t stress how important this is.

This is where you get the paper out and start sketching. Make broad strokes first (yes, this is design dude), try and think where the major elements are going to be. But make sure you challenge everything you do. Don’t just put things in because you have seen it before. For example, I was going through this process with a client recently, and the client got up on the white board and plotted out the following elements; logo, main menu, second level menu, and footer. I got up and wiped it all off. They looked stunned. So I asked, what have those elements got to do with the objectives and message? The client couldn’t answer me effectively other than “that’s what all web sites do”. I am not saying that those things won’t be in there, but don’t assume from the start that they are there, or where they will be positioned, as you are just limiting yourself. This client’s home page evolved nicely from then on, we ended up getting it right and the interestingly, there was no need for a second level menu, and the main menu was only brought in at the last minute (as we just didn’t need it), and only had 3 links on it. It was nice and simple and catered for all the user types.

We all know that the home page is critical, because it is your site’s (or business) first impression that counts. Think about it – you have got about 5 seconds of a visitor’s attention before they either click away or go deeper. Generally, if a user goes deeper, it is reasonably likely that they will go just beyond one page. So in the first 5 seconds, you need to get your user to say to themselves “I understand and I would like to know more”. That is why you need to continue to test, and hope that you are not too precious about your views – because expect to have them shattered.

Think about interactions early on

But UI is more than just home page. I don’t care if you are building a web brochure, rich website or web application, your UI is what your user is interacting with, so simplify. We have seen a trend with all the latest Web 2.0 sites where they are removing the ‘fluff’ in the UI that we have seen with the older dot com UIs. Thank God for that!!! Something that used to drive me crazy was when web sites used to plaster links all over the page just because they could. It was counter productive, no body clicked on those links. Think about it; even on your favorite most popular sites that you visited, think about the links that you click on. For example, I use eBay a lot, and here is a site that has a lot of links – but they have improved on it over the years. Even though there are probably over a hundred actions on a product listing page, I usually only click on 2-3, that’s it; “Watch This Item”, “Bid Now” and the seller’s profile. I would occasionally click on other links like seller’s other items – but rarely.

But eBay didn’t start at this point, they evolved to this point based on their customer’s usage patterns and requests. The key is not try and pre-empt all your user’s possible actions, because you just can’t. You don’t know how your users are possibly going to use your site. The only thing that you know is how you would like your visitors to use your site.

So there you have it, unfortunately not too much details about the actual UI, but that is not what this post is about. It is about thinking about the UI early on. Another important aspect that I use a lot, is the “Scenario”, and this is an process that leads on from what I said above about how you would like to have the user behave on the site. That is going to be my next posting.