UX Prototyping
UCD and Agile

Mick McQuaid


But first … Figma

Last semester, Figma was devoured by Adobe and we discussed it in class … Here’s some of what was said …

Figma acquisition by Adobe

  • Should we keep using Figma?
  • Should we switch to Framer or Penpot or go back to Sketch?
  • Should we try to develop multiple escape routes?

What’s the problem?

  • Adobe has a long history of buying companies and ruining / destroying their products
  • Adobe has a direct competitor to Figma
  • Acquisitions in big tech are usually disastrous for the consumer
  • There’s even a tumblr devoted to publishing optimistic statements by acquired CEOs followed by later announcements of closure (https://ourincrediblejourney.tumblr.com/)

Where is more info about this?


  • Everybody hates Adobe. Why? (Subscriptions?)
  • Isn’t it possible that this acquisition will fail? (Yes)
  • Might the FTC block the deal? (Unlikely)
  • The co-inventor of Figma has already moved on. Why? https://madebyevan.com/ (That’s what they do)
  • What will Adobe do? (retire XD? retire Figma? ruin both?)

Speaking of Adobe stock

Why do we care?

  • Reliance on Figma
  • Pace of innovation at Figma
  • Sketch is mac-only (for now)


Most of this material comes from a NordiCHI conference workshop on UCD and Agile, documented in Cockton et al. (2016).

What is UCD (User Centered Design)?

  • When did it start?
  • What was the software environment in which it began?
  • How has it developed?
  • How can it be integrated with Agile development?

Some facts about UCD

  • It started in the eighties, as a result of plummeting hardware costs, leading to the rise of casual users
  • Software engineering at the time was concerned with the software artifact, not users, and waterfall processes dominated the landscape
  • Its initial focus was usability, later defined by ISO 9241 as “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use”
  • The above definition grew and developed over time

Still later, UCD embraced UX

  • UI ⇒ user interface, focused on the human-computer interaction
  • UX ⇒ user experience, more broadly focused on the user’s world

Early Challenges for UCD

  • The phased approach of waterfall methods meant that UCD had to find a place in each phase (not easy)
  • UCD fit better into an iterative approach than a phased approach
  • UCD activities like Contextual Inquiry fit into the problem analysis phase
  • UCD activities like user testing fit the verification phase

Waterfall phases

  • problem analysis
  • requirements specification
  • design
  • implementation
  • verification
  • operation

A waterfall picture

waterfall phases and products

Iterative software development

Iterative software development is a three-part circle

Iterative software development

  • It is less risky, but more expensive, to iterate
  • The iterative process is design, build, test, over and over
  • Why is it less risky?
  • Why is it more expensive?

UCD Today

  • A major approach to UCD is goal-directed design
  • It’s exemplified by Cooper et al. (2014)
  • It’s covered in I320U Information and Interaction Design

Enter Agile

What is Agile?

  • First and foremost, it is a manifesto, posted in 2001, featuring twelve principles
  • Everybody and his brother loved the manifesto
  • Pretty soon, everybody and his brother started saying they were Agile
  • Agile started to lose meaning
  • Let’s try to capture some of that meaning

Agile software development principles (1)

  1. Customer satisfaction by early and continuous delivery of valuable software.
  2. Welcome changing requirements, even in late development.
  3. Deliver working software frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers

Agile software development principles (2)

  1. Projects are built around motivated individuals, who should be trusted
  2. Face-to-face conversation is the best form of communication (co-location)
  3. Working software is the primary measure of progress
  4. Sustainable development, able to maintain a constant pace

Agile software development principles (3)

  1. Continuous attention to technical excellence and good design
  2. Simplicity—the art of maximizing the amount of work not done—is essential
  3. Best architectures, requirements, and designs emerge from self-organizing teams
  4. Regularly, the team reflects on how to become more effective, and adjusts accordingly

What agile looks like

Collaboration between

  • Cross-functional teams
  • Self-organizing teams
  • Users / Stakeholders on the team

Focus on

  • flexibility
  • early delivery
  • continuous improvement

Further reading on Agile

Vastly many agile processes and practices are documented on Wikipedia’s Agile Software Development page, including the following diagram of one attempt to merge the best parts of agile and waterfall.

Unified Process Model

Major Concerns with Agile

  • Cultures
  • Teams
  • Tasks
  • Work per iteration

Agile + UCD


  • evolving requirements
  • incremental development
  • close collaboration with customer reps


  • reduced opportunities for user testing
  • less upfront planning before software implementation

Best practices from NordiCHI

Four themes

The following slides review the four themes that coalesced at the NordiCHI workshop:

  1. Culture
  2. Teams
  3. Tasks
  4. Research


Cultural differences

  • What constitutes a valid problem and what can be ignored
  • What resources are provided and how allocated
  • Adequacy and excellence in design work

Agile and UCD Values, first Agile

  • Self-empowered independent autonomous teams
  • working software that customers accept
  • customer collaboration
  • rapid reaction to feedback
  • velocity
  • visibility, awareness, accountability
  • productivity without interruption
  • clear roles, short term goals (not vague and fuzzy)
  • low waste
  • being fashionable

Agile and UCD Values, next UCD

  • iterative processes and tools to support planning of comprehensive user-focused research and objective empirical evaluation
  • well documented evidence and data analysis
  • understanding users before software development
  • coherent, holistic picture of what will be developed
  • superior expert knowledge of HCI
  • attention to detail
  • satisfied users

Recall the values from the Manifesto

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Note the nature of the four preceding pairs

  • They are matters of degree
  • You should favor the left side, but how much?
  • Crudest solution would be to make the LHS simple rules, as follows

Crude rules that could follow from the four pairs

  1. Just have individuals and interactions: no need for processes and tools
  2. Just make working software and no documentation
  3. Just collaborate: no need for a contract
  4. Just keep responding to change with no plan

Good news about culture

  • Only half the Agile Manifesto rules could block UCD
  • Compromises are possible, even with those
  • Other values, such as safety and security and inclusiveness, are important and outside the possible Agile / UCD tension

Culture and methodology

  • UCD and Agile have disjoint but not necessarily incompatible values. Dogmatic rules on either side may cause tension.
  • Values come from many sources: marketing, creative designers, customer support, security experts. Give user and customer values their own place rather than simply representing them indirectly via UCD or Agile.
  • Conflicts and synergies are manifasted in teams and tasks in work contexts, where the ideologies of methodologies meet the realities of software development work.


Themes relating to teams

  • Roles and responsibilities
  • Team boundaries and communication practices
  • Cross functional capabilities of teams and individuals

Roles in Scrum

  • Product Owner (PO)
  • Scrum Master
  • Team member (undifferentiated by rank or expertise)

Roles vs responsibilities

  • Responsibilities matter more than roles
  • Context makes all the difference
  • No universal prescription for relations between “Scrummish” roles

PO represents the customer

  • Yet the customer may be a team member
  • Customer funding may drive top down decisions

Developers empowered by Agile

  • Breeds distrust by UXSs
  • Leads to attempts to get developers to do UX
  • Tricky to get developers to do UX
  • Takes training and support and management buy-in
  • Mostly favorable outcomes when it happens

Team boundaries and communication

  • Creative design needs problem-solution co-evolution
  • Co-evolution is threatened by daily standups excluding UXSs
  • Pair designing (one UXS and one developer) can overcome this

Face-to-face communications

  • Omitted from most of the NordiCHI cases!
  • Scrum Islands (Chapter 5) was one exception
  • Of course this conference was pre-pandemic
  • Shared language turns out to be key

Scrum Island

Summarizing communication

  • Roles and communication practices matter
  • But individual attitudes and capabilities are the foundations for success

Skipping tasks and research for now

  • Read the task part
  • Skip the research part unless you want a PhD

Chapter 3: Templates

  • Getting developers to do UX via templates
  • Some example templates follow


  • Designers need to better understand the language of developers
  • Getting developers to appreciate UX is the key to blending them
  • Templates seem to work


Cockton, Gilbert, Marta Lárusdóttir, Peggy Gregory, and Åsa Cajander. 2016. Integrating User-Centred Design in Agile Development. Cham, Switzerland: Springer.
Cooper, Alan, Robert Reimann, David Cronin, and Christopher Noessel. 2014. About Face 4.0: The Essentials of Interaction Design. Indianapolis, IN: Wiley.



This slideshow was produced using quarto

Fonts are League Gothic and Lato