Avoid Edge Cases by Designing Up Front

by Ben Henick

17 Reader Comments

Back to the Article
  1. Great article. It rehashes much of the stuff I learned in project managing. I have to agree with Zack here and say that the process described is great for larger firms. Although usability testing does not have to break the bank (see Jakob Nielsen’s articles), it’s often a non-issue for smaller businesses.

    From my experiences in large organizations, it’s incredibly important for designing and re-designing that there is an overall project manager with enough authority to keep designers, engineers and higher powers (management, shareholders) in line. Engineers, as well as designers tend to run away with things. Even worse, designers are often confronted with completed (read: half baked) designs made by engineers and vice versa.

    Indeed, the approach you described could elimate a lot of problems. But you have to have all the parties (and stakeholders) on board from a very early stage as well as a project manager who has the authority and tools to lead a project.

    Copy & paste the code below to embed this comment.
  2. You might keep an eye on what “D. Keith Robinson”:http://www.dkeithrobinson.com/ is writing – he’s planning to take a wallop at the material from a project management perspective…

    Copy & paste the code below to embed this comment.
  3. I think most web design businesses get into trouble because the conceptual framework to which they view a website is flawed. I website is not a poster, it is a richly styled interface. Any project manager who prioritises a graphic designer’s input over the programmer’s tasks is headed for disaster and probable unemployment.

    The simple truth about website design is: after half an hour of using a website, unless there are serious contrast, layout or typography issues, no-one cares how it looks. All folks care about is site structure and content.

    From my point of view there are basically two ways to develop a website.

    1. Pulled out of your template stack to be styled, content filled and published.

    2. Developed as software using components from your application library to be added onto an expandable architecture designed using the project’s scope.

    While No.1 is quick and dirty for those budget projects, No.2 will guarrentee for your client their website’s economic maintainance and upgradablility indefinately into the future. And, when I say developed as software, I’m talking about no static markup whatsoever even if the website itself is to be published as a static one.

    Finally, two quick points;
    -The choice to develop for browser compatability does not exist for the professional website designer.
    -Development for grandma is priority in an ecommerce site as baby boomers hold the majority of wealth in the world today.

    Copy & paste the code below to embed this comment.
  4. Your assertion that people don’t care what it looks like is one to be taken with a grain of salt.  Given two competitors, the one with the more-usable site will win; that factor being equal, the one with the more-attractive site will win.

    “Good will”:http://dictionary.reference.com/search?q=good+will counts for something, sometimes a lot, and acquiring it is cheap in terms of return on investment.  Meanwhile, people miss that point because the development of good will is all capital investment, all the time – in the form of better-trained CSR’s, excellent designers, more-skilled project managers, and all of the overhead those talents require.  A stakeholder on a cost-cutting mission won’t go there, because the payback develops over time and is difficult-to-impossible to measure.

    At the same time, there are teams that have ineffective project management, and the stakeholder winds up smiling, nodding, and signing off on the engineers’ work – no matter how craptacular it may be with regard to usability – because he doesn’t know any better.

    There are two extremes to the problem.  I ignored the extreme at the engineering end of the scale because it was out of scope – I was following up on a well-defined problem laid out in my previous article.

    Meanwhile…

    Obviously, a place like Amazon needs to hew to the LCD.  ThinkGeek does not.  This is simply one of the more stark contrasts, but there are others like it.

    “E-commerce needs to be usable by everyone” is not automatically a true statement.

    That said, there are usability concepts in e-commerce that benefit all potential users:

    1. Minimize steps and obstacles between the start of the session and the purchase.  (Yes, this can be done across multiple user objectives and session scenarios.)
    2. Ensure that the visitor’s shopping cart is visible at all times.
    3. Allow removals and additions to be conducted with a mouse alone.
    4. Respect the customer’s intelligence, but don’t assume they’re a genius, either.
    5. Ensure that all content is quickly legible, within reason (a subnotebook such as the machine on which I’m writing this comment can easily be declared an edge case, for example).

    These are not respected without attention to specific aspects of user experience; template-filling, this is not!

    Copy & paste the code below to embed this comment.
  5. We’re a small shop (three people) but are taking all of January off to build our own internal project management system. We’ve spent a year developing the ideas (many of them mirrored in the article and your comments.) Why? Well, we figured that as a small shop we needed the ability to scale up the work we did (so we could make more cash, obviously,) but found that the more jobs we took on, the more time we spent on the phone dealing with irate customers.

    Man, we all know the cliche – work smarter, not harder – and that’s what it’s about. Systemised workflow is gold for small businesses – it puts us on a more even footing with our bigger competitors.

    I also respect the comments about authority – although in our case, because our jobs are at the smaller end of the scale and developed using a more intimate process than larger firms, it’s as important to maintain some sort of authority over the client. Our biggest workflow problems are in keeping clients to our tight development schedules.

    As an aside, I find point four above hard to accept. Oh, and our process is always iterative :P

    Copy & paste the code below to embed this comment.
  6. Hi Ben! Thanks for reading the article translation! I´d appreciate your help, but I think we really can´t translate your exact idea on that topic to Portuguese. That´s why I tried to translate de idea instead of the lyteral words.

    Contact me for anything!

    Copy & paste the code below to embed this comment.
  7. I work on “LUDO”:http://www.ludo.com.uy , a small design studio in Uruguay. We produce multimedia web-based applications.
    Last semester, we have been working on a web product which consists of a limited backend to manage personal work, aimed at artists and graphic professionals, while the frontend is totally customizable, adapted to the client’s identity.
    We are a four-member team; and at first glance, we estimated a three-month work for the completion of the project.
    Nop.
    We are still testing and correcting it.
    I (we) should have read your article earlier, in order to realize that no matter how small a project could be, the same cutbacks would keep on coming.
    Even if the time spent planning the project takes more than expected, it will surely save future cutbacks in the production process, because any project has them, and we all know they are unpleasant.

    Copy & paste the code below to embed this comment.