Managing Client Feedback

6 Jul 2011 - 2:02pm
3 years ago
5 replies
980 reads
rkeeves
2010

Hi All, 

For anyone working in a client services/agency format, or with a sea of internal stakeholders on large scale projects, I'd love your comments. Managing client feedback can be a detailed painstaking process. It's not the fun part of design, however it needs to get done, and when done right can it really make a difference. I'm interested in the following with respect to managing feedback for wireframe documents:  

1.  For each iteration of wireframes that are completed and presented to the client, how many rounds of review do you allow with the client?  Did you agree on a certain number of rounds of review with the client in the SOW?  What happens if you go beyond the limit?  

2.  For each round of feedback collected, how do you manage the feedback?  Sticky notes in a PDF? Excel doc? Google doc?

-Richard 

Comments

7 Jul 2011 - 5:06am
Fredrik Matheson
2005

Good topic. What's a SOW?

7 Jul 2011 - 8:05am
willdonovan
2009

KiN : http://flavors.me/kin
State of Design Festival: Victoria-India Service Design Jam



On 7 July 2011 20:18, Fredrik Matheson <fredrik.matheson@gmail.com> wrote:

Good topic. What's a SOW?

7 Jul 2011 - 8:05am
pjohnkeane
2008

SOW = Statement of Work ("A statement of work (SOW) is a formal document that captures and defines the work activities, deliverables and timeline a vendor will execute against in performance of specified work for a client. Detailed requirements and pricing are usually included in the Statement Of Work, along with standard regulatory and governance terms and conditions." -- http://en.wikipedia.org/wiki/Statement_of_work)

On 7 July 2011 11:47, Fredrik Matheson <fredrik.matheson@gmail.com> wrote:

Good topic. What's a SOW?

(((Pl
7 Jul 2011 - 8:05am
willdonovan
2009


Question 1:
Generally 2 rounds of feedback identified in the scoping document. However they assist in the beginning and co-create the goals of the wireframes with some collaborative sketching in a workshop to have everyone on the same page going forward. The second is to bring the wireframes back for their review of the Conceptual Framework Wireframes (I use these to highlight object grouping areas through the Interacton Design phase) and the actual wireframes.


I have to ask why the focus on the client?
A user focus of the wireframes has me pull together the early wireframe stakeholder & design goals with that of the early findings in the research phase. If there is little or no research phase then early (lo-fidelity) user-testing of the wireframes would have to going back to the client a second time with the results.

I try to keep my main stakeholder(s) involved with the wireframe design activity so that any decisions made has them involved and just as responsible. Any changes after the final presentation for me have more to do with style guides, existing models of use and implementation challenges. Even gaps in the early business requirements.

If the review is to go beyond the limit it is at this stage it happens because we realise a shift in priorities, goals or want to explore an opportunity that  is a huge win for both the stakeholder and the end users (or delivering the project).

If (and it has for me) it is none of this and there is disagreement. I find it tends to be around a gap in a shared understanding and  language of the goals and agreed outcomes. I find there is always a project timeline and a conversation to align what we're trying to achieve needs to happen. Indi Young made the quote to me one day in a workshop "it's like Jello (Jelly)" It's about working it and at some stage is starts to congeal. The timeline can be extended however I make sure everyone is aligned on the goals.



question 2:
In the past I have captured everything is a Design / Issues Log similar to the capturing or user feedback or commentary made in research and if there is enough commentary I'll do an affinity exercise as I'm combing through the feedback. I'll have a discussion with the main stakeholder(s) to find out what needs to be addressed, then have discussions in a group or with small teams of people to get clarity and agree on a path forward or agree to close it off.

With each comment I log an outcome and from whom. Right then I double check that if the person who made the decision around a suggestions priority is the right person. If not I take the comments to the decision maker and collaborate with them to make sure there is buy-in all the way and everyone has the sense of being involved.

Going forward I can then draw on (traceability) the comments and decisions from both sides (stakeholder and users) that influence the wireframes. I always find it matters on how you present it. I've shared it as a story of the research that unfolds the design, or gone pixar style and created storyboards of the wireframes and walked people through the story of the research AND the interaction design flow.





William Donovan
t, fb, in, b: @willdonovan
http://www.willdonovan.com.au/
Projects:
KiN : http://flavors.me/kin
State of Design Festival: Victoria-India Service Design Jam



On 7 July 2011 17:20, rkeeves <rkeeves@gmail.com> wrote:

Hi All, 

For anyone working in a client services/agency format, or with a sea of internal stakeholders on large scale projects, I'd love your comments. Managing client feedback can be a detailed painstaking process. It's not the fun part of design, however it needs to get done, and when done right can it really make a difference. I'm interested in the following with respect to managing feedback for wireframe documents:  

1.  For each iteration of wireframes that are completed and presented to the client, how many rounds of review do you allow with the client?  Did you agree on a certain number of rounds of review with the client in the SOW?  What happens if you go beyond the limit?  

2.  For each round of feedback collected, how do you manage the feedback?  Sticky notes in a PDF? Excel doc? Google doc?

-Richard 

(((Please l
7 Jul 2011 - 8:22am
Lisa Goldberg
2007

Typically I plan for two rounds of feedback. Of course actual revisions depend on the project and usability test results.

I keep versions of each set of wireframe documents and list the updates in the wireframe notations. I also email the list of changes to the stakeholders along with a link to the latest version of the document.

Lisa

 

Syndicate content Get the feed