Constructing the testing pyramid

I like Mike Cohn's testing pyramid as a guideline for test allocation, and I've mentioned it to a couple of teams around here (for more, read Patrick Wilson-Welsh's blog and/or see his Agile 2008 presentation). Lately, on one team, we've been very earnest about writing Selenium tests for UATs, even doing some ATDD. But we're seeing what many have seen: Selenium tests are often (necessarily) long and slow, and occasionally brittle. I asked the team what our "testing pyramid" would look like, and it's something like this:

          ^^^^^^^^^^^^    (GUI/system)
           ^^^^^^^^^^     (functional)
        ^^^^^^^^^^^^^^^^^ (unit)

That is, the majority of our tests are at the unit level (that's good), but we are top-heavy with GUI tests. So with the help of the Ace team, we're moving toward more under-the-GUI integration tests using Webrat. Now we're looking more like:

          ^^^^^^^^^^^^    (GUI/system)
              ^^^^        (integration)
           ^^^^^^^^^^     (functional)
        ^^^^^^^^^^^^^^^^^ (unit)

The goal is to convert some of those Selenium (GUI/system) tests to Webrat (integration) and get our pyramid more in line (and help our team be more productive). There's still obviously need for the GUI-system tests, but we're just trying to be smarter about it.