Iterative Fidelity Development: Part III (of 3) The New Framework

UX Design @ UW
Oct 27, 2014 · 11 min read

By Jason Civjan

Part II discussed some of our major realizations around how to best align Agile development and great UX. One of the key takeaways was that iterations should increase the fidelity of the product and not the functionality of the product.

To this end, we redesigned the way we develop software, resulting in the Iterative Fidelity Development framework. While this post will give a general overview of this model, you can check out this document for an expanded explanation.

The Iterative Fidelity Development framework includes:

Project structure

Story in Trello
Story in Trello
Story in Trello (UI Fidelity)
  • Stories document single user workflows that support their end goal(s)
  • Iteration on each story in development happens across fidelity, progressing through fidelities until you reach Minimum Viable Product (MVP) or the Project Owner (PO) decides to release the product:
  1. Pageflow fidelity
  2. Wireframe fidelity
  3. User Interaction fidelity
  4. Narrative fidelity (visual and a11y)
  5. Visual Design fidelity
  • A Sprint is a timebox to take stories to a higher fidelity.
  1. If possible, iterating through multiple fidelities w/in a sprint is fine.
  2. All stories for a release candidate should progress at roughly the same pace through fidelities (if you get through Pageflow fidelity for Story 001, stop working on it until Story 002 has completed that fidelity). This may take multiple sprints.
  3. All tasks, discussions, decisions, and goals are scoped to the stories and fidelity at hand.
  • Release Candidates are determined by the development team and focus on MVP

Meeting structure

In Weekly extended standups, the development team agrees on the goals for the week that will put them on track to meet the sprint goals, and tasks are created to meet these weekly goals.

Daily standups focus on clearly stating what was done yesterday, what will be done today, and what will be next. Also, a time for bringing up any issues/roadblocks or confusion.

Sprint Retrospectives include:

  • Reflection on what went well and what went badly during the sprint.
  • Action items to improve the next sprint.
  • A revisit of the release plan and MVP definitions to show team if things are on track; negotiate time in later sprints for new work discovered during the sprint; and to make updates to release plan as needed.

The Iterations of Fidelity

Below is an overview of each fidelity step. For a more thorough description, see the expanded document here.

Before Development Begins: Defining the Project


  • A purpose of the project. Why is the product being worked on?
  • Intended audiences for the project. Who is expected to use this project?
  • A usefulness of the project. What real goals do the audiences hope to accomplish and which ones do you propose to support?


Use cases (audiences and goals) that the first MVP needs to support.

Stories that describe the workflow(s) implied by the use cases.

A rough Release Plan:

  • Stories that describe the first MVP should be determined.
  • Remaining stories can be roughly hashed out into logical subsequent MVPs.
  • Gut-estimation of effort for the development work for the MVPs.

Technology choices that will get the development effort started.

Note: In this project definition phase, we typically don’t include QA yet. They will be included if a particular meeting or decision needs their input.

This work should be timeboxed (a couple days — 1 Sprint) to push the team to make rapid decisions. If the work finishes early, then get started with Sprint 1.

Whiteboardng Audiences and Goals
Whiteboardng Audiences and Goals
Whiteboardng Audiences and Goals

Audience and goal definition/prioritization can happen on a whiteboard.

Pageflow Fidelity



Implementation considerations come when mapping the supported workflows to an ultra-low-resolution Pageflow diagram, which provides a system map — pages, basic navigation, basic form elements, and information needs — that communicates the minimum product that will accommodate supported user workflows. With this, you inherently have the basis for a useful (supports real user goals) and usable (maps to natural user workflows) product.

While Design is creating this simple Pageflow (including the whole team in strategic whiteboard sessions), the Engineers are starting to put together the technology stack . These are efforts that are lead by Design and Engineering respectively, but the other team members are included and proactive in questioning what is being proposed. At the end of this fidelity, you should have:

  • Defined User Workflows for each story.
  • A Pageflow Diagram, detailing the critical information needed to support the Workflows, across each page of the product.
  • A fully tested working product that creates the Pageflow in working code, with real information being pulled onto each page; the basic (simplest) interactive elements enabling users to follow the workflow; and semantic code.
  • All test cases to allow testing of all app behavior. These should have been created by QA and Design (together) and shared with the development team. At end of sprint, these should be verified as passing by QA.

Note: The product at this point is great for low-fidelity user testing, in order to validate that the information that is being displayed is the information needed to complete the workflow.

workflow diagram
workflow diagram
An example Workflow Diagram.
Pageflow Diagram
Pageflow Diagram
Example of a Pageflow. This is what is built out in real code, and iterated upon in subsequent fidelities.

Wireframe Fidelity


Pageflow becomes regression testing for QA and they can simply focus on what is new. Once this fidelity is done for all MVP stories, you’ll likely have a releasable product. It might not be the prettiest site out there, but it should certainly be useful and usable.

Note: We have a generic Django project template that contains the basic technology stack we use and our baseline css (bootstrap w/ our basic reset). With this, the wireframe site tends to have a pretty decent, tho generic, look and feel.


  • Production-ready, fully tested code, that now has a designed layout of the information. It still has the simplest UI solutions that semantically allow the workflow to be completed.
  • Updated/expanded test cases, that represent any new thinking around behavior of the app. These should have been verified by the development team and be validated as passing by QA.
example wireframe
example wireframe
Example Wireframe

Note: The product at this point is great for mid-fidelity user testing, in order to validate the visual hierarchy and layout of information throughout the workflow, as well as getting an idea of where your labels and content isn’t meeting the user need.

UI Fidelity



  • Production-ready, fully tested code, that now has fully optimized UI elements (think both desktop and mobile). Any changes should have strong rationale to recommend them above the simplistic and semantic code that is currently in place.
  • Updated/expanded test cases, that represent any new thinking around behavior of the app. These should have been verified by the development team and be validated as passing by QA.

Note: The product at this point is great for user testing of specific implementation choices, especially if you have introduced non-standard solutions.

Narrative (content, visual and a11y) Fidelity


Note: Keep in mind that, by focusing throughout development on semantic coding and having general eye towards A11y while coding, your product is likely already accessible and that this phase is really about optimization.

Again, there is a narrative already established — in the workflow and translated through the pageflow, IA and UI — so you are again just looking deep into the refinement. Think about the narrative for fail states and think through the content/narrative of the 403, 404, and 500 pages. If you desire a separation of your content from your code, this is a chance to clean that up.

This is when you want to have a full content review, by content editors if you are lucky enough to have some. Bugs should be entered for grammar, consistency, etc.


  • Production-ready, fully tested code, that now has polished content and visuals that clearly present a narrative through the workflows that the product supports. These narratives should be echoed in the A11y narrative.
  • Updated/expanded test cases, that represent any new thinking around behavior of the app. These should have been verified by the development team and be validated as passing by QA.

Note: The product at this point is ready for full A11y testing and pinpoint user testing to answer specific research questions.

Visual Design Fidelity


It is usually beneficial for Design to lead the development team/stakeholders through a process of defining the visual style for the site, and then knock out the details and implementation themselves, getting validation as necessary.

At this phase, Engineers usually don’t have a ton to do, other than bug fixing and joining in the team meetings, so can focus a bit more of their effort on code and performance optimization, which is great.


  • Production-ready, fully tested code, that now is fully designed to MVP.
  • Updated/expanded test cases, that represent any new thinking around behavior of the app. These should have been verified by the development team and be validated as passing by QA.


  • We had production-ready code that supported the major workflows at the end of the very first sprint.
  • Subsequent work iterated across the entire application, providing plenty of opportunity to refine thinking.
  • As with everything else, the JavaScript layer was built iteratively, so that foundational JS was easily kept separate from optimization JS, making our ability to respond to changes in implementation decisions far more easily.
  • Communication was efficient and the team had a common definition about what was being worked on at any given moment, allowing us to minimize documentation dramatically.
  • ALL team members (not just UX) were conversing and making decisions based on a common understanding of the user workflows.
  • The entire development team was talking in terms MVP and fidelity.
  • As new information came to light, the development team trusted the process, willing to push changes that were outside of the the sprint/fidelity scope to a later sprint/fidelity.
  • The timeline was easier to manage, as there was always leverage to negotiate.
  • There was a huge amount of confidence in the code and product going into final release.

With this said, it is true that most of the project development team was deeply involved in designing this framework, which may have made it an anomaly. However, a few of us have gone on to use this system in multiple other projects since then, and continued to find that it solved many of the problems that we were unable to avoid with the more traditional model, resulting in what felt like true Agile without sacrificing holistic UCD processes.

Interested? Have questions? Something to share? Drop a comment and we’ll happily continue the conversation.

The other posts in this series are:
Part I about the UX of Agile.
Part II highlights our realizations about how to best align UX and Agile.


Thoughts from the user experience (UX) design community at the University of Washington.

UX Design @ UW

Written by

User Experience (UX) design at the University of Washington.



Thoughts from the user experience (UX) design community at the University of Washington.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade