How do you prevent a situation where you have to produce work-product work first and get client feedback before getting on the right track to meet their needs?

Are there any techniques to help the client and us to get a clearer sense of what she expects?

Background on what we usually deal with:

We often develop (customize) CMS for clients. First and before any information structure is the "look and feel" of the website, the whole "identity", we could even say branding.

Beyond the fact that we are wire-framing the home page with tools like Balsamiq, and ask a lot of questions like:

  1. If your website would be a person, how would he/she look like, behave, attitude have...?
  2. What colors would you associate with your company / product / services?
  3. How is your competition, how does they website look like, what do you feel about them?
  4. What is your company mission statement, vision...?
  5. How your business model looks like, Who is your target group, What the seek etc?

All of this later on in our costumers case most of the time is out of "their true vision of product / company / service design".

What is more one of our customers when we started to ask questions answered: "I need artist that will with himself find proper colours and prepare design. If he is truly artist when he will understand what mission we provide, the design will manifest from inside of him..."

So we also arranged meeting with both client and graphic that would remove any "chain factor", however client using world like: unique, prestigious, life saving, and giving also marketing materials provided totally other vision that graphic understood.

Graphic prepared nice modern design, that showed joy of life, product and company as happy place... As opposite to client vision (that he claimed after he saw project) as this institution has a machine that treats people and rescue life it should be: grey, sad, with attitude like at the funeral / church...

I know that we can adapt "after" he will provide us feedback, however this is tremendous waste of time, money and very often indicates frustration.

  • 2
    Hi Daniel, this type of question might be better suited for our Graphics Design SE Q&A site, since this doesn't appear to be about the field of project management. However, I'd suggest focusing more on finding answers rather than asking for books, courses, etc. The point of our network is for our experts to answer your question, in Q&A format, not to shuffle you off somewhere else. ;)
    – jmort253
    Commented Oct 18, 2012 at 3:32
  • 1
    That is true and not true in the same time. I was thinking about Graphic Design SE, however I saw there only technical stuff. Considering Q&A format also "yes and no", because Project Management is not only about specific questions that answer equals "2 weeks", but also about "soft aspects", and whole "strategy, philosophy, methodology". And for those it is better to point some resources, or topic guru. For this type of complex question simple answer do not exist and this indicates time for research and analysis this concept. Commented Oct 18, 2012 at 10:37
  • Concur with @jmort253; the <a href=pm.stackexchange.com/faq> FAQ </a> specifically requests that we avoid requests for recommended sources. In my opinion the portion of your question which is most appropriate for this site is, "What are techniques to elicit requirements from customers who don't understand their needs?"
    – MCW
    Commented Oct 18, 2012 at 10:38
  • @MarkC.Wallace this is good point, and I will update and formulate question in this way, however when someone would post question "What are techniques to efficiently gather software requirements", some might answer - familiar yourself with Scrum and User Stories, and this will only point my out to seek resources about Scrum and User Stories. I understand that concept of Stack Exchange are to "gather knowledge inside". But sometimes when topic is complex resources are needed, and question do not have simple answer. Commented Oct 18, 2012 at 10:49
  • 1
    Fair point. I believe that the truth is you're asking a hard question. If you can find a good way to ask that question, I think many people will benefit from the answer.
    – MCW
    Commented Oct 18, 2012 at 11:03

6 Answers 6


Soliciting requirements is a iterative process, starting at an abstract level and diving down as you iterate. It is a data pull from the stakeholders; so it is about asking a ton of questions, several different ways, and becoming more tactical as you go along. Since it is a data pull, the techniques are not rocket science. It involves surveys, interviews, workshops, and focus groups. Which means you need to understand the universe of stakeholders involved, their segments to which they belong, and the missions and values which are often times at odds with each other.

Requirements will conflict, and this part of the iteration process. You must de-conflict the offending requirements and rack and stack what remains. And then you will have your requirements baseline from which you can plan the rest of the work. And you will have--not may have--stakeholder segments who are simply not happy.

Regarding the work product part of the question, that's part of this process. Sometimes you must demonstrate functionality, customers have to play with the widget, before a decision can be made. It is part of the focus group and cost of doing business.

  • @David "Sometimes you must demonstrate functionality, customers have to play with the widget, before a decision can be made." How would you demonstrate NFR? In my case design ("look and feel, branding") before it is finally done? And yes we wire-framed all "screens", that passed, hover design does not... Commented Oct 26, 2012 at 12:54
  • I understand the iterative about it, But i'm thinking you can't call a client to come over 4 or 5 times before even giving them an estimate. right? Or am I seeing this wrong? Commented Feb 16, 2016 at 20:43

At the initial scoping phase of the project you need to understand what the client wants and what users want. Your project management skills will be tested in trying to balance both sets of requirements and deliver a product both are happy with.

To understand your client's requirements use the techniques that other answers have proposed including what you're already doing - asking questions. From experience I've found for larger projects it's good to start the process with a workshop (for smaller projects a face-to-face meeting usually suffices). This is really an ideas session but you will need to put some structure around it to ensure that you can engage your client and keep them focused on what you need - their requirements. For example, you might want to put some of the results from usability testing (see below) in front of them and ask them individually to write solutions on post-it notes and stick them on the wall. You can then review them as a group and agree on what the best solution is.

Follow-up the workshop with 1-1 interviews then produce a requirements document in whatever form appeals to your client - so a slide deck, a spreadsheet, etc. Ask for their feedback on the requirements document, reiterate and then get it signed off.

For gathering requirements from users do some usability testing!

There is no better way to understand what users' requirements are (and these are the people who matter most). The information you will get from engaging users is the most valuable information you will get about a website. It's also a great way to challenge what your client wants or believes they want. Informed usability testing cuts through personal opinions about how websites should work. You'll often find that what you thought would work for the user actually doesn't work at all, or gets ignored by the user. It can also validate new functionality that you've introduced. Ideally usability testing should be done throughout a project: during the scoping phase to gather requirements; after wireframing to test the concepts; after the visual design to test reaction to it.

There is lots of information on the subject in books and on the web (including the UX Stack Exchange site). Some typical usability testing techniques are:

  • face to face testing: inviting participants to click-through the website while you observe, taken notes and ask questions (also try monitoring your behaviour during these sessions to inform how you can modify it for future sessions)
  • lab testing: can be the same as above but if you can find the facilities, participants interact with the website while your client watches through a two-way mirror; you can also use eye-tracking tools to monitor where users eyes track across the screen
  • online surveys

You can gather all of this data to improve deliverables on your current project and to plan for future projects.

The data gathered from the testing sessions can then inform your discussions with the client about what they want, what their strategy is, etc. Usability testing data provides a solid evidence base for making design and functionality decisions when planning your project.

  • 1
    If you wait until user testing to validate requirements, you're too late. Commented Oct 18, 2012 at 15:41
  • @DavidEspina I'm saying that you start with user testing to actually gather requirements and then validate them with further user testing after wireframing. Maybe it's just semantics but I'm not defining user testing as the more formal 'user acceptance testing', but instead as a way of engaging with users to understand what they want.
    – br3w5
    Commented Oct 18, 2012 at 15:54
  • 2
    I've edited my answer to clarify that it's about usability testing and not user acceptance testing.
    – br3w5
    Commented Oct 18, 2012 at 16:02
  • 1
    That makes more sense. Consistent with my answer about focus groups. Commented Oct 18, 2012 at 16:11
  • I've added more info about client's requirements because they are the informed by usability testing.
    – br3w5
    Commented Oct 18, 2012 at 16:23

I'm not sure we've answered the OP's question:

How do you prevent a situation where you have to produce work-product work first and get client feedback before getting on the right track to meet their needs?

If I understand the problem correctly, the OP is working with the client to develop the initial requirements for the project (pre-initiation). The sticking point seems to be some soft non-functional requirements (NFR). (the look & feel/branding of the website). It is difficult to do user testing on NFR's (not impossible, but more difficult). If the OP's team doesn't convince the client that they can fulfill those requirements, then there will be no project. These are also soft non-functional requirements - there is no objective answer. The client doesn't know what the website should look like, (if they did, the whole interaction would go differently.)

I believe the OP has given the best answer so far; there are a list of questions to elicit subjective impressions of the brand and try to identify key themes that need to be reflected in the website design.

I would offer two further suggestions:

  1. Check some books on advertising - part of the question falls outside the domain of project management. Very interesting stuff, but not PM. Some of the answers will bridge over into salesmanship where I'm not qualified to comment.
  2. Prepare two or more alternatives based on the answers to the branding questions and ask the client to select the elements that work. Contextualize the experiment correctly - you're presenting some exploratory material to make sure you understand the NFR; actual fulfillment of the NFR will be part of the project execution after the project is chartered and planned.

