Stakeholder Evaluation, Roles and Responsibilities

by on July 12, 2013
in book, design

An Excerpt taken from, The Value of The Finite

By taking the time to understand the people involved with your project, your own role and contributions, and thoughtfully engaging the right people in the right way, you can make a significant impact on the ability of your project to succeed. It also has the side benefit of helping your career as well. This is fundamental, but is often overlooked in the design discipline. It is critical to ensure you are involving the right people in the right way with intention in the design conversation. The process is really pretty straightforward, simply ask yourself who needs to be involved, how and when should each individual be involved, and what is their actual role and/or contribution?

While working through this exercise keep-in-mind that the magnitude and importance of this is corollary to the scope of the project, the size of the organization, the number of internally dependent teams, as well as any external partners. By looking at a project through the lens of all of the “other people” working on it, communicating about it, and losing sleep over it, you can gain some very useful insight as to how to appropriately involve everyone in the design conversation.

Take thirty minutes and do the following for your current project. I guarantee it will be the most useful 30 minutes you invest in your project today. You can thank me later.


1. Make a list of all the people directly or indirectly involved with your project – include people

2. Answer each of the following questions for each person:

What is their role?
What function does this person perform in the organization?
What are their expectations?

What is their responsibility?
What is their expected contribution to the project?
What do they really want to contribute?

What is their motivation?
What is their personal and/or professional interest for involvement?
What is really important to them?

What is their preference?
How do they work?
How do they want to be involved?

3. If you don’t know the answer to the questions, be direct and ask. It’s amazing how much people appreciate this.

