UX Trello Template

My go-to template for booting-up a discovery track in Trello

I've been using Trello for quite a while now, some of my boards have earned me free swag direct from Trello. But my favorite, most used board is my UX board. I've spun up a public blank template for anyone who wishes to utilise it.

How it works

There is a template card that you duplicate for each new thing you want to track on your Trello board and cards move through the columns from left to right - with a few exceptions.

The board is designed to manage stories and tasks, not so much epics of work. That means I'm in mine every day updating progress and sharing work.

The Trello columns

My Trello columns are organised loosely from a tiny idea through to something ready for delivery. The aim is to have a validated card with screens, prototypes, accept criteria and basically everything a developer needs to pass over to the delivery track of a dual track agile board. Different teams have a different definition of ready but we aim to have most of that here. I've never directly handed this card to a developer instead a more succinct story is handed to the Developers often in JIRA or another project management tool. Discovery, unlike Delivery, is very dynamic and it's always fast. With that in mind, there are no rules to which way the card can go, if a card can change mid-sprint etc. I avoid recreating cards for the same core story especially if it has been worked on recently. Instead I'll rejuvenate the existing card and amend it to include the latest thinking.

The template card

This card is loaded with all my process queues. Each one is a reminder of the things I should consider for each story.

You don't need to complete every field, they are only cues to remind you have you thought through the card sufficiently.

Detailed breakdown

The template card

Here is the template markdown for you to copy into your own projects.
    High level description
===============================
Enter a high level description about this card
Pretty self-explanatory, succinctly tell the story of the card.

    Stakeholders
===============================
Who is genuinely affected by this solution and should have a say (rather than just be informed)?
Declare which personas will be most interested in this card and which internal stakeholders will be interested in this card. I do this to ensure I don't forget who should be seeing this and why.

    Hypothesis
===============================
- the change that you are testing
- what impact we expect the change to have
- who you expect it to impact
- by how much
- after how long

My hypothesis takes the form of:

We believe that by changing V for persona W they will do X more/less.We will know this to be true if we see a Y% increase in X over Z period.

e.g. We believe that by making the button blue for Early Esthers they will buy more shampoo. We will know this to be true if we see a 10% increase in sales over a 2 month period.


    Assumptions
===============================
State your assumptions here. Include what you have de-risked from previous iterations.
I declare any and all assumptions starting with the riskiest. This helps me formulate the right tests to (in)validate my designs.

    User story
===============================
As a (user persona) I want to (do behaviour) in order to achieve (goal).

This is the short version of the story declaring who the user is, what they're goal is and why they are looking to solve that need. It should always been from the user perspective even if that user is the business.

e.g. As a first time buyer I want to understand the buying process in order to make the best choices possible when buying my new home.

Its worth trying to avoid the solutions here and think about the outcomes. So I try to avoid declaring features like "I want a step by step buying process".


    Invest
===============================
(I)ndividual
----------------
(N)egotiable
----------------
(V)aluable
----------------
(E)stimatable
----------------
(S)mall
----------------
(T)estable
This mnemonic helps you ensure a story is feasible. If you don't know about INVEST and why it might be useful I would suggest you devote just a small moment in looking it up.

    SMART Goals
===============================
Specific
----------------
target a specific area for improvement.

Measurable
----------------
quantify or at least suggest an indicator of progress.

Agreed/Assigned to
----------------
specify who will do it.

Realistic
----------------
state what results can realistically be achieved, given available resources.

Time based
----------------
specify when the result(s) can be achieved.

+ PIVOT
----------------
Outline what will we do if the experiments fail.

Like INVEST this is a framework, this time for declaring the goals of the story. Again if you don't know about SMART, It would be wise of you to look it up.

One of the really important ones that is frequently ignored. When to call bust on a design. Most bad ideas are money pits, people will keep throwing design after design ignoring the repeating feedback. If you can get buy-in from your team declare the point at which you hold your hands up and say let's not take this forward".

Pivoting can be a great opportunity to run a retrospective and figure out what you have learned or what could have gone better. Oh, and it stops you building something you know is going to fail.


    Testing
===============================
Test Design
----------------
Determine what fidelity you need to test with

- open interview
- survey
- card sorting
- low fi mockup
- prototype
- live data prototype
- 404 button
- live test

Test Method
----------------
- Face to face interview
- Remote un-moderated
- Remote moderated
- A/B Testing

Sample size
----------------
Define how large a sample size is needed to determine outcome

Test Duration
----------------
Say over what period this test will run

Moving onto the test portion of the card I think as much as I can about how we can measure this empirically with as little effort as possible. Aka the MVPe (minimum viable product experiment)

Testing

Moving onto the test portion of the card I think as much as I can about how we can measure this empirically with as little effort as possible. Aka the MVPe (minimum viable product experiment)

Test Design

I declare the type of test(s) I will want to run in order to measure validity of the idea. Early discovery tends to be mostly open ended interviews while live products tend to have more granular, iterative and quantitative experiments run against it.

Test method

This goes hand in hand with the above but just reminds me to think about how this will be run.

Sample size

Should really be more granular but here I think about the persona again and how many people will we need to reach in order to get significant results.

Test duration

How long should the test run to get a good sample of representative outcomes. Many of our experiments will be sensitive to time and it is important to consider this. e.g. Don't run a CTA A/B test on an isolated sales day. Unless of course, it's only going to run on sales days.


    Testing results
===============================

Data
----------------
Return data/Links to data from research here

High level findings
----------------
Overview of the data analysis

Outcome & Next steps
===============================
Describe what was learn't and what the next steps should be.
For example:

- Test for longer
- Test with different users
- Change hypothesis
- Change test

Data

Then I include the data I have collected once the experiments have run. It's important to share the source to allow others to interrogate your data.

High-level findings

My short interpretation of the data all things considered.

Outcomes and next steps

It's really important that after every round of testing we correct course before sailing ahead. This is key to be agile and failing fast. It ties in strongly to knowing when to Pivot, but not necessarily throwing in the towel. Most likely this will become the basis for your next Trello card. Note there's no 'build it' in the template. I never as a UX designer decide to build something only advise based on our findings. More importantly, something is never truly perfect so there is always an opportunity to iterate upon it.


Final thoughts on the card template

The card, like this article, is long. It's not meant to be filled out to the letter each and every time. It's there as a reminder of the things we should think about when developing every story. I make an effort only to fill out the sections that will help develop a shared understanding between the team.

The Trello columns

My Trello columns are organised loosely from a tiny idea through to something ready for delivery. The aim is to have a validated card with screens, prototypes, accept criteria and basically everything a developer needs to pass over to the delivery track of a dual track agile board. Different teams have a different definition of ready but we aim to have most of that here. I've never directly handed this card to a developer instead a more succinct story is handed to the Developers often in JIRA or another project management tool. Discovery, unlike Delivery, is very dynamic and it's always fast. With that in mind, there are no rules to which way the card can go, if a card can change mid-sprint etc. I avoid recreating cards for the same core story especially if it has been worked on recently. Instead I'll rejuvenate the existing card and amend it to include the latest thinking.

Opportunity backlog

This is where all the ideas get dumped, all the user needs get collected and anything else that has yet to be prioritised.

Discovery prioritized backlog

These are cards that we have decided we want to work on in an order of priority with the most important going at the top.

Design

This is work that is in the design stage of the process, whether that be a user research survey design or a user interface it all goes here.

Ready for test

Just a buffer for working with Researchers to expose what is ready for testing at any given time. Like a definition of ready the definition of ready to test would be a story that has an emperical test written for it and the assets and instructions on how to carry out that test.

Test/Research

When a collection of stories are in test.

(in)validated

When an experiment has drawn to a close the data is shared and the findings concluded. For tasks, I use this as my 'done' column.

Blocked

I define blocked as items of work that can no longer continue without a dependency on an external resource being resolved.

UX Debt

Much like tech debt this is work we have done that was either a shortcut, a stepping stone or any known inconsistency across the experience. For example updating the CTA visual treatment but only doing it on the new pages is UX debt for the older pages.

Summing up

My workflow is quite basic, Trello lets you move cards forward and backwards to give you the flexibility required and one last note is I periodically archive the list as they become too big.

You can copy my Trello card template and you can visit a blank Trello board with it all included for those who wish to clone it.

TYIT Ltd provides a full stack UX consultancy that designs accessible digital services. We've helped complex organisations like BEIS and DfE achieve digital transformation by running Lean and Agile discovery processes.

Companies House Number

Contact

13 Bright Rd Dunmow Essex CM6 3GU
© Copyright TYIT LTD 2019