Applying a Startup Environment and Developer Principles to the Library UX Lab

The Agile Manifesto is a collection of values and principles created to help guide software development. The Agile manifesto was written by software developers, computer scientists and developers during the winter of 2001, as a way to place an emphasis on people, in software development. At its core Agile consists of these four key values:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The purpose of the Agile Manifesto is to promote team collaboration and iterative building, over siloed work groups and complex deliverables. As Agile projects are designed to create new work quickly, many developers and UX researcher have run into problems when attempting to incorporate UX research into an Agile project. Due to these concerns and the popularity of Agile software development, UX researchers have created modified approaches to traditional UX workflows in order to create systems that allow UX researchers to work alongside Agile developers.

Two different approaches to UX in Agile and other quickly iterative processes have been coined in the past few years: Lean (Startup) UX – which was inspired by The Lean Startup, a book by Eric Ries – and Agile UX. Although devotees to each approach find these flavors of UX research to distinct from one another, they both share a focus on fully integrated UX research throughout a project (and after a project’s initial completion), iterative testing and design, as well as small team groups. For the purposes of this essay I will be discussing Agile UX, although Lean UX is another similar and powerful approach to performing UX research.

Some supporters of Agile development processes who do not utilize UX researchers throughout their development process, rely solely on A/B testing. Agile UX does not oppose A/B testing but a instead suggests supplementing A/B testing with usability tests throughout the lifespan of a project. A/B testing is helpful when choosing between two or more designs or design choices, however this form of testing can often require a lot of work on the part of developers and designers and can leave many questions unanswered. If a team decides that they are going to perform A/B testing on three distinct landing pages, this will require designers and developers to create three fully functioning landing pages, two of which will most likely be discarded after the A/B testing. Additionally, the team now knows which of their designs was the most popular, but they are left to guess or analyze heat maps in order to find out why. This means that when redeveloping a separate part of the website, interface or app, the team will need to start from scratch again, testing and analyzing different designs through A/B testing, or worse — they won’t perform any usability testing at all.

The iterative, fully integrated approach to UX advocated for in Agile UX helps teams to understand their users, over understanding the impact of their designs on users. Where A/B testing can show which design is more popular, iterative testing can help a team to understand better what their user group wants and needs therefore limiting the need to redesign or scrap a project after it has already be fully developed. This iterative process, which places UX researchers in small teams with developers and graphic designers, also means that usability tests for portions of a project can be scheduled in advanced and that different sections of the app, interface or website can continue to be tested on a regular schedule even after the launch of the project. Furthermore, through making usability testing a consistent element in the design process, all of the small teams and groups that make up the larger project team can request that usability testing be performed on all of the various elements of the design or larger project.

In order to allow for this process to still be agile and quick, the deliverables that are designed and presented in Agile UX projects are often very different from the deliverables found in traditional approaches to UX. Agile UX researchers have created different templates and guidelines for their teams, which range from text based documents to sketches and wireframes all the way to high fidelity prototypes. What unites all of these different deliverables together however, is that they are created to be utilized within the small development groups working on the project. Due to the fact that these deliverables are used internally amongst team members who are all working towards the same product the focus of these deliverables is communication – and often speed – over attractiveness.

Agile UX’s focus on team member collaboration and end user needs, as well as the processes’ commitment to iteration and continued (scheduled) UX research after a project’s initial launch could transition well into implementation a library lab setting. Agile UX, as it exists in the Agile Software Development Universe, pairs UX researchers with information architects, developers, content creators and designers therefore enabling small, diverse groups to work together towards a united goal. Many libraries rely on a number of different offices, volunteers, patrons and specialists working together to finish projects. In an academic library, the library’s web presence and digital projects might require the collaboration of IT, librarians, graphic designers, archivists, student workers and professors. Through utilizing an Agile framework and implementing an Agile UX workflow, all team members — regardless of their expertise or level of commitment — can have access to usability testing, and the UX researchers placed in smaller groups can help to mediate between the software and content development portions of a project.

Library makerspaces can also invite individuals from diverse backgrounds to collaborate together on projects, or project upkeep utilizing Agile UX. Due to the speed of development and testing in Agile projects, it would be possible for these small groups to meet on a weekly or monthly basis to address, test and potentially answer a design problem or need together. Additionally, makerspaces could work towards a larger, longer project by utilizing UX researcher/librarians as the backbone of the project. Developers in residence could moonlight on the project, add to published projects and test their ideas throughout their residencies with the UX team.

Library labs and makerspaces are already helping to bring together diverse communities of scholars, makers, developers and designers. The potential to combine these efforts while promoting and making usability testing available would help to ensure that library produced applications and websites be held to the same standards as non-academic projects. Another exciting potential for academic library labs would be to connect with digital humanists, professors and students to create digital humanities and cultural heritage projects that would be developed to answer the needs and questions of scholars and students from within the academic institution. Alternatively these groups could also work together to design and create tools to be used and shared throughout the digital humanities community, something that is already occurring at Columbia University’s digital humanities program.

Bibliography:

Guo, F. (2013, November 20). Create Great UX in an Agile World by Conducting Lean UX Research. UX Magazine. Retrieved December 2, 2013, from https://uxmag.com/articles/create-great-ux-in-an-agile-world-by-conducting-lean-ux-research

Little, A. (2013, October 13). An Answer to the Pains of Integrating Agile and UX. Boxes and Arrows. Retrieved December 2, 2013, from http://boxesandarrows.com/an-answer-to-the-pains-of-integrating-agile-and-ux/

Manifesto for Agile Software Development. (n.d.). Retrieved December 2, 2013, from http://agilemanifesto.org/iso/en/manifesto.html

Ocamb, S. (n.d.). What Does the Agile Manifesto Mean? – Scrum Alliance. Scrum Alliance. Retrieved December 2, 2013, from http://www.scrumalliance.org/community/articles/2013/2013-april/what-does-the-agile-manifesto-mean

Principles behind the Agile Manifesto. (n.d.). Retrieved December 2, 2013, from http://agilemanifesto.org/iso/en/principles.html

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 870 other followers

%d bloggers like this: