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

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 (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 Sprint planning, The development team agrees on stories, fidelity, goals, and “doneness” for the sprint.

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

The most difficult concept to grasp, if you have been following other Agile methodologies, is that Stories are simply workflows that you continue to iterate on until the MVP is released. In this model, “fidelity” — as well as “MVP” — is something that the team talks about in any discussion, to determine if their discussion is in scope or not. ALL development work is focused on the same fidelity, at any given point in the project.

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

Before Development Begins: Defining the Project

Overview

No project starts development as a blank slate. While it may be ill-defined or not documented, you can tease out:

• 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?

Deliverables

Often, what you end up with is both vague and ridiculously broad in scope. It is up to the development team to translate this into:

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

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

Pageflow Fidelity

Overview

The purpose of this fidelity is to have a working product that simply allows QA to test the workflow, navigating from page to page and seeing the essential information on each page. This should be a working build that looks similar to the traditional pageflow diagrams that a UXD would create. There is no designed layout to the information, but semantic layout should be established (if it is obviously an ordered list, then code it as such!).

Deliverables

Design needs to understand and articulate the user workflows implied by the sprint stories. These serve as critical artifacts to get the entire team on the same page as to what specific value the product is providing to the end-user. We define these user Workflows as decision-action diagrams that map the perspective of an audience in trying to achieve a goal, absolutely independent of implementation.

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.

An example Workflow Diagram.

Example of a Pageflow. This is what is built out in real code, and iterated upon in subsequent fidelities.

Wireframe Fidelity

Once all stories for your release candidate are at Pageflow fidelity, you are ready to level-up to Wireframe fidelity.

Overview

This fidelity is about IA and page layout through the Workflow depicted in the Story. You iterate quickly on the way information is displayed and the content (don’t use Lorum Ipsum), and you create your page layout and heading structure. Again, focus on semantic code and simple solutions.

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.

Deliverables

As always, we try to keep this simple, as we know we’ll be able to iterate across it at a higher fidelity. While other documentation might be needed to communicate ideas to various team members, the only real deliverables are:

• 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

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

The following fidelities are all about refinement and optimization, finding gaps in your quick first pass and bridging them.

Overview

There is UI already in the product at this point. It should represent the simplest semantic implementation of interactive elements. This phase is a chance to think these interactive elements through usability, which includes establishing validation and fail cases and alerting on them. Think the UI through ALL forms of interaction, so optimizing for keyboard, touch, voice, and screen reader are all on the table. At this point, there should be a lot of negotiation around introducing complex implementation, and the burden of proof should be squarely placed upon the people proposing the complexity (Design or Engineering).

Deliverables

Again, the only deliverables are:

• 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

Overview

Narrative is focused on flushing out content to present the user with a refined narrative as they move through the product. This is about ensuring that the content, visuals (iconography as better way to convey certain information than text for certain audiences), and code are presenting a consistent narrative. Code narrative is another chance to ensure proper semantics are being communicated, as well as looking for gaps in the A11y narrative of your product and using ARIA and other screen reader-only narrative elements to fill them.

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.

Deliverables

The only deliverables are, once again:

• 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

Overview

At this point, there is visual design already established — in your baseline styles; in taking a pass on the visual narrative; and through quick decisions made throughout the development. So, once again, this fidelity is again about refinement, including finalizing iconography, font choices, branding, content styling, etc. In kicking off this fidelity, you should be in negotiations with the PM/PO around time that they are willing to allot to this effort and the fidelity of visual design that they (and other stakeholders) are expecting, tempered with Design’s understanding of what end-user expectations might be. As always, Design should be aiming for what will satisfy MVP.

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.

Deliverables

Other than any visual design documentation (mood boards; screenshots of Firebug mockups; etc…) that the Designers might use to communicate ideas to stakeholders and users to generate feedback, the only deliverables are, once again:

• 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.

Conclusion

In practice, this process solved many of the development team’s frustrations and problems. Engineers, Designers, and QA who worked on the first project using this framework found the project “fun”, even a “pleasure to work on”, and — most importantly — a way of working that finally felt Agile.

• 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.