Unfortunately I can't say what the product is or who its for at this time, but I've started down the road of a new project and seeing elements of the practices outlined in Jeffs article in my first project here. Being the usability/UX/business analyst on the project, I'm going to see how we touch on these 12 elements Jeff outlines as we go through the project..(I'm going to ensure it will be as many as possible heh heh)
In keeping with practice 1 and 2:
"UX practitioners are part of the customer or product owner team"
"Research, model, and design up front - but only just enough"
(read the article and save me having to re-iterate them eh, I'm lazy)we've:
- Defined our users, the work they are doing, the environment they may use our solution, discussed issues in play creating the opportunity for a solution
- Met and whiteboarded screen flows representing function/user requirements for this product based on tasks we've established for product x.
- Added priorities by tagging them on each screen or function area
- Stood back and agreed that was the main flow and function set we wanted to embark on.
- Took photos of each screen in the flow on my mobile phone
- Transferred them via blue tooth onto my laptop
- Imported them into Axure pro, wired up interaction, dialogs and controls, (I love that you can do alternative cases also to the same button e.g. behavior of the app according to roles) in a short space of time.
Its easier than flash too ! Whilst it may have limitations for complex interactions, it was quick and easy to start on the gross/overall approach.
The second session was spent exploring the prototype, confirming the scope and additional information (non functional and third party technical considerations) needed for deployment, training, documentation etc etc.
Time elapsed = 6-8 hours and we already have:
- Overall scope
- high level product behavior, user centric interface considerations and functionality
- Less chance of 'but I wanted xyz' from stakeholders as its visible and easy for non techies to grasp a working picture of an artifact not a long narrative where they have to imagine it from
- A sense of flow/whats happening on the application
- Our technical people provided feedback regarding the feasibility of the work at white board stage.
- We avoided a traditional 'requirements' phase where non technical stakeholders would have been engaged first only to have to be returned to once technical people next in line found issues or technical constraints
- We also noted the additional 'back end'/platform and hardware factors raised by out techs that will also have to be elaborated on in future iterations.
I expect developers and stakeholders to give input as we elaborate each area in the subsequent execution of iterations required to develop and test the application a la agile process.
Now we're on to getting estimates of functions development effort and breaking the overall application into nice agile like chunks.. practice 3 beckons...(not that I'm saying its going to be sequential :)
Facilitating the upcoming sessions, yours truly should ensure that the elaborated designs are still usable, useful and on track. I want to start with user stories/scenarios to elaborate each area.
Benefits of participatory sessions combining stakeholders and developers in agile approaches include:
- Developers/programmers/designers can contribute and not feel they are being told to' just do it' according to the specification or interface mock up after the fact.
- Hopefully there will be less chance of subversion of the design during development by personal opinion, technical constraints or 'exploratory diversions' during coding because developers are involved in the modeling and agree to the direction there and then (or for ever hold your peace).
- Stakeholders can confirm requirements seeing them in the form of flow and functions in a prototype/model. Less room for interpretation of a narrative (really, how can a narrative explain an application that lives in a non linear way)
I'll let you know how it goes.. hopefully with elements of Jeffs outline on workshops and in keeping with 'agile' principles, we'll be light on documentation. Hopefully the artifact will be the 'specification' for the most part. (Axure also does some documentation generation, lets see if we need it).
Some UML sequence diagrams of back ground messaging may be needed. Use case diagrams and use cases can document complex interactions for developers too if we again, need it :)
We'll round this off with some user testing of the model and hopefully pre-deployment .. that's the plan at least..
This weeks work was fun, fast and my tech and non tech stakeholders reported finding it valuable.
Have a good weekend ..
So potentially:
workshop+stakeholders+tech reps = screen shots + axure + interaction +demo = all agreed on high level scope (functions) and flow (interaction): Agile requirements are go!
