Phase Two: Definition

Contents:

Phase Summary

  • Define the Project
  • Double Check Internally
  • Deliver the Goods

Typical Outcomes

We try to limit any unnecessary deliverables because ultimately they take a lot of time to polish and then are thrown away. Think carefully about what the project needs to be successful and use that as the truth stick for measuring which deliverables you want to go ahead and create as a team.

  • Sitemap
  • Page description diagrams when necessary
  • Content strategy documents: audit, analysis, and recommendations
  • Content competitive analysis
  • Voice and tone guidelines
  • Copy; including app store content if needed
  • Mental models (user flows, and current and future system support)
  • User stories (narrative descriptions of how viewers currently do things)
  • Updated components list; ‘statement of work’ document outlining scope
  • Marketing documentation for app submission or marketing site/sign up page

Define The Project

Time to get to it. The definition phase makes use of all of the data we’ve collected and analyzed. Using our understanding of project goals and our detailed research, we create the skeleton of the project while defining which areas need special focus. Remember, we don’t want to predefine the project, or box it into something that already exists to make it easier to digest. Sometimes the best ideas are those that seem crazy or vague at first. For larger projects or multiple products, be sure to establish a clear timeline and rough ship dates. Keep the boat moving, phase the project–ship early and often.

The team works together to create necessary reference documents. The goal is to refine the high-level functionality, brand attributes, core messaging, user behavior, and organization of the site or app as well as its intended goals without spending unnecessary time on documentation. Building apps will involve a lot more user testing and behavior exploration, the amount dependent upon the UX goals for the project. It’s also important to remember to keep the client’s vision in mind. The product ultimately belongs to the person or people hiring us. Telling the client’s product ‘story’ back to them can keep them feeling good about the direction we’re going, not to mention reducing any scope creep down the line.

These may include any of the following (but remember, only if absolutely necessary):

  • Team: Develop information architecture
  • Designer: Develop a sitemap
  • Team: Create page description diagrams to illustrate messaging hierarchy and page types
  • Team: Assess target audience, define site goals (make sure they’re aligned with business goals)
  • Content strategist: Complete a content document with content types, core messages, and final copy; pay special attention to process flow: things like cross linking, calls to action, images, and video placement
  • Content strategist: Create formatting document for content; style guide, voice and tone, and nomenclature
  • Content strategist and PM: Work with client to create content for app store submission if needed
  • Designer: Create a mood board highlighting current and desired branding elements
  • UX: Create usage scenarios and mental models for complex functionalities
  • UX: Document user/process/task flow; determine how you want users to behave
  • UX: Document interface specifications (description of UI, flow, and behaviors)
  • UX: If there’s an open-ended budget, UX works through exploratory ideals
  • UX: Implement usability testing with validated or exploratory benchmarks if necessary
  • Project Manager: Outline with team all components and functionality required
  • Team: If building an app, determine sprint and approval schedule, update project management tool with expected timelines
  • Developer: Identify all the potential API endpoints that will need to be created in order to support the desired application functionality.

Check out the Roles & Responsibilities page to see how our tasks break down.

Architecture Brain Dump

Designers, developers and other teammates along with other stakeholders meet and discuss how the data model and data relationships need to be represented. This helps create a shared picture of the system we’re building together.

The team fills in any gaps in understanding by reaching out to the client with follow-up questions and working internally to keep the plan flexible enough to accommodate new information. Scope creep is most likely to happen during Definition and Development. Make sure the goals and the plan to implement those goals don’t get slippery. Regular communication and documenting ALL additional requests and changes with your team and the client will help you stick to what you’ve determined fits the project budget and timeline.

Note

A good way to discuss potential scope creep with clients is to say: “That’s a great idea. Let’s look at how much additional time that will take and how much that will cost.”

Double Check

Once the documents are created and polished, the team does an internal review before presenting them to the client. This is a great time to reassess high-level functionality, overall branding and tone, the intended project goals, and make sure everything is consistent and supports the client’s business goals. Feel free to reach out to one or two people outside of the team for a fresh perspective and reality check on your rationale.

Deliver the Goods

Get it all in Basecamp and have the project manager connect with the client after submitting the definition documents to walk him or her through them. This way, any miscommunications or possible scope issues can be squared away quickly. Remember to record all additional requests, and get estimates and approvals whenever clients ask for new or different things.

The team completes two revisions to any client-facing formal documentation and any tweaks required and waits for sign-off before starting the design phase.

WAIT! SIGN-OFF REQUIRED!

Note

The client will be sent a Basecamp message each Monday regarding the progress of the Definition phase.