Different roles in a SCRUM team - how to do?

A few months ago we decided to extend our team with a new role - the design role. The reason for choosing to employ a designer rather than another serverside developer was to improve our ability to guide and reason our Product Owners about the layout and design of the systems we're working on. Being serverside guys the layout and design process incorporated the de-facto It's-Ugly-But-It-Works standards seen worldwide. So - a designer was employed in Mid-October and has worked with us on a project that began 1. of October.

Today after a Sprint Planning One our new designer raised concerns about the stories we are to work on during the sprint in February. We realized that questions such as "What's the identity of this new website we're launching February 1st" had never been answered properly so the stories we created before the October sprint and up until today didn't reflect any thoughts about layout and graphics. What we had was a lot of functionality (a feed-reader, data-standards, a Lucene index for searching etc.) which reflected what the user was supposed to be able to retrieve... Not a single story about design of the markers on the Google-map which is a vital part of the new website. Nothing about what the logo should try to express or if the site should have a visual pattern or layout which would enable a user to recognize it as a subsite of our main website. It has resulted in our new designer working on tasks not directly related to the stories we've created and estimated - some times she's been working completely on her own without anything being reflected on the task board which breaks our SCRUM process in terms of visibility and ability to provide feedback to our Product Owner.

We knew before hiring a designer that bringing in a new role to our consolidated team of serverside developers would be a challenge - we couldn't really point our finger to how it would show itself but It struck me how used I've become to think in terms of functionality when reflecting upon stories in our backlog - for example: "I need to know where data is coming from before I know when it's done". That's what I think about when reading a story description - I never come to think about how it is supposed to look and feel on the website. I consider it to be similar to my wife at home who once every three months points a finger at me and tell me that I mess a lot at home. I do - because I don't see my three jackets hanging over three different chairs in the living room instead of resting on a coathanger in the hallway. I don't see that all the pillows are stacked in one end of the sofa - it's not that I don't want to I just don't see it. I guess it's the same way when I read a user story - it's not that I don't want to see the design challenges and issues - I just don't see them and I could imagine that the same rule applies to a lot of serverside, hardcore .NET developers with a hang for unittesting, automated builds using CruiseControl.NET, deploymentscripts etc. etc. It's hard to see things or problems you don't know exist and that's the challenge we're facing right now.

The way we're trying to overcome this challenge right now is to implement the following:

• This sprint will have a story called something like "Design and identity of website". The tasks are to be defined during Sprint Planning II (this afternoon). This story is not estimated so it will act as a placeholder for the design tasks requested prior to launching February 1st. The main goal is to improve our understanding of the tasks related to the design process.
• Upcoming projects will have stories focused on design and identity during the first sprint(s).
• Working in Adobe Photoshop shouldn't be regarded as "Design" tasks. We're a team (swim or sink as one) so at least one of the remaining teammembers should at least have a clue about where to find PSD files and be able to navigate in them.

We had a discussion about the fact that if you're working in a team everybody is working on the same story always. Is this always true - is it impossible to have a Design role working on future project's identity and wireframes while the rest of the team are working on implementing features on the project which is up for release? I think it is like having a Tester role - they should be able to work on enhancing i.e. test suites for the entire suite of projects regardless of what the Software Programmer role is doing. If you define a role as being what are most likely to be doing on a daily basis - is it wrong to even think in terms of roles in a SCRUM team? Note: the Product Owner and ScrumMaster are SCRUM roles - I'm talking about the different roles within the role SCRUM Team.

We have committed ourselves to be doing SCRUM by the book so I'm curious to know how other teams are integrating different roles in their daily work using SCRUM. Please leave a comment if you have something to share - I'm all ears  :o)

Regards K.