UI logo
The Webzine for Interaction Designers
uidesign.net
 
     
 
  Site Search

Advanced Search
 
  Subscribe
Receive site update email alerts.
Enter your email address.
 
  Resources
Recommended Books
Links
 
  Site Info
Update Notification
Send Feedback
FAQ
Copyright/Link Policy
Review Scoring
Site Goals
About us
 
 
January 7th, 2000
     
 

Site Redesign
Part 1 : Gathering Requirements

 
     
  Introduction  
  After one year of running uidesign.net, I was aware that the original design though functional was looking tired. It was also failing to meet the requirements and expectations of Users and Owner to a sufficient degree. I was also acutely aware that if you are going to preach or teach then you need to lead by example. You have to walk-the-walk as well as talk-the-talk.

Actually, the design of the site has remained far from static over the first 12 months. As the quantity of material has grown, the site design has had to grow with it. It became obvious very early that the initial directory structure just wasn't going to cope with the growth of site. The original premise of "publish a few white papers" had been outgrown. This lack of foresight cost. Many of you still come by the site from Search Engines which have archived those early original links.

So the directory structure changed after 3 months. The original navigation space underwent subtle change too, as it became evident where the focus of the site was and the areas that I was able to develop. The PartsBin section for example got nowhere. Partly because I wasn't doing real work in that area and partly because the readership didn't show an interest in it either.

The other big area of change was the front page. Originally, I had envisioned Users coming to read from the archive. For them it was enough to select Books, or White Papers, then select the article that they wanted to read. However, I completely missed the regular monthly visitor who wanted to know, "what's new this month". The addition of the "This Month" section on the front page, solved this problem and became immediately popular. It was joined shortly afterwards by the "Updated on" status indicator and later still by dates on many of the articles.

Looking back many of the faults could have been avoided, partly if I had done the requirements better and partly if I had previous periodical publishing experience.

So there were many faults in the initial design in terms of navigation and usability. The other side of it was the lack of graphic design. This was a necessary constraint in order to get the site up-and-running and the initial material published but it was never intended to last forever.

So conveniently after 12 months, it is time for a redesign. A new look and new navigation. Such a change is good because it regenerates interest in the site, and gets people thinking about how it looks, how it works, why it is that way and not some other way.

The problem is "where do you start?" With the Requirements!

 

 
  Requirements  
 

The requirements for the site are driven by two groups: the site owner (that's me!); and the site visitors (that's you!). The Visitors actually fall into several groups or types of which more later.

Owner's required functionality

The owner's requirements are that the site should be interesting to a diverse group of visitors who share some interest in the field of Interaction and User Interface Design. Such that the content will be read and improved software design will ultimately result in improved user experience with software technology. The site should facilitate the publishing of periodical material, formal "how to" papers, editorial comment - opinion or advice, feedback from readers and other useful related material such as book reviews and resources for Interaction Designers or User Interface Designers.

Owner's preferences

