UXD Notes: Developing the Scope of a UX Project

To learn more about User eXperience Design, I’m:

  • Taking the Udemy course “User Experience Fundamentals” by Joe Natoli.
  • Reading the book Don’t Make Me Think) by Steve Krug.

According to the timeline I created in a previous post (this is my inner the project manager speaking), I should have this course completed in 8 weeks from now…

This Week’s Learning Takeaways

Disclaimer: My takeaways are not comprehensive of the resources I cite and therefore should not be read in lieu of. If I’m citing resources, I’m recommending them to you. If you like what you read, please support the creator.

User Experience Design Fundamentals: Session 4 – Scope

(It was helpful to complete this section while reading Ch. 9 of Don’t Make Me Think. It reinforced the need for user testing throughout the development process to address concerns that might come up.)


    • People often rush into design and development without fully understanding the scope of the project.
      • Use waterfall or Agile or similar so entire team has clearly defined scope, including what you can/can’t do.
    • When you define scope (and document it), you are forcing people to see and address potential conflicts.
      • The documentation gives everyone a common reference and language. Write down all the essential features and functions, plus who is responsible for what.
      • Make sure suggestions support the strategic objectives of the project.
      • Decide when new features can be added.(Ex. Features 1.0 list for this month, Features 2.0 for next month, and so on.)
    • Resist the urge to say yes to everything. “We’ve gotta look into that and see how it impacts everything else.
    • The long wow – in designing the scope, you have to design how the product will evolve over time. (This can also address some of the feature ideas that come up throughout the process. “We might be able to unfold that as a new experience that keeps users coming back and renews innovation.”)

Functional Specifications

  • The best source for functional specifications are users and stakeholders.
  • Requirements fall into 3 categories: Things they say they need, things they actually need, things they don’t know they need.
    • Many ideas don’t make it into the final feature set because people make false predictions of their behavior. (I also learned from DMMT that users often don’t accurately express themselves in words, it’s better to see them in action.)
    • Focus your attention on the objective, not the feature/function. “People don’t want 1/4″ drills, they want 1/4″ holes.”
  • User scenarios can help determine what functions are necessary.

Content Requirements

  • “Content is the sum total of everything that shows up on screen.”
  • Content format and purpose are different. Focusing on the format (ex. FAQs) can distract from the purpose.
  • Reduce “happy talk.” Content must serve users, not the company.
  • Things to clarify with a client at the start:
    • Who is going to create, edit and approve the content?
    • Who is responsible for managing and updating content?
    • How many content types exist?
    • Which content types exist for different devices?
    • What are the current content requirements and constraints?

Generating Effective Requirements

  • Generally, you need to pull requirements out of clients – they don’t intuitively know. You have to apply your input and expertise throughout the process. “Seek to add value – don’t just take orders.”
  • Opinions have no place in requirements development.
  • What they say and do are not often the same. (Usability and observation are more effective in gathering information. (This is what Steve Krug emphasizes as well.)

Don’t Make Me Think: Chapter 9

  • Usability tests often do not happen early or frequently enough in the design and development processes.
  • With focus groups, you listen to people talk about it. In usability tests, you watch them actually do it. Focus groups are good before design and development.
  • Things you should know:
    • You should test frequently. After a few weeks, “you can’t see freshly anymore.”
    • Testing one user earlier is better than more users later. As you get further along, it’s more difficult to make changes.
  • The process:
    • Test one morning a month, then debrief over lunch.
    • Use a script. (Steve has one available in the book and online. See p. 127-136)
    • Get three users.”Recruit loosely and grade on a curve.” You aren’t collecting quantitative data, it’s qualitative. Give users something to do, then watch and learn.
    • During debrief, focus on the biggest problems first. (Joe’s recommendations for Scope, above, are helpful for this. Steve also goes into much greater detail in pages 138-139.)
    • Typical problems you learn in usability testing:
      • The concept of the site is unclear.
      • Key words they’re looking for aren’t there – you “failed to anticipate” something.
      • The site is cluttered.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s