As an example here is a stakeholder evaluation that I conducted for a primary influencer from a past project (all information has been fictionalized to protect

Stakeholder: Sally Joyce
Role: Project Manager (mid-level)
Function: Manages schedule, delivers functional requirements for the project, and also communicates project status.

Expectations: Involvement in requirements authoring, feasible timely design solutions respectfully incorporating functional requirements. Communication of blocking issues, and the completion of deliverables. Involvement in preliminary design discussions to prevent missed requirements.

Responsibility: Accountable for the delivery of the software solution on schedule.
Contributions: Requirements, feedback on designs, schedule, communication.
Actual Contributions: Are in alignment, no gaps, or conflicts of role and contribution.
Motivation: Date driven. Delivery of solution on time, without slipping, irrespective of quality.
Importance: Meeting dates is really important.
Style: Assertive face-to-face, passive written, prefers face-to-face, often doesn’t read emails.
Involvement: Needs direct involvement in reviews to meet preferences. Won’t appreciate or read written status.

As you can see, by just reading the summary above, having never even met Sally, you probably would have a pretty clear idea about how to work with her, what she expects, what makes her tick, and how she prefers to work.

The funny thing is we all have these needs in the work environment, and we so rarely communicate and talk about them. It’s as though there is some sort of social contract that says we’re just supposed to intuitively “know” all of this about each other.

It’s amazing to me what happens when you simply directly ask the right questions, instead of guessing, assuming, or pretending to understand people. When you assume this, you are simply projecting your thoughts and beliefs onto someone else, and this can have the adverse effect of alienating the people you will eventually need to rely on to deliver.

When conducting an evaluation like this, often I will just be getting to know someone related to a project, and won’t know the answers to many of these questions. So i’ll schedule a thirty minute one on one to fill in the blanks. Every time I have done this people generally open right up, are really happy to talk about what they care about, what their perception of their role and contribution is, and what is important to them. People like to talk about themselves, it’s what we know, it’s human, and people generally really appreciate it when you simply take a few minutes to understand them.

In retrospect I have spent years of my life working with people on projects having not done this. I guessed, assumed, projected, tried to reach over gaps, and made so many mistakes in the process. This simple tool employed appropriately, early in a project, can go so far in building really solid foundational working relationships on your projects.

It takes a little effort, a little practice, and a little discipline. And once you get the hang of it, not only will you earn the respect of the people you work with every day, but you will also advance your own self-awareness relative to your contributions, motivations, and preferences.

Design Review Process

by on July 11, 2013
in book, design

An Excerpt taken from, The Value of The Finite


The design review process is a tried-and-true social mechanism for ensuring standards of quality, cross feature and functional alignment, ensuring consistency across deliverables/functional areas of larger projects, and incorporating feedback from project stakeholders.


Ensure that designs meet appropriate standards for consistency, accessibility, usability, findability, internationalization, performance, etc.


  • Maximizes transparency of design progress
  • Acts as a natural forcing function for progress
  • Ensures that designs meet business goals
  • Helps to minimize late changes to product requirements and concepts
  • Helps to ensure brand integration


  • Realize maximum value internally from design teams
  • Facilitates teamwork, learning, and cross-pollination of ideation
  • Increases team accountability
  • Involve teams and project stakeholders in the design process


As with any other meeting (see chapter 2.1.1 On Time) ensure that the agenda is clear, that roles and responsibilities for the review are assigned, and that the work up for review maps to one of the following categories or design stages. Send the framework for the review at least 1-2 days in advance of the review. Do not send the designs ahead of time unless you require feedback from folks that aren’t available face-to-face for the review. Feedback on designs is very subtle and is almost always best shared face-to-face whenever possible. This also allows the designer to capitalize on the first impressions of the design. Often folks feedback will evolve if they have enough time to “think-about-it” which is still useful, but isn’t aligned with how an actual customer will consume a design solution.


  • Design Owner – The designer (in the hot-seat) presenting his work for the review.
  • Design Reviewer – Ideally at least one other designer, someone from outside the design discipline – ideally test, and a researcher if available.
  • Informed – Make note of any key stakeholders outside of the review that may need to be informed on the review status, and follow up notes.
  • Note Taker – Someone needs to take notes, which should only be sent directly to the design owner. This responsibility should rotate on teams.


The goal of conceptual design review is to verify early that design concepts map to the user experience vision and product pillars. These could be anything from pencil drawings, pixel perfect comps, interactive prototypes, or even competitors solutions.


  • Low-fidelity/Med-fidelity prototypes – Ideally from an efficiency perspective little time investment has been made this early in the process.
  • Preliminary interaction/navigation models
  • High-level design concepts – Many interaction or core details may be left missing. This is ok, the goal is to understand and talk about the high-level direction.
  • Preliminary information architecture/s
  • Design schedule – How is progress relative to committed dates? Are things on track?
  • Task analysis – Are there critical use-cases missing that would fundamentally alter the design or force a change in direction?
  • Competitive evaluation- Are there existing solutions the design is informed by? Are there better alternatives out there already?
  • Alignment to product vision/pillars – Are you aligned with them?


  • What scenarios/stories/use-cases/tasks does this concept address?
  • How does the concept accomplish the scenario/customer goals?
  • How does this concept deliver maximum value to the target customer/primary persona?
  • How is this concept better than existing/competitors solutions/offerings?
  • How did data/research help inform/shape this concept?
  • Which stakeholders have given input into your concept?
  • How does this concept integrate with other products/feature areas?
  • How does this concept fit into the product pillars and product vision?
  • How is progress relative to committed dates? Are things on track?


The goal of the design standards review is to verify that the updated design concepts meet the required organizational design standards. Of course every organization is different, but if you don’t have any defined standards documented, that might be a better place to start, rather than effectively “flying-blind” and proceeding with product design without any documented and agreed to design language.


  • Med-fidelity/High-fidelity prototypes
  • Applicable user experience guidelines, organizational best-practices, and documented design language
  • Low-level design
  • Design schedule


  • Does the design look right?
  • Does the design feel right?
  • Does the design align with all documented standards within reason? Includes: design language, team principles and tenets, and standardized best-practices.
  • Are there new deviations/innovations that should be documented?
  • Does the design fit into the product road map and product vision?
  • How is progress relative to committed dates? Are things on track?


The goal of the interaction design review is to verify that the proposed interaction/behaviors are clear, predictable, consistent, and usable.


  • Med-fidelity/High-fidelity prototypes
  • Applicable user experience guidelines
  • Low-level design
  • Design schedule


  • How is the UI design tailored to the primary persona?
  • What are the most significant engineering concerns for this design?
  • What interaction standards or best practices have been employed?
  • Are there any necessary additions or changes to the visual specification needed to support this design?
  • What legacy features may be impacted by the proposed design?
  • How is the interaction design consistent with the brand?
  • Does this design require ongoing maintenance?
  • How is progress relative to committed dates? Are things on track?


The goal of the visual design review is to verify that the visual design of the UI maps to the design vision, the visual specification, and the brand guidelines for the current release.


  • Full fidelity pixel perfect compositions of core screens
  • Color palette
  • Icons, graphics, and branding
  • Visual specification
  • Brand guidelines
  • Product vision


  • Do the visual design elements within the UI align with the brand guidelines for the release?
  • Do the objects (buttons, tabs, menus, etc) align with the visual specification?
  • Does the visual design (colors, grid, typography, graphical style, icons, and logos) align with the visual specification?
  • Are any amendments are needed within the visual specification to support this design?