The site should teach by example. It should demonstrate many "best of breed" examples of good Interaction Design including good navigation, good usability, ease of use, good visual communication. It should generate interest and it should promote itself and the Owner (this is the hidden agenda - there is always at least one in the requirements and it's important to find it, to know it and to understand it). It should also encourage more frequent return visits to the site.

It should also be fast to load and make effective use of lightweight graphics.

Naturally, there is some vagueness is these definitions and if I were doing this with someone else then I would have them define the parameters. What exactly does "fast to load" mean?

Owner's constraints

The site has to be maintained using low cost tools and pages must be easy to compose as all the work on the site is done during precious recreation time. It must also continue to work effectively on the likk.net server. uidesign.net does not generate any revenue and it is essential that it can continue to be hosted at no cost to the owner.

The redesign must be completed on a low budget and with a minimal amount of time. Time spent redesigning is time lost to development of content. A modest budget is available in both time and resources. This cannot reasonably be exceeded by order of the Owner's spouse :-)

 

 
 
Related Articles
Most Recent
Most Popular
 
  Site Search

Advanced Search
 
User and Goal Analysis
  So we have the Owner's functional requirements, the desired preferences and the constraints within which the final design must exist. Over the last year at the site, there have been several techniques discussed in book reviews. So now it's time to put it into practice.

First we need to take a look at who uses the site. How do we get that information?

Well we have access to the site logs. That tells us the IP names of machines visiting the site and we also know what pages are being read and when. In some cases we know whether they arrive from Search engines and we know whether they come in by the front door. However, this actually tells us very little about the User or their Goals.

We also have the direct feedback from email. Surely this is a great help. Well yes and no. We must ask whether the emailers truly represent the community who visit the site. They are the minority. It's the silent majority that are of real interest. The emailers fall into two neat categories: those whom I know personally or professionally; and those who come in with 101 type questions and go away never to be heard of again. So email correspondence was not the answer.

The answer lay with Personas [Cooper 99] (aka User Profiles [Fleming 99]). So I decided to develop some. For each Persona definition, we can look at the goals that Persona might have.

Walter, an HF/HCI post-grad student

Walter has only worked in industry for one summer internship. He didn't get any real work to do or it was only hacking C++ code for some back end interface. He is currently doing his literature review and has turned to usenet and deja.com for suggestions. He found uidesign.net through a link from my tagline.

Walter needs to find material that can be classified as "State of the Art" and he needs to know if he's missing anything. He finds the book reviews (or at least some of them) useful. He browses the White Papers and cherry picks those with novel Interaction material.

Diane, an Undergrad CS student with a term paper on HCI to submit by Friday

Diane is having a lousy year. Her boyfriend is cheating on her, her allowance is almost done for this month, her roommates are real messy and her pet cat got sick. She works evenings to supplement her allowance and parties when she is not working. She doesn't have time to do homework. Term papers have to be thrown together over lunch, just before their due date.

Diane hits uidesign.net from AltaVista search engine. She arrives on a book review but really needs a White Paper to plagiarise. She needs to see a list of available papers and get a quick grasp of the content. She selects a paper, saves it to disk and starts editing.

Later Diane's lecturer recognises that the work can't possibly be her own but he isn't too sure where it came from.

Gary, Windows GUI Developer in a big Insurance Firm's IT Division

Gary stands out from his immediate colleagues as a visionary. Someone who cares a little bit more than simply when his paycheck will arrive. Gary wants to do a better job. He knows his boss is related to Dilbert's boss and the only way the department's output will improve is if he makes it happen in his own time. He reads a few web sites periodically and tries to improve his knowledge. He doesn't have time to read books but he does own a few weighty tombs on Windows APIs which he references when required. Currently, Gary doesn't know much about UML but he is keen to learn that too. It might just be his passport to a better position elsewhere. Gary found UIDesign.net from usenet. Gary bookmarked the links page. He passes through occasionally looking for other sites.

Gary needs to read stuff which makes his job easier. He wants advice on menus, grouping fields, code construction, notification mechanisms, advice on when to use a widget and what alternatives there might be. He needs to know stuff about APIs and stuff about UML and software development processes. He comes in by the links page, occassionally he might stay but more often he just wants to choose a link and surf off somewhere else.

Graham, Program Manager at esiteforyou.com

Graham graduated in Art and Communication. His hobby interest in Graphic Design and his Apple Mac experience, got him a job as a Graphic Artist at esiteforyou.com while it was still a small startup called Design Partners. The sudden explosion in eCommerce and the change in the business name saw huge growth and VC investors. Graham is now head of a whole eCommerce web team. He still knows a lot about Graphic Design but is out of his depth in many other areas of design and software development. He found uidesign.net from a Search Engine and bookmarked it. He visits occasionally as he does several other sites. His interest is in improved usability and better design.

Graham needs to see what's new. If something interests him then he may choose to read it, otherwise he doesn't want his time wasted and will move on to something else somewhere else.

 

 
 
Summary
 
 

So we now have a pretty detailed idea of the requirement. We know what functionality the owner requires and what other features would be nice to have. We have preferences and constraints. We also have a sufficient sample of the User Base and an idea of their motivations for visiting and their goals. This User and Goal Analysis is not exhaustive. It's obvious from the Persona descriptions that there is significant overlap between required functionality and content across the personas. If we build the site for those 4 Personas then we will actually cater to a much greater, wider audience.

 

In Part 2 of Site Redesign, we will look at Analysis. From the Requirements we will analyse the problems for the site design. Finally in Part 3, we will present the Design Solution to those problems.

 

Do you have any comments about this paper? Would you like to add a Persona to the set above? Didn't recognise yourself? Please send feedback to mailto:david@uidesign.net

 

References:

[Weinberg 89] Exploring Requirements: Quality Before Design, Gauss & Weinberg, Dorset House 1989

[Fleming 99] Web Navigation, Jennifer Fleming, O'Reilly, 1999

[Cooper 99] The Inmates are Running the Asylum, Alan Cooper, Sams, 1999

 

 
   
  Comment on this article...  
   
Most Recent
Related Articles
uidesign.net
hosted by likk.net
           
 
Copyright uidesign.net, 1999 - 2003.
The UI logo device and uidesign.net wordmark are trademarks of uidesign.net