Agile User Interface Development

I came away from a DevCSI workshop: paper-based agile design techniques beaming with ideas. The workshop provided a useful introduction to agile methodologies and card-based techniques. Agile techniques are relevant to UX2's development of library systems and user interfaces, which are mainly working prototypes for evaluation purposes. Adopting an agile method seems logical. In a previous post, I described the work on an open source library user interface. The prototype has since been evaluated through a usability test involving a group of users from the University of Edinburgh. This post discusses the agile method introduced at the DevCSI workshop as a plausible development framework for UX2's UI development following the usability test.

Scrum and User Stories: Yes?

The DevCSI workshop introduced Scrum, a widely used agile software development method. User stories (see an example below) is a core feature of Scrum. The workshop provided useful discussions and hands-on experience in creating user stories. During a hands-on story-writing session, participants (acting as a part of a Scrum team) were given the opportunity to brainstorm, write, discuss, group, sort user stories for a fictional software (and hardware) development scenario. In a subsequent group session, the concepts of product/sprint backlog (sprint ~ development iteration) and velocity (estimation of development capacity per sprint) were introduced. Using the user stories created in the group session, we then devised a fictional product backlog and estimated the content of a first sprint backlog.

Figure 1: A user story from a UX2 focus group meeting on mobile library app development

An impression I gleaned from the workshop is that both Scrum and user stories are relevant to open source system development. Indeed, agile methodologies and open source system development share many common characteristics. In particular, both advocate frequent and iterative delivery of working software. 'Stories' is also an emerging field in user research and experience design.

Some of the UX2 technological developments have been agile in essence. There is an emphasis on working and often low-fi prototypes so that we may elicit user feedbacks. Additional features are developed every few weeks, similar to having sprints in Scrum. During a recent development iteration, a mobile web version for our library user interface was created because we wanted to undertake a 'mobile web vs. mobile app' study. The work was hastened and completed in less than a week so that we can provide a working demonstrator with basic search UI. Additional features of the mobile library UI are currently being introduced progressively.

Sometime, results from user testing may lead to modifications and new features. These were prioritised through discussion about what can be realistically achieved, the extent of usability issue and development feasibility. This prioritisation is analogous to sprint backlog planning in Scrum. During a guerilla testing session, we discovered that users would prefer an additional author filter option in the faceted search UI. After a brief discussion, we decided that the feature should get prioritised and implemented immediately because the work only requires re-indexing (Solr search index) and changes in configuration (UI and Solr index schema). This is equivalent to assigning a story of low story point to the sprint backlog in Scrum.

Adopting Scrum therefore seems logical. First, it provides a systematic approach to consolidate the ad hoc project development. Second, the method's artefacts such as user stories and product/sprint backlog would improve communication among the project team and dissemination in general. Third, with most infrastructure work out of the way, the majority of late UX2 development involves UI enhancement which can be accomplished in shorter iteration cycles.

But the Caveat: User-Centred Design

However, there are several issues related to user-centred design (UCD) which need to be considered if we were to adopt Scrum:

• Open source (third-party) system adoption
• User research, usability and usefulness studies
• User interface and experience design

Confronted with deadlines and budgetary constraints, most public-funded projects such as UX2 adopt off-the-shelf open source systems (OSS). How would a Scrum team derive user stories from existing third-party systems? OSS use cases, feature list whilst useful, are unlikely to provide the contextual information required by user stories which should be derived through user research methods such as contextual inquiry, interviews and focus groups. Also not all features from the adopted software are useful. How about missing features? The answer to these questions may depend on user-centred design (UCD) tasks viz. system decontextualisation and user studies. The former decomposes OSS and user interface into quantifiable units - interaction design patterns - viable in analysis and various forms of user studies. A lead-off usability test in sprint 0 or earlier may also enable users to convey preferences and identify usability issues in existing OSS and UI, to be fixed or enhanced using the Scrum method. User research techniques such as interview, focus group meeting and diary studies may also be employed to determine the usefulness of a particular aspect of the OSS, perhaps leading to the dropping of useless features.

Testing in Scrum is closely tied to software development, i.e. unit and functional testing. I have not come across a particular agile method that explicitly addresses the broader evaluation requirement of UCD. Moreover, UCD tasks can be ad hoc, formative and summative. Guerilla testing is an example of formative evaluation; it is an agile and low-cost form of usability testing, involving quick, sprint-like and informal tests with limited scope. Such testing can result in additional development requirement (new user stories) in the product backlog, anytime during the development cycle. On the other end, a user study can be longitudinal, for example a diary study tracing user interactions with a system may span several development sprints.

