I hate to be the type of person who says, "It depends" - but, it depends.
I tend to divide things between project-specific concepts and generic concepts. For example, I recently worked on a site which displayed a lot of data in the form of progress bars in two different areas of the site. So, three tickets/stories get generated:
- Widget 1 consisting of progress bars, table, etc.
- Widget 2 consisting of line chart, progress bars, etc.
- Progress bars
Now, there are dependency relationships for these tasks. In the example, the two widgets cannot be completed until we finish creating a way to make progress bars (a Finish-to-Finish relationship between the progress bar and the other two tasks). Therefore, in the backlog, the progress bars actually get the higher priority.
It also depends on what you are responsible for. If your only focus is front-end and UI components - focus on that. If you're doing everything front, back, and all points in-between...you'll probably want to do something different.
A general rule of thumb I have adopted over the years of working on the web and in other development areas is to start with a general task: Create 2013 Version of Website, for example. Then try to estimate the duration and complexity level - if I can. If I can't estimate it because it is too vague, I start filling in details (maybe, build header, build footer, build single page template, etc.) - basically atomizing tasks, similar to creating a WBS (http://en.wikipedia.org/wiki/Work_breakdown_structure). When all/most of the tasks can be estimated to take one working day or less to satisfy a definition of done (for me this is unit tests, if applicable; cross-browser compatibility; documentation; etc.), then I stop atomizing them.
What I have found, by following this rule of thumb, is that the stories pretty much write themselves and the backlog tends to be more complete than if I tried to shove a project and its requirements into some predefined structure/convention. So, go back to the original example we might end up with a break-down like this:
1. Create 2013 website
1.1 Widget 1
1.1.1 Progress bars (FF with 1.3)
1.1.2 Table with data
1.2 Widget 2
1.2.1 Progress Bars (FF with 1.3)
1.2.2 Line chart
1.3 Progress bars - split-out and promoted to a higher-level of our WBS
because it's used in multiple places
(I am new to this StackExchange site; so, pardon me if there is a better way to visualize that.)
In conclusion, to answer the question indirectly but concisely - it depends. To offer the most useful/pragmatic recommendation I have found over the years - don't come up with a template before you start documenting tasks - this leads to possibly trying to fit a round peg in a square hole. Instead, add a backlog item at the highest level possible - start building a list which fleshes out this abstract concept at the next level down - then, continue cultivating the backlog by breaking out tasks into 1 day's effort bits and reusability. Finally, use dependencies to help prioritize the backlog and choose which items have the most value - in our example, the progress bars have the most value; therefore, are the most important.
Hope that helps.