Managing scope changes and timelines for graphic design components of a project

Question

Our team mostly does web application projects, working directly with our clients. For projects without a public-facing interface, design is rarely a major issue.

Nearly every project that involves a public website component, however, results in a lot of back-and-forth about multiple design details, ranging from color choices, to placement of content elements, to navigation menus.

Usually, it is one or more key stakeholders who identify something they don't like, ask it to be changed, give vague descriptions of how it should be changed (ranging from "it's too dark" to "it should look 'new' and 'modern', and this [entire component] looks outdated"). The expectation is usually that we redo it, so they can see if we got it "right", and if we didn't, we get new feedback ("that looks better, but now it doesn't have enough contrast compared to [adjacent component]", or "that's definitely better, but it still doesn't 'pop' enough! I want something that really draws attention...."), and are expected to do it again.

In some cases, this can result in half a dozen design iterations or more. This creates a large amount of scope creep.

We are working on better structuring of definition of done for our projects (we're moving... slowly... towards a Scrum approach to development), but I'm at a loss for how to employ this approach for graphic design elements.

Ideally, what I'd like to accomplish is to either:

1. Limit the number of design revisions that can be requested before sprint completion
2. Find some way to effectively communicate to stakeholders what we're including in the design portion of the estimates, and at what point their requests will start impacting our scope (preferably before we get to that point).

Number 1 would be my strong preference, as it would make it easier to maintain an overall schedule without impacting other sprints or projects.

Number 2 might be as easy as "we devote x hours to design, and anything over that costs extra", but our previous attempts at this have sometimes frustrated clients, resulting in their arguing that the design wasn't "done" because it didn't contain features that they hadn't previously defined (this was in projects where we failed to get adequate definitions of done, however). Other clients agree to continue paying the extra costs, resulting in a lot of extra billable time, which is great until we have to explain to another client that we have to delay their project because the previous one is running weeks beyond schedule (we're a very small team).

Note that we do not have a dedicated graphic designer, and, while it's on my wish list, we are unlikely to get one anytime soon.

Answer 1

Firstly, design is a very personal thing and (in my experience in a similar industry) this makes it very difficult to set the 'back-and-forth' process to a specific number of iterations. I think your second suggestion is much closer to how I would approach it.

To keep the back-and-forth to a minimum though, I would consider getting the client involved at the Wireframe stage or gather more detailed requirements than you might do in other industries, and then keep in regular communication with them throughout the process. The time spent at the start getting the requirements and layouts right for the client may well pay dividends when it comes to the design process further down the line.

Answer 2

Product ownership

Get your clients to appoint one product owner. He is the one who communicates with the team and make sure all stakeholder interests are looked after. This way, the constant change and minimal changes are felt more within their organization and/or team, and less in yours.

Plan for a number of sprints, or don't plan other projects

To give transparency and an honest outlook to your clients, you have roughly two options:

1. When first starting the project, plan together with the client / product owner for a number of sprints to be run. Make clear that you have other projects that need fulfillment. When scope is increased in design, immediately point to the fact that quality and time are fixed. Therefore, scope in other stories needs to be altered, or something on the bottom of the backlog will not make it to the sprint. This option ensures you can adhere to time schedules, but may leave clients unhappy.
2. Don't plan other projects until a running project is complete. Or at least not until you're fairly confident the project is wrapping up. This option makes planning future projects harder, but ensures you can fully serve clients (they can keep adding sprints until they're happy).

Optimize your design process, or outsource it

1. There are numerous methods to running a design process. Some will be better suited than others. Do research on this, incorporate what fits your situation into your process. For instance: use a style tyle / style guide to quickly set a general frame of reference for all design and ui. If the client agrees, point to the style guide whenever changes are proposed. If it's still being pushed, once again make clear that this will affect some other stories scope.

2. Cut the design process loose from everything else. Treat it as a separate project. Possibly use a freelance designer for this. This way, the unpredictability of the design phase is contained inside that project. Once that design has been agreed upon, your team can deliver the project as specified in the design.

On something of a sidenote I'm quite interested in how you currently handle maintenance or incidents, and how you handle scope increase during development. What I mean to say is: there are more reasons for scope, complexity and effort needed to increase, besides design. How do you cope with that in your current workflow?

Answer 3

Move your design and UX skills under the Product Owner and not on the development team. Spend as much time as you like getting the right design, and then only push the final one down to the development team for implementation.

Make the UI, UX, and Behaviours part of the Product Backlog Item.

This has the benefit of minimising the rework for the team, which is both waste and demoralising.

There are many tools out there from Balsamic to PowerPoint that can be used for storyboarding. Your stakeholders then iterate on UI with the Product Owner (and their new minions).

Answer 4

I'd try to work with one representative, collect feedback from all others during a demo, and let the representative choose where to focus next.

I'd start focussing on functionality and bring the site live as soon as possible. Half finished, on a testenvironment, but live, with content. As soon as you have a live website people tend to care about what it can do. If the logo is all you give them, they will care about it. So give 'm more to care about.

I'd make sure that the one representative is close&available to the designer when design is being done. It's best when they're in the same room during that time.

This way you achieve a couple of things:

The product owner (that's what he/she is) can choose between functionality or design. The Sprint can contain stories about design as well as functionality. Since you have only one person to deal with, you will eventually reach a result. This person (let's call him/her the Product Owner) will 'own' the design, having been part of the process. He/she can explain to the rest of people 'yes, the logo is a bit dark but we decided to focus on the login functionality this sprint'. Or 'Ok, we will change that the next Sprint'. Or 'Sorry but we tried that and it was voted out two weeks ago'.

Answer 5

One of the benefits of having a Product Owner when working with Scrum is that they are a single voice for requirements.

This means that they:

• Spend time speaking with the stakeholders and so prevent the development team from getting distracted
• Remove confusion over requirements and prevents conflicting requirements
• Rationalise the multiplicity of requests from stakeholders and boil them down to a simple prioritised list
• Realise the cost of making changes and weigh them up against the benefit they deliver

This is why Scrum introduces the Product Owner as an intermediary between the development team and the stakeholders.

It is worth remembering that the goal of Scrum is to deliver what the customer wants and so feedback and constructive change is encouraged. The key to stopping it becoming a problem is to have somebody in the Product Owner role who realises that every change made comes at the cost of pushing back other work.

Smart prioritisation will minimise UI tweeks with little business value and will encourage better communication of requirements to minimise waste.