Avoid Edge Cases by Designing Up Front

by Ben Henick

17 Reader Comments

Back to the Article
  1. I’m more a software developer than a website designer. In software development we moved from a sequential process (waterfall) to iterative processes many years ago. If projects get more and more complex you simply cannot design everything up front. So you make several iterations of design and implementation, everytime improving quality and also your knowledge about the specific project needs and circumstances.
    So your approach is better than a chaotic one, but for complex sites I would suggest to go iterative.

    Copy & paste the code below to embed this comment.
  2. Andy, you cannot compare a software development projekt with a website. Web designers are creative people, software developers are nerds. So with those different kind of people you want to run the same process? Never ever…

    Copy & paste the code below to embed this comment.
  3. (@Jochen: Not to go too off-topic, but creative people are found in every walk of life, and in every position, including software development. That’s too broad a brush to be painting with…)

    For me, this article made good sense, and seemed like a relatively painless, even fun way to get websites done… in my dreams.

    I truly do wish most shops knocked out projects like this. But I’ve never seen it.

    So does the author have examples of sites that happened under this utopian process, that I may gaze longingly at the fruitful result of their workflows?

    Gotta go – the latest edge case awaits.

    Copy & paste the code below to embed this comment.
  4. Since the best part of my energy here was aimed at web designers and project managers, I deliberately chose not to discuss my ideas in a waterfall-vs.-iterative context.  Sorry, but the instant I start jabbering about software engineering, nearly every single art-school-trained reader will tune out.  That’s the last thing I want.

    However, I also figured that it would be a matter of time before it came time to bring it up in the comments – in this case, on the first page.

    Web projects are going to require a bastardization (in whatever proportions) of the two methods – at once you have project sponsors who often need their documentation delivered at the Dr. Seuss level, while again you’re working with tools that lend themselves quite well to iterative development.

    The idea is not to throw iterative development into the dustbin, but to catch the gotchas that would otherwise increase the time between iterations.

    If I could start over from scratch with the article, I’d’ve probably given examples of the sorts of edge cases at issue – “the sidebars in this section need to have 10px of padding, but the sidebars in that section need to have 12px of padding” would be a good one.  It’s best to catch those early in planning and/or iteration, rather than later.  In my opinion, The ground rules needed to make those catches are established with – you guessed it! – wireframes and a formally normative style guide.

    Copy & paste the code below to embed this comment.
  5. Do you feel that the ideas presented in this artice are realistic, or pie-in-the-sky?

    What anecdotally common dynamics or personal experience can you share to substantiate your answer?

    Copy & paste the code below to embed this comment.
  6. While the proposed process is very well put together, and great for larger firms with big clients, I currently design mostly for small and medium sized businesses who are not interested in extensive user testing and usability reports.  They also are generally unwilling to incur the extra cost that is associated with a longer process. In your article, you mention that it may not be suitable for smaller sites, which is mostly true.

    On a larger site, I think it is valuable and reasonable to expect the level of detail you call for.  There’s a book that is out that lays out a very similar process, called “Web Redesign 2.0: Workflow that Works”:“http://www.web-redesign.com” . It certainly helped me understand a thorough design, development, and documentation process (with helpful screenshots).

    Overall, your article is a very helpful resource, thank you!

    Copy & paste the code below to embed this comment.
  7. Here’s a working link to the book I mentioned: “Web Redesign 2.0: Workflow that Works”:http://www.web-redesign.com/

    Copy & paste the code below to embed this comment.
  8. I think a sequential process for website development is not realistic, since your customer has to LIKE the website you are building. Website building is not a technical and graphical issue alone, it’s also a kind of art. And the website developer will develop some thing that the customer does like and some others that he does not like. So once you get feedback from your customer you’ll have to take some steps back and redefine your previous results.

    Copy & paste the code below to embed this comment.
  9. Dieter, I think the process described in the article is for helping the website developer focus on his own work. Of course there will be customer feedback, but that’s at the end of the process, not after every single step.

    Copy & paste the code below to embed this comment.
  10. Loved the way you broke it down and made it so simple anyone could understand project assessment thanks for the great read.

    Copy & paste the code below to embed this comment.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.