- News
- Overview
- Archive
- 2011
- 2010 Subscribe RSS
ERGOSIGN Blog
Agile & UCD – Best Practices
With more software projects cascading down the waterfall (pun intended), agile software development principles have grown more and more in importance over the last years with the goal to make software development more lightweight and adaptable to ongoing changes (budgetary- and functionality-wise).
As implementing agile techniques for a project has major influences on the way management and development teams are working, it of course also has influences on UCD activities and the way they can be applied during an agile project.
This adaptation varies from project to project to fit the customer’s needs. These adaptations can range from designers working closely together with the development teams on-site to an on-demand designer who receives the requirements from the project teams and delivers the wireframes or screen designs accordingly. This really depends on a couple of factors that need to be decided per project (e.g. product enhancement vs. new development, in-house expertise, co-location or availability of users).
Process Information
Figure 1: Schema of the design and development track working together in parallel.
The agile process requires UCD techniques to scale according to the process. In the available documentation on the internet [cf. Further Reading] and also from our experiences it has proven to be essential, to prepare iterations in advance so that at least a rough GUI sketch is available as a ‘lightweight guideline’ for the iteration to start. This has the big advantage that this can already be used as a basis for discussion within the teams and with the product owner or even for doing paper prototyping with users to validate designs even before a line of code has been written.
The duration of this iteration preparation phase depends on the comprehensiveness of the overall vision that has been established at the beginning of the project because it might heavily influence the design of the UI for the iteration (e.g. should the UI be represented in a dialog or a drawer?).
We would strongly advise to use the “cycle 0 phase” at the beginning of the project to produce a visual representation of the vision on a wireframe basis that can be used as a central theme. Especially if you are working with different teams in parallel this will lower the risk that they will run into consistency issues and in different directions. However, this vision needs to be reviewed frequently to ensure that it is still valid or adapted where necessary.
Composition of Teams
As mentioned before, the composition of teams can vary a lot depending on the project’s circumstances. But the most important thing is that there is a GUI responsible person included in every team.
As can be seen in figure 1, depending on the stage the project is in, there can be quite some tasks that are running in parallel with regard to designing, researching and testing.
Figure 2: User research support group
This can be compensated with a ‘second line’ User research support group (cf. figure 2) that takes the questions from the teams, clarifies the issues with users and reports back to the teams. This way, the support team will also have a good overview about the different UI projects and it can use their connections to the user community to organise some lightweight usability testing.
Design-Scrum-of-Scrums
Additionally, a design-scrum-of-scrums has proven to be very good to keep track of different design solutions within other teams, meaning regular meetings after the teams’ stand-up meetings with the GUI representatives of these teams. It’s a good way to inform the designers about newly built components, layout issues or problems with the overall vision that can then be adapted according to the input of the teams.
UCD deliverables & tasks depending on the level of the project
In some of our projects so far, we have used a wiki as a possibility to store information about the overall vision, the different projects and decisions that have been taken. It can also be used to incrementally build up a collection of guidelines that can be reused for further designs within other releases as soon as certain aspects of the user interface are fixed (e.g. icons, colours, patterns).
The following sections will dig a little deeper into the UCD deliverables depending on the level of the project.
Project Level
Although users are foreseen to be included or consulted frequently for lots of agile methodologies, it may sometimes be difficult to get day-by-day access to them or one user carries the burden of representing the whole user community which one user cannot sufficiently do.
UCD activities like a user task analysis helps in understanding how users are actually performing their tasks and can help the project team to gather the requirements for the project.
The gathered requirements can then be used to create a first wireframe version of the new tool that can be used to communicate the vision within a company but also to early verify certain UI concepts with users. It should focus on the overall structure and interactions of the user interface. The information represented in the wireframes can then also be used to gradually chunk the overall tool down into pieces for the different releases and iterations.
Figure 3: Generic example for a high-level mock-up
Release Level
The information provided by the vision wireframes can now be used, adapted and elaborated to find the right scope and requirements for the project on a release level (e.g. “For the first release we would like to have the navigation area being populated and the available data is displayed in the content area”).
Figure 4: Release mock-up with focus on navigation and content area
This visual representation can also help the development teams in estimating their efforts to build such a solution and the product owner to prioritize features.
Iteration Level
For every iteration of a release, the wireframe can now be broken down into several pieces and be described in more detail.
Figure 5: Iteration Wireframe with additional information
Wireframes on an iteration level should be treated as a way to document design decisions in a lightweight manner. It has proven to be very efficient to print out screenshots and put them on the ‘agile wall’ of the project team. This has served as a great gathering point for discussions on the tool.
When the design is finalised for the iteration, the designer can then invest time in producing the required assets like icons or any other kind of graphics. If decisions are taken that influence the higher-level mock-ups, this should be communicated to the design team and adapted where appropriate.
And of course not to mention the preparation of the next iterations with regards to user research (cf. figure 2) and wireframes (cf. figure 1).
Conclusion
Maybe the main conclusion we gathered within our experiences with agile projects is that there is no exclusive way of conducting an agile project. Both methodologies have to adapt to find the best way of interacting with each other. These adaptations strongly depend on several factors such as product enhancement vs. new development, in-house expertise, co-location or availability of users.
From our point of view, UCD methods such as a user/task analysis at the beginning to gather requirements, creating wireframe mock-ups to validate and test concepts at very early stages and our experiences with testing software at several steps of the project can bring real value to the process of developing usable software in an agile manner.
If you would like to get in contact on how UCD activities can bring value to your project, please don't hesitate to contact us at contact@ergosign.de.