From user stories to product, where and when to do graphic design?

Question

We are taking our first steps in the Agile development world, and while we have a long path to follow, I'm having difficulties incorporating our graphic designer in the development process.

The previous PO believed in a Product definition => designer => Developers flow. The designer worked with the product manager to create a presentation of exact images of the app, sending it to the developers for implementation. This created a huge waste as any change required the designer to update many slides. As well, since he made all images for the whole app beforehand, when the app development progressed, there were changes to the design which again made him change many many slides. Another problematic issue was that the images do not explain expected behavior - what happens when there's an error? using what animation a popup should appear? this caused a lot of expected-behaviour related bugs.

To eliminate this waste, I've asked the designer to create a set images for each story, when most of the image is a sketch of the app and only the parts related to the current feature are actual images. In addition, I've asked the product manager to write the acceptance criteria defining the expected behaviour (which includes any behaviour or specific error messages).

This was just a shot in the dark, and I am not sure that is the way to go. I would appreciate anyone who can share his thought about the process described here, if there is anything I should do differently.

Answer 1

The process you describe is pretty good and fits pretty well into Agile-scrum visual design practices.

Here's the visual design process that has worked well for me across several Agile-Scrum projects:

Start with rough wireframes 1-2 weeks before entering an iteration Have your designer work with the PO to create the wireframes Try and have the wireframes focus on the functionality that will ONLY be covered in the story -If you need to add other elements to your wireframe for context, make sure its absolutely clear what part of the functionality the wireframes cover and what is extra. Review the wireframes ~1 week prior to iteration start with a technical lead or developer to get feedback. Negotiate story changes/wireframe changes with the PO after getting technical feedback At iteration start, attach final wireframes and/or visual designs to the corresponding user story The user story should references the visual design The user story should still provide descriptions in the acceptance criteria of how UI elements interact During demo/acceptance, compare the wireframes/visual design to the actual product. Discuss any discrepancies and adjust the design or create a defect if needed to ensure both stay in sync.

Some wireframing tools are interactive and can actually show UI elements; pop-ups, modals, inter-page navigation, etc to help bring even more depth to the visual design components of the story.

If there is a visual design or wireframe change during the iteration, make sure the visual assets are updated to match the story. Ive seen so many designers work off of outdated visuals that keep getting re-used in stories. This creates a ton of confusion for developers.

Finally, try and get your designer embedded into the team. Many designers can double as a QA resource by looking at local, or QA level work-product and ensuring it meets design criteria before it goes to the PO for review.

Wireframing can be incredibly simple; I've seen great wireframes come off a whiteboard. It doesn't need to always be pretty. Furthermore, you can often avoid detailed visual design on each story if your project re-uses design elements. Keep this in mind when looking for areas to squeeze efficiency.

Answer 2

You're on the right way.

The best plase for the graphic design is a Definition of Ready for a User Story. The Story is percieved as Ready to start development by the team when:

• Title and description is specified
• Acceptance criteria defined
• Graphic design screens attached
• Story Points estimation assigned
• [whatever other criterias you define]

Answer 3

One question to ask is if all stories need to be finally designed when they go out. If not, it might help to only do the interaction/usability design up front and leave the visual design for later. This might not be ideal as it drags one story over multiple sprints but it could save the up front rework of high quality slides.

Answer 4

one of the biggest advantages that Agile (and all other similar approaches) can bring, is that one or two functions (PO and Designers) should never make key decisions on their own - or those decisions will be subject to unnecessary re-work and downstream change - that is one of the major reasons why Agile can give you better product faster :)

Agile encourages all key functions to work as single team.