
Creating buttons is something every web designer deals with, usually on a very regular basis. It can be one of those tasks that becomes tedious and repetitive but with a few tricks you can make pleasing looking buttons that also give the visitor useful feedback and navigational consistency. In this article I’ll be talking about buttons with 3 states – normal, hover, and pressed – and I will be using the sprite based method which places all 3 states in the same image file.
Achieving the right graphical look is important so that you are able to present your design in the manner you desire – be it rational UI or crazy mystery meat navigation. It’s important to have your choices look deliberate and not haphazardly chosen – it will help you when presenting to the client and in the final UI users will interact with.
Photoshop’s shape tool is a quirky thing with a couple important options to understand before you start working. First there is the choice between creating a vector-based “Shape Layer” or a pixel based “Fill pixels” option. In a nutshell the vector option is versatile but clunky and the pixel option is less flexible (especially when you want to modify the shape later) but it acts predictably in the pixel world. I use pixels simply because the vector tool can be a pain.
Of equal importance is the “snap to pixels” option which is accessible from the hidden menu at the end of the shape option bar (see fig. 2, step 1) when you are using the rounded corner shape. This will prevent your shapes from displaying unpredictable antialiasing which becomes very important as you duplicate shapes and specify heights and widths in CSS. Also make certain if you’re created a rounded corner shape to turn anti-aliaising on (fig. 2, step 3).
(fig. 2)

Now you can create shapes! Choose a radius for your rounded corners and you’re ready to go.
Button styles have been evolving as long as the web has and there are an infinite number of styles you could use but I am going to demonstrate a sensible approach that is universal and not heavy on character. The following are tips on using Photoshop’s Layer Styles to create a button like the ones used in the examples.
These are your basic settings for the “normal” state. For the hover state alter the gradient overlay and lighten both colors. The “pressed” state requires a few new styles and a couple adjustments to get that indented look.
The 3 states of the button are contained in one image so you will use the background-position CSS attribute to control which states are shown for normal, hover and active states. This method is known as sprites and there are many great resources on it. The primary benefit is since all 3 states of the image are loaded in the same file there is no additional loading on hover and active states. The CSS for changing the background image would look something like this:
#bee_button a {
display: block;
text-indent: -5000px;
width: 136px;
height: 41px;
background-image: url(/images/bee_button.png);
background-repeat: no-repeat;
}
#bee_button a {background-position: 0 0;}
#bee_button a:hover {background-position: 0 -41px;}
#bee button a:active {background-position: 0 -82px;}

You can see buttons like these in action on the Widgetfinger home page and inside both Hoptoad and Thunder Thimble. They provide a tactile experience for the user and an extra bit of visual feedback when a button has been clicked.

Kelly Johnson worked at and was one of the driving forces behind Lockheed Martin’s Skunk Works group. As part of an upcoming project management book I’ve been writing (it’s called “SWARM”, is meant for managers of small teams of software developers, and has a picture of bees on the cover), I’ve been reading up and thinking about the business processes which are in place at technology-but-not-software business, including the Skunk Works.
Aside from the success the team had building aircraft, I think they were rather innovative in their organizational management as well, and I was inspired to write this post when I ran into this gem – Kelly’s 14 Rules.
Reading over this list, I think that Lockheed’s Skunk Works might be the agile developers of the aerospace defense world—from 60 years ago. I’ve reproduced the list here with an identification of a modern software development rule or business practice that it corresponds to..
| Rule | Skunk Works | Comment |
| 1 | The Skunk Works® manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher. | When we bid on a project for clients we explain that they are hiring us for a purpose and because of our expertise. As a result: the more control they can give us, the better the solution that we deliver. |
| 2 | Strong but small project offices must be provided both by the military and industry. | We have yet to do military work, but we do send people on site, and when we can get them in a small group with the client stakeholders, a lot can happen. |
| 3 | The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems). | Too many cooks ruin the soup, and too many developers or managers ruin the software. A small talented team will consistently out-produce an “average team” many times it’s size. |
| 4 | A very simple drawing and drawing release system with great flexibility for making changes must be provided. | Design driven development, with rapid iteration. |
| 5 | There must be a minimum number of reports required, but important work must be recorded thoroughly. | Invoice based on trust, not paragraph-long line items. Comment code only when it’s crucial to a future developer trying to understand the problem. |
| 6 | There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don’t have the books ninety days late and don’t surprise the customer with sudden overruns. | Always keep the next milestone in sight, and always review whether you’re still focusing on the larger business goal of the project. Don’t spent 40% of development time and money on a feature used by 1% of the audience. |
| 7 | The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones. | We’ve gone one step further here – and we refuse to subcontract for another vendor, or to hire a subcontractor when we’re the primary vendor (we’ve learned our lesson on both fronts). Commercial bids are almost always better than non-profit bids (including those for government or quasi-government entities) |
| 8 | The inspection system as currently used by the Skunk Works®, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don’t duplicate so much inspection. | We attempt to maintain a set of code quality standards and development best practices which are literally the best in the industry. We want to consistently exceed, by a large margin, any standards or policies that a client has in place. |
| 9 | The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles. | You must have a staging server that accurately represents the production server. If you don’t maintain your test suite, you cannot work with confidence as change requests come in. |
| 10 | The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works® practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended. | Implementation doesn’t start until design is done. Design doesn’t start until a contract is signed. A contract isn’t signed until the spec is done. |
| 11 | Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects. | Work on a milestone never begins if there is a past due outstanding invoice. |
| 12 | There must be mutual trust between the military project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum. | Communication failures kill projects. Daily “scrum style” meetings, or at least regular communication via an online tool is absolutely critical to project success. |
| 13 | Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures. | Honor your NDAs. |
| 14 | Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised. | Hours worked, meetings held and emails sent are not metrics for success. Quality produced, milestones completed, and profit made are. |
Finally, according to wikipedia, there’s an unwritten-but-sometimes-spoken 15th rule…
Starve before doing business with the damned Navy. They don’t know what the hell they want and will drive you up a wall before they break either your heart or a more exposed part of your anatomy.
I’ll leave that one as an exercise for any reader who has done client work to negotiate for themselves.