- Accidental Creative
- Adapting to Web Standards: CSS and Ajax for Big Sites
- Art of Non-Conformity
- Art of Readable Code
- Back to the User: Creating User-Focused Web Sites
- Beginning PHP6, Apache, MySQL Web Development
- Books to Read
- Born For This
- Complete E-Commerce Book
- Core PHP Programming
- CSS3: Pushing the Limits
- Dealing with Difficult People
- Defensive Design for the Web
- Deliver First Class Web sites
- Design for Hackers: Reverse-Engineering Beauty
- Designing Web Interfaces
- Designing Web sites that Work: Usability for the Web
- Designing with Progressive Enhancement
- Developing Large Web Applications
- Eat That Frog
- Economics of Software Quality
- Elements of User Experience
- Extending Bootstrap
- Flexible Web Design
- Flexible Web Layouts
- jQuery Pocket Reference
- Letting Go of the Words
- Manage Your Day to Day
- Official Ubuntu Book
- Organized Home
- PHP In a NutShell
- PHP Refactoring
- PHP5 CMS Framework Development
- PHP6 and MySQL Bible
- Responsive Web Design
- Responsive Web Design with HTML and CSS3
- Rules of Thumb
- Saleable Software
- Securing PHP Web Applications
- Seed Underground
- Simple and Usable Web, Mobile and Interaction Design
- Smart Organizing
- Submit Now: Designing Persuasive Web sites
- The Life-changing Magic of Tidying up
- Web site Usability
- Web Site Usability: A Designer's Guide
- Web Word Wizardy
- Work for Money, Design for Love
Minding Your Users
The practice of creating engaging, efficient user experiences is called user-centered design. The concept of user-centered design is very simple: Take the user into account every step of the way as you develop your product. The implications of this simple concept, however, are surprisingly complex.
Everything the user experiences should be the result of a conscious decision on your part. Realistically, you might have to make a compromise here and there because of the time or expense involved in creating a better solution. But a user-centered design process ensures that those compromises don’t happen by accident. By thinking about the user experience, breaking it down into its component elements, and looking at it from several perspectives, you can ensure that you know all the ramifications of your decisions.
The biggest reason user experience should matter to you is that it matters to your users. If you don’t provide them with a positive experience, they won’t use your product. And without users, all you’ve got is a dusty Web server (or warehouse full of products) somewhere, idly waiting to fulfill a request that will never come. For the users who do come, you must set out to provide them with an experience that is cohesive, intuitive, and maybe even pleasurable—an experience in which everything works the way it should. No matter how the rest of their day has gone.
Defining the Strategy
The most common reason for the failure of a Web site is not technology. It’s not user experience either. Web sites most often fail because - before the first line of code was written, the first pixel was pushed, or the first server was installed - nobody bothered to answer two very basic questions:
What do we want to get out of this product?
- What do our users want to get out of it?
By answering the first question, we describe the product objectives coming from inside the organization. The second question addresses user needs, objectives imposed on the product from outside. Together, product objectives and user needs form the strategy plane, the foundation for every decision in our process as we design the user experience. Yet, amazingly, many user experience projects do not begin with a clear, explicit understanding of the underlying strategy.
The key word here is explicit. The more clearly we can articulate exactly what we want, and exactly what others want from us, the more precisely we can adjust our choices to meet these goals.
If it involves providing users with the ability to go places, it’s navigation design. The information architecture applied a structure to the content requirements we developed; the navigation design is the lens through which the user can see that structure, and is the means by which the user can move through it.
There are two main reasons to bother to define requirements.
Reason #1: So You Know What You’re Building
Reason #2: So You Know What You’re Not Building
by Jesse James Garrett
These are notes I made after reading this book. See more book notes
Just to let you know, this page was last updated Wednesday, Mar 21 18