Scrum is also light on upfront design. It lacks clear methodological support for user interface and interaction design. Similar to (unit) testing, design in Scrum is implicitly tied to software implementation in a 'design-implement-test' cycle which happens during a sprint. In contrast, UCD may entail global branding, product concept development and layout design (e.g. BBC GEL). UI prototypes of a particular user story may be shown to users prior to implementation for usability and usefulness evaluation. Consider this user story - "as a library user I want to search the library catalogue so that I can find books on a reading list for course XYZ". There are many plausible ways of interpreting this in terms of UI and interaction design!

Adapting Scrum for Open Source UI Development

A quick exploratory research on "agile user-centred design" led to a few observations. First, there is a general advance in embedding user-centred design, in particular the use of discount or guerilla usability testing in agile methods. But there are still considerable practical challenges if the practice were to become widespread and ingrained, e.g. automating GUI testing (cf. unit testing). A scan of the current literature revealed relatively little information and case studies about embedding UCD in Scrum.

However, there is an emerging Agile UCD approach. The method have been described in various sources such as the Nielsen Norman Group's Agile Usability report and the Succeeding with Agile (Scrum) book by Mike Cohn. Both cited a method first proposed by Lynn Miller and Desiree Sy (JUS, CHI'09). This method involves a parallel User Experience (UX) or UCD track which is in-sync with agile implementation (see a diagram of the parallel tracks). Recently, I attended a course on (Agile User Experience and User-Centred Design), a similar method was also discussed. The following figure shows an implementation iteration in the Miller-Sy method with corresponding UCD tasks: user research, UI design, usability testing.

Figure 2: A single implementation iteration (other iterations not shown) + corresponding UCD tasks, Miller-Sy method

The key concepts of the Miller-Sy method are:

• Chunking of UCD tasks (research, design, usability testing), base them around an agile implementation iteration.
  • Progressive user research: conduct user research such as focus group and contextual inquiry 2-sprint ahead of implementation.
  • Just-in-time design: create and evaluate UI design chunks 1 sprint ahead of implementation.
  • Dovetailed usability test: conduct usability test on implemented UI immediately in the next sprint.
• Progressive: low-fi to hi-fi usability testing and contextual inquiry.

I find the granularity changes and the progressive nature of this approach interesting. For example, large design is deconstructed into smaller and manageable design chunks. This resonates with our evaluation and development of interaction patterns in digital libraries. Formative usability test is conducted initially on these low-level design chunks (low-fi prototypes) with internal users, e.g in 15-minute tests. This enable a steady stream of appropriate designs to be fed into the development. Meanwhile, user research is spread through out the agile cycles, providing richer and holistic contextual information as the development progresses. The fidelity of usability testing also increases through the gradual refinement of test tasks and activities, from early in-house testing of low-level designs with internal and would-be users, to summative usability testing sessions and longitudinal studies with actual users. The method also suggests data gathering in cycle-0 to refine existing product, cf. the usability tests on open source UI conducted in UX2 prior to enhancement work.

However the Miller-Sy approach seems resource intensive. Each implementation cycle requires UCD resources in preceding and following iterations. Because implementation happens in every cycle, a UCD iteration will eventually involve various research, design and usability testing tasks, each corresponds to different implementation purposes. This requires significant management efforts. To remain two cycles ahead of implementation, the research tasks also depend on forward planning, but cycle planning in agile methods tends to mainly focus on the next cycle. The ways with which the UCD parallel track 'wraps' around software development implies that the latter could assert independency and progress autonomously unless UCD interests are communicated systematically and frequently. This coupled with the resource demands increases the likelihood of a separate dedicated UX team being created. But a single cross-functional team is crucial to Scrum.

UX2 Approach and Retrospective

For a small Scrum team working on open source systems with limited resources, I would adapt the Miller-Sy approach by integrating the parallel tracks as shown in the figure below. The integration decouples the following key characteristic of Miller-Sy from the '2-ahead, 1-behind' UCD cycle prescription:

A user story (implementation) has associating UCD tasks (user research, design, usability testing)

The integrated approach treats tasks granularity and timing more fluidly, and has the following features:

• A single cross-functional team consisting manager, product owner, usability analyst, UX designers, developers
• In addition to activities in user story creation, sprint 0 should include a lead-off usability test of existing or open source system to derive user stories (see below)
• Several user stories may share the same UCD tasks, e.g. a single usability test/design/research task for a subset of user stories
• Assign points (efforts estimation) to UCD tasks cf. story points for user stories
• Manage implementation and UCD tasks equitably, prioritised according to team velocity during sprint planning meeting

Figure 3: Integrated agile UCD - boonious Scrum

The approach would work well for a team with a high-level of UX maturity, e.g. manager and developers understand the rationales for UCD and may undertake some of the tasks such as UI prototyping themselves. It is also up to the team to decide how strictly they want to assert the association between each user story and the UCD tasks. For example, the team may decide whether the availability of UI design or prototype should become a prerequisite for all or some of the user story implementation. Developers may take up some of the UI design tasks or a dedicated UX designer may prototype a batch of UI design for several user stories in a sprint.

The following is a list of prospective implementation derived from the issues identified in the usability testing of UX2 library user interface, according to severity levels:

High

1. Enhance post-search interaction: cherry-crumbs and search box design (para. 6.1.2 in report), 3 points
2. Improve the visibility of links in item details page (6.2.2), 2 points

Medium

1. Provides results sorting (6.1.3), 3 points
2. Provides date range faceting (6.1.4), 5 points
3. Improve e-books and online resources findability (6.1.5), 3 points
4. Improve the readability of description text in item details page (6.2.3), 3 points
5. Enhance post-bookmark interaction (6.3.2), 2 points
6. Enhance the usefulness of "other links" (6.4.2), 6+ points
7. Enhance look and feel: text size, keywords highlighting, visited links (post-session), 1 point

Low

1. Address the positioning and meaning of technical format (mimetypes) facets (6.1.6), 3 points
2. Enhance language facets readability, using full description instead of codes (6.1.7), 1 point
3. Provide a way to navigate all authors facets - a-z navigation (6.1.8), 5 points
4. Improve the visibility of previewable items in results list (6.1.9), 2 points
5. Improve the visibility of library holding information in item details page (6.2.4), 1 point
6. Provide control over multimedia playback, instead of auto-playing (6.2.5), 3 points
7. Enhance the availability and usefulness of subject keywords (6.2.6), 6 points
8. Provides a recommender service similar to Amazon "customers who bought this also bought.." (post-session), 6+ points

Perhaps the implementation can be called usability stories as these are derived from usability testing. If we were to use Scrum, I would hold a planning meeting to determine the starting velocity, the sprint period and the first sprint backlog. For example, we would begin with a sprint velocity of 6 and implement usability story no 1 'enhance post-search interaction' during a one-week sprint period. This leaves 3 story points for UCD tasks, e.g. UI prototyping and formative testing for this or other user stories deemed more necessary on the list.

But the UX2 project is coming to an end. We are busy wrapping up the final project outputs. There is not enough time to incorporate sustained development sprints to try Scrum out. Moreover, the sprints would have been interspersed among dissemination and other forms of end of project activities (reporting, executing exit strategy). In retrospect, I would adopt the method early in the project and make UCD tasks such as "just-in-time design", prototyping and evaluation key cross-over activities in the team. The project has been constraint by the development scope. The limited resources were spread too thinly on drawn out and 'cycle 0' type of development, in particular to establish open source facet search and social networking infrastructures (reported in this blog). Also we were involved in 'cycle 0' user research such as persona development, contextual inquiry and usability testing for AquaBrowser in a related small project (AquaBrowseUX). A better-managed UX2 should involve a reduced development scope and less upfront cycle-0 activities.

AquaBrowserUX enabled a closer working relationship with the university library, information services and ultimately the library users. It entailed opportunity to gain experience in applying new user research techniques in informal and real-use contexts, all of which is related to agile methods. The synthesised results such as the general knowledge of faceted search and the library personas are useful to UX2. But a downside of working with AquaBrowser: we were diversifying instead of consolidating UCD tasks with the development of our own library user interface. The inception of AquaBrowserUX was a strategic move to counter the lack of local users and the ending of a flagship e-science project which was supposed to provide a test bed for user research and testing. We therefore had to realign technological developments and repurpose the UX2 digital library for library catalogue use scenarios to build a closer working relationship with the university library. That was a situation beyond our control. Ideally, the strategy realignment should not be necessary or UX2 should be run by an organisation with easier access to library users and the intention to develop the library UI through agile UCD.

Nevertheless we are where we are: more enlightened.

Thanks!

Comments

[Dave Land]

In the section “UX2 Approach and Retrospective”, you write:

“ user story (implementation) has associating UCD tasks (user research, design, usability testing)”

Did you mean “associated UCD tasks”?

[Javis Lounsbury]

Data gathering can become easier when a large group is divided into small chunks, as you've suggested. The same goes in the development of a system; let's say for example, a software. As long as all data or consistent and are "reusable", all the data can be integrated to form one big result. Oh, one more thing. I'd like to point out the same thing that Dave Land pointed out. Was that a typo?

[custom essays]

Additional features of the mobile library UI are currently being introduced progressively.

[Robin Bob]

At the writing services it is easy to get some information and custom writing close to this good post . To do better the career buy custom essay papers and use your time of rest!