Might be that some form of SWOT analysis could be adapted here to identify the concepts that are core parts (Strengths) and peripheral parts (opportunities) of the desired brand. The internal/external axis might represent the competitive advantage/discriminators from the competition. (I'm not familiar with it, but I think that the Gartner Magic Quadrant follows a similar model.) If the Project Team and the Client can use that as a structured process to identify the key features of the brand, I think they'll have identified a cluster of NFR's.

There is also an analogy to risk management. Risk management is an attempt to give the operations manager actionable information; the risk manager does that by decreasing the uncertainty on the unknowns. In this requirements exercise, the project team is trying to reduce the mutual uncertainty about the client's soft NFR. The key in both risk management and the OP's situation is that you don't have to solve the problem during the initial requirements stage, you just need to establish a framework and trust that the problem is bounded and that the boundaries will constrict over time to reach a final requirements set that matches the client's true needs.

The OP has asked what I believe to be a powerful question that has implication for scope management in many projects. I believe it is not at all uncommon for the stakeholder to either fail to express or be unable to express soft NFR's. Successful closure of the project means that the PM needs to uncover and quantify those requirements.

  • +1 re SWOT analysis and providing/understanding the strategic reason as to why the product is needed. Although there may not be budget for it in smaller design /crm customization projects. Commented Oct 18, 2012 at 16:29
  • @MarkPhillips: True! What are some alternative paths for smaller teams to elicit the soft NFR?
    – MCW
    Commented Oct 18, 2012 at 16:40
  • that would make an excellent question on its own, particularly if you specify the constraints the smaller team may be facing. Commented Oct 21, 2012 at 20:25
  • @MarkPhillips "True! What are some alternative paths for smaller teams to elicit the soft NFR?" It is exactly the question that I am seeking answer... Commented Oct 22, 2012 at 11:59

Would not delve in graphic design issues, since my aesthetic feeling may not be shared by others. As for eliciting customer's requirements, there are a few considerations:

How do you structure and dimension your product space?

a) Structure: what attributes of the product do you consider overarching and largely constraining your design? For instance, for aircraft it would be the required mission profile - what payload, how far, how high and how fast should it carry? It doesn't make sense to concentrate on ancillary product characteristics if inability to fix the top of the attributes' ladder leads to feature creep and multiple redesigns.

Once you've decided what attributes would generally come first, you have to make them as independent of each other as possible (we say orthogonal, perpendicular to each other).

b) To achieve attribute independence you would generally cull out attributes strongly correlated to each other and leave a manageable number of dimensions. Given clients' short attention span and your limited resources, would not recommend more than five dimensions altogether, preferably two or three (to leave clients some choice).

Next, what are the extremes at each dimension? Say, a regional jet or a jumbo for Trans-Pacific flights? (note to self: avoiding car analogies? check) Prepare sketches of design for each combination of extremes and sit with the client to see how he feels about the variants. (Don't try to second-guess him now - the money is his.) Let him know these are just rough approximations and will be refined as more preferences are revealed. Refine, fixing his decisions on what is and what isn't acceptable. Repeat the process...

There is another route (which works for less subjective products, though): finding someone with enough knowledge of both the client's industry and your subject domain and enlisting him to work as 'an interpreter'. However, the usual complication is that a 'middleman' whether he works full-time for you or not brings a whole set of own biases and preferences into play, and possibly a hidden agenda as well.


"How do you prevent a situation where you have to produce work-product work first and get client feedback before getting on the right track to meet their needs?"

You can't in a lot of cases. But from what I've read/understood of your question, it all comes down to risk management.

You said:

What is more one of our customers when we started to ask questions answered: "I need artist that will with himself find proper colours and prepare design. If he is truly artist when he will understand what mission we provide, the design will manifest from inside of him..."

Translated that says - I want an artist that can read my mind.

With a client like that you have two choices - keep trying to draw out requirements, and then document those and be very clear and specific, or build the process of demos and prototyping into the cost. Start with a crude idea and get feedback and build from there.


Maybe I've missed it in other answers, but I think one of the key pieces is to gain a better understanding of what the client is actually trying to achieve at a high level.

  • Measureable goals

    • Increase overall market size?
    • Take users away from competitors?
    • Prevent current users from leaving?
    • Be seen as the best solution in the space?
    • whatever else they are trying to achieve, as long as it is measureable in some fashion
  • Constraints

    • What can't they do?
    • Are there regulations that they need to follow?
  • User personas

    • Who are they targeting? (this needs to provide insight, not just a few words)
    • What is the context does this person use this product in?

Building this with the client can help not only point you in the right direction, but will often help get the client to think (and express) more about what the final product should look like.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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