Redesigning Sakai tools based on requirements (session planning)
 | New Title?
How about "Sakai UI Roadmap Exercise" |
Inspirations/Purposes:
- There are often design/usability problems that are identified within the Sakai user interface, but then little action is taken to solve them. What if we were able to leverage the design skills/sense of those in the room to either solve a design problem or at least define what is the next step?
- Colloborate on design together and learn from each other
What is a "Next Action?"
As popularized in David Allen's book, Getting Things Done, A Next Action is a task in a project that should next be accomplished to move the project along. The benefit of identifying a Next Action is that it keeps you from being overwhelmed into inaction by a project. Instead of looking at a large project and being frozen into inaction by its size, a Next Action is identified - what is the next thing that needs to be done to move the project along. By identifying a bite-sized task to undertake, you both identify what is needed to progress the project, and since it is small and not overwhelming it you will likely actually do it. After you complete that Next Action, you then identify a new Next Action for the project, which you can then act on, etc., until the project is completed.
Outcomes: The outcomes of this exercise could be varied and/or multiple, but all would answer the question, "what is the next step?". Some potential solution categories are:
- a clearly defined usability/design problem
- list of affected users
- potential next steps:
- a design or design "angle" (part of a solution)
- more user research
- technology enhancement
- usability testing
- backing from the Sakai community
- collaboration between Sakai project teams
- additional resources from the Sakai community, etc.
Design problem sources:
Agenda:
- all together: overview of Roadmap WG and how that fits into this exercise
- Synthesis of existing UX evaluations in Sakai
- Pointer to working document
- Goal is to feed this information back into the Sakai requirements process
- Create new requirements
- Further define, refine existing requirements
- Add relevant design solutions, rationale, etc. to the jira tickets
- all together: frame the time, purpose, outcomes and process
- break into small groups: follow outline provided (Group work will be added to confluence)
- *# Define problem (10 minutes)
- Define user profile (or should we provide Sakai personas for this?) (10 minutes)
- Define primary scenarios (15 minutes)
- Brainstorm potential design solutions (30 minutes)
- Define next steps (10 minutes)
- Create working group?
- all together: report outcomes
