6

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.

  • "when the app development progressed, there were changes to the design" - What is causing these design changes? – Ashok Ramachandran Dec 15 '14 at 13:59
  • If for example one of the features was replaced. Using the current development mode a change to one epic or some stories does not require updating all of the project but only the relevant items. – Kuf Dec 15 '14 at 14:21
  • possible duplicate of pm.stackexchange.com/q/10508/4271 – Todd A. Jacobs Dec 15 '14 at 18:54
  • @Ashok, many things cause the GUI/visual design to need to change as the code design progresses: things get forgotten up front, ideas are seen to not work well when functionality is added to the imagary or it is discovered that initial assumptions/requirements were wrong. This is the whole reason for the iterative approach of agile design & development existing: it's a recognition that changes to the requirements and initial designs are both needed and desirable. – David Arno Dec 19 '14 at 11:56
9

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.

  • 2
    I don't think you can emphasize enough the need for someone from the development team to be involved in the wireframe review process. Without that, it is quite possible for the designer and product owner to come up with wireframes that are both usable and valuable, but that don't take into account the difficulty/cost to build. – Kyle Dec 17 '14 at 13:55
4

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]
1

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.