The Global design team at OFN have had a few conversations about ‘how’ design could be done across OFN in a way that is:
- More open and understandable to non-designers
- Easy for OSS designers to follow and add too
- Work for the complexity and fluctuating budget of OFN
The process that was ‘agreed’ to put forward here on discourse is below. Please ask questions and make comments, especially if anything is unclear or you have additional concerns or ideas.
UX workflows - What is in our ‘typical design & UX workflow’ and is this what is agreed on and expected? for OFN’s potential Pebbles, Stones, Boulders work?
What is a Pebble, Stone or Boulder?
This is a new(ish) way that OFN is using to describe the size of work that we undertake
Pebble: A very small piece of work that is incidental or not widely impactful to design. This could be a minor UI change, addition or even a design perspective or comment. Time wise this is something that should not take up more than 2-3 hours of thought, investigation or work. A good example of pebbles are design insight on papercuts.
Stone: Larger than a pebble but smaller than a boulder, this might be a piece of work that requires some deeper thought and more than 1 day to investigate, enquire, research, prep, design and present. This could be a relatively simple feature request or investigation. Stones can easily become boulder size if they are all piled together. These are hard to quantify as they likely have some user impact or complexity. They might need user research/testing. @Eriol Fox Put in example issues here. A good example of a small stone is New add-to-cart buttons prohibit buying large quantities
Boulder: These are our big pieces of work that require deep design and user investigation. Think Mobile UX, Network and big problem statements like ‘How do we retain our shoppers?’ These are likely to be projects that take weeks or months of a single designers time and are best done by multiple designers in order to limit bias perspectives. These are going to be projects where there is a lot of assumptions to test, research to gather and understand and experimentation in design solutions.
What if it doesn’t fit?
Work like Unit Prices Eriol thinks are ‘small boulders’ or ‘Piles of stones’ as Unit Prices required deeper investigation into how to achieve the best results across two kinds of users.
Do we use this measurement going forward?
We can if we think it’s useful to quantify what we’re doing size wise. The process for pebbles, stones and boulders share steps 1 and 2 which assess it’s size and potential unknown complications and there fore is the stage in which sizing a task is best done. These sizings can never be fully accurate and foreseeable though and may change size as uncovered. Therefore these sizes as early warning estimation are prudent.
Sizing is really also only useful in the circumstance where two or more team members are managing workload and cycles and as a solo designer on a project sizing is less useful to the immediate design team and process and only really useful when trying to plan for future roadmap work.
This topic is connected to user research, user testing and community involvement questions also.
UX research/testing with users database - Connected to work flow, can we begin to talk about what kinds of tasks we agree need user testing and what don’t, or the process of making a decision on how to allocate time and budget to that.
Note!! This is a UX process that comes after the prioritisation of a project. So in this respect, it is already agreed in some way, by OFN that design time will be allocated to this project.
WIP UX design process
This process largely applies to boulders and larger stones work but not to pebbles.
-
Work is discovered, prioritised and agreed that it will have design time allocated.
-
Design’s first task to analyse the needs of the task. Are there any missing aspects? Unknowns? Assumptions that must be noted and acknowledged?
-
Design should ascertain if any research is needed to clarify and/or support the task. The research should aim to confirm or deny assumptions and fill in any critical missing details from the task. The research can include a few options:
- 1/2 - 1 day of community research
- 1/2 - 1 day of ‘desk research’
- 1 - 2 days of user research
- 2+ days of user research or field studies
3.5. 1-2 days of synthesis of the above research (if needed) → Especially when the conclusions are not obvious. This applies mostly to larger research or ‘abstract’ OFN questions like ‘As a hub manager, how can your relationships with producers and shoppers be improved with technology and specifically OFN’s platform’ (an example).
-
Design should spend time exploring options should the problem need a visual design or UI solution. A minimum of a 1 day up to 3 days to come up with applicable solutions.
-
Designers should have time to confer with each other and ask for design feedback and critique. This can be done async on the design circle channel but is vital for noticing whether the lead designer on a project has missed something vital. Product circle members can also perform this function.
-
Designers may need to create clickable prototype in order to accurately display the process or journey of a design. This can take between 1 day and 3 days to create and complete depending on complexity. Prototypes are usually used in usertesting and also for developers to understand interaction design and action/page flow for users.
-
If a design task is changing a vital part of the tool then there should be community and/or user testing performed on the prototypes or designs. The creation of a usertesting plan, booking in tests and synthesising the findings can take a minimum of 1 week of design time which can include weekends and evenings (out of standard work hours time) to complete user tests.
-
If the user tests unearth medium to large changes to the design task the changes must be discussed and agreed on for this iteration and then steps 6 and 7 can be repeated if we have time. If the tests unearth minimal issues then the design can be finalised for product and development.
8.5: Usertesting synthesis process & presentation. After usertesting has been conducted, notes written, video + audio uploaded to a shared file location the designer should go through a synthesis process of the results against clear and actionable criteria. This can take max 1 day.
-
Design should be available and ready to support product and development as the task goes through their processes to provide any subsequent clarification. e.g Mobile UX
-
After what was a design task has been completed and is released into the live product design should aim to complete post-live usertests to validate whether the task is meeting the goals that it set out to achieve.
This process applies to pebbles
-
Work is discovered, prioritised and agreed that it will have design time allocated.
-
Design’s first task to analyse the needs of the task. Are there any missing aspects? Unknowns? Assumptions that must be noted and acknowledged?
-
Pebbles are unlikely and not encouraged to have deeper research needs beyond the designer understanding what the task is trying to achieve and whether it should not be considered a pebble.
-
Design should spend time exploring options should the problem need a visual design or UI solution. Typically 1 day to come up with applicable solutions.
-
Designers should have time to confer with each other and ask for design feedback and critique. This can be done async on the design circle channel but is vital for noticing whether the lead designer on a project has missed something vital. Product circle members can also perform this function.
-
Any edits or changes based off of design, product or developer feedback should then be actioned up to a number of rounds/time estimate.
-
The pebble task should then be prepared for development via visuals and examples that can be added to a GitHub issue. Design should then follow up with any direct requests or comments on the pebble task.
-
Design should take so time, once the pebble is live in the product, to monitor and test when convenient. Pebbles should be unlikely to cause large UX problems and therefore not critical to usertest.