Usability isn't necessarily a new term, but when it comes to how users interact with the Web, it takes on a whole new meaning. Web usability is evolving as we learn more and more about how our users interact with our online information, how they retrieve it and use it, how they want to move on our site, what they anticipate and what they expect within the realm of their experience.
The term 'usability' has historically involved testing how users actually get on a system and use it. With Web usability, I prefer to take it one step further and think of it in terms of how a user gets on a Web page and a) anticipates how to interact with it and b) actually interacts with it. This anticipation is what we need to test for along with use; it's the intuition and the logic involved in the Web experience that differentiates Web usability from other types of usability. Failing to rethink our approach to usability predisposes us to either success or failure—I don't know about you, but I prefer the success path. Web users are a fickle group; let's face it, if you don't anticipate what they want, give them what they want, how they want it and when they want it, you can forget the bookmark; they're not returning.
Think of Web usability as a 'pay now or pay later' proposition. If you don't check in with users early in the development process, you run the risk that you won't meet their needs when you launch the site. When you realize their needs haven't been met, you have to go back and rethink your whole approach, rehire the web developers and get them refocused on the project so they can redevelop the site. The terms, 'rethink', 'rehire', 'refocus' and 'redevelop' should be conjuring up visions of dollar signs for you, not to mention the fact that your brand, image and credibility were damaged in the process of launching a site users weren't able to use.
Testing for usability is a choice, not a requirement, and it is often the first step in the development process that management will scratch if time is running short. The next time you approach your web project, consider using the web usability strategy I developed to understand the scope of testing usability, how you could easily administer a test session, who you should test and what you want to test for. It may be less burdensome than you think!
Tuesday 19 June 2007
Sunday 17 June 2007
Developing a new website - Planning
THE FIRST STEP in designing any Web site is to define your goals. Without a clearly stated mission and objectives the project will drift, bog down, or continue past an appropriate endpoint. Careful planning and a clear purpose are the keys to success in building Web sites, particularly when you are working as part of a development team.
Planning a Web site is a two-part process: first you gather your development partners, analyze your needs and goals, and work through the development process outlined here to refine your plans. The second part is creating a site specification document that details what you intend to do and why, what technology and content you'll need, how long the process will take, what you will spend to do it, and how you will assess the results of your efforts. The site specification document is crucial to creating a successful site, as it is both the blueprint for your process and the touchstone you'll use to keep the project focused on your agreed goals and deliverables.
Web sites are developed by groups of people to meet the needs of other groups of people. Unfortunately, Web projects are often approached as a "technology problem," and projects are colored from the beginning by enthusiasms for particular Web techniques or browser plug-ins (Flash, digital media, XML, databases, etc.), not by real human or business needs. People are the key to successful Web projects. To create a substantial site you'll need content experts, writers, information architects, graphic designers, technical experts, and a producer or committee chair responsible for seeing the project to completion. If your site is successful it will have to be genuinely useful to your target audience, meeting their needs and expectations without being too hard to use.
Although the people who will actually use your site will determine whether the project is a success, ironically, those very users are the people least likely to be present and involved when your site is designed and built. Remember that the site development team should always function as an active, committed advocate for the users and their needs. Experienced committee warriors may be skeptical here: these are fine sentiments, but can you really do this in the face of management pressures, budget limitations, and divergent stakeholder interests? Yes, you can — because you have no choice if you really want your Web project to succeed. If you listen only to management directives, keep the process sealed tightly within your development team, and dictate to imagined users what the team imagines is best for them, be prepared for failure. Involve real users, listen and respond to what they say, test your designs with them, and keep the site easy to use, and the project will be a success.
Planning a Web site is a two-part process: first you gather your development partners, analyze your needs and goals, and work through the development process outlined here to refine your plans. The second part is creating a site specification document that details what you intend to do and why, what technology and content you'll need, how long the process will take, what you will spend to do it, and how you will assess the results of your efforts. The site specification document is crucial to creating a successful site, as it is both the blueprint for your process and the touchstone you'll use to keep the project focused on your agreed goals and deliverables.
Web sites are developed by groups of people to meet the needs of other groups of people. Unfortunately, Web projects are often approached as a "technology problem," and projects are colored from the beginning by enthusiasms for particular Web techniques or browser plug-ins (Flash, digital media, XML, databases, etc.), not by real human or business needs. People are the key to successful Web projects. To create a substantial site you'll need content experts, writers, information architects, graphic designers, technical experts, and a producer or committee chair responsible for seeing the project to completion. If your site is successful it will have to be genuinely useful to your target audience, meeting their needs and expectations without being too hard to use.
Although the people who will actually use your site will determine whether the project is a success, ironically, those very users are the people least likely to be present and involved when your site is designed and built. Remember that the site development team should always function as an active, committed advocate for the users and their needs. Experienced committee warriors may be skeptical here: these are fine sentiments, but can you really do this in the face of management pressures, budget limitations, and divergent stakeholder interests? Yes, you can — because you have no choice if you really want your Web project to succeed. If you listen only to management directives, keep the process sealed tightly within your development team, and dictate to imagined users what the team imagines is best for them, be prepared for failure. Involve real users, listen and respond to what they say, test your designs with them, and keep the site easy to use, and the project will be a success.
Thursday 14 June 2007
Now Available: Microsoft eScrum Version 1.0
If you're looking for another Scrum template to try with Team Foundation Server, consider using eScrum, which is an implementation of Scrum that's used internally by some teams within Microsoft:
"eScrum is a Web-based, end-to-end project management tool for Scrum built on the Microsoft Visual Studio Team Foundation Server platform. It provides multiple ways to interact with your Scrum project: eScrum Web-based UI, Team Explorer, and Excel or Project, via Team Foundation Office Integration. In addition, it provides a single place for all Scrum artifacts such as product backlog, sprint backlog, task management, retrospective, and reports with built-in context sensitive help."
"eScrum is a Web-based, end-to-end project management tool for Scrum built on the Microsoft Visual Studio Team Foundation Server platform. It provides multiple ways to interact with your Scrum project: eScrum Web-based UI, Team Explorer, and Excel or Project, via Team Foundation Office Integration. In addition, it provides a single place for all Scrum artifacts such as product backlog, sprint backlog, task management, retrospective, and reports with built-in context sensitive help."
Source: Download details: Microsoft eScrum Version 1.0
In addition, take a look at the VSTS Scrum Process Template on CodePlex, which is under the guidance of several Team System MVPs.
First Post
This will be my first post starting the blog for the website and web development projects I will undertake as part of the team at Carnival Media Group. Over the coming weeks and months I hope to cover topics such as programming and development for websites, databases, SEO, e-commerce, shopping carts, custom solutions, new techology and ASP.NET tips, tricks and other information.
I hope this can be a fun an interesting blog about my role in the company and new and any interesting development we are doing.
I would also like this to be an area for me to give my opinion on web development techniques and new directions in the web development field!
I hope this can be a fun an interesting blog about my role in the company and new and any interesting development we are doing.
I would also like this to be an area for me to give my opinion on web development techniques and new directions in the web development field!
Subscribe to:
Posts (Atom)
