UCD & Agile

UX Prototyping

Mick McQuaid
mcq@utexas.edu

University of Texas at Austin

09 Oct 2025

But first … Extreme emphasis

But first … Guessing Game

  • How I’d do it differently
    • Initial screenshot instead of actual Figma file
    • Final design as implemented (again screenshots)
    • Narrative about the process and conversations
    • Grading scheme of 3/3/4
  • What do you think?
  • What were your conversations like?

Good things

  • Guideposts for Figma newbs
  • Annotations (mostly callouts)
  • Unicode cheatsheets

Surprises

  • Why did everyone use the default font when that was one of the very variables you could control?
  • Not reading the instructions to the CS students
  • CS students asked Prof Bulko what they “had to do”
  • One CS student complained they didn’t get the design until 2 Oct!
  • One or two of our students didn’t take the conversation about their capabilities seriously

But first … the story of Figma

In September 2022, there was a time when it seemed that Figma was going to be devoured by Adobe and we discussed it in class … It may still be worthwhile to explore the situation as it developed … (We still don’t know whether it was really Adobe or Figma that actually killed the acquisition …) 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

Where is more info about this?

Questions

  • Everybody hates Adobe. Why? (Subscriptions?)
  • Isn’t it possible that this acquisition will fail? (Yes) (Nope!) (Yep!)
  • Might the FTC block the deal? (Unlikely) (It didn’t)
  • What will Adobe do? (retire XD? retire Figma? ruin both?) (using Figma technology on Creative Cloud?)

Speaking of Adobe stock

Speaking of Adobe stock (2nd time)

Speaking of Adobe stock (3rd time)

Speaking of Adobe stock (4th time)

Why do we care?

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

Aftermath

  • It failed, allegedly because Adobe lost interest after regulatory scrutiny
  • Scuttlebutt was that Adobe realized it had overbid, but no one knows—Figma’s internal valuation is reportedly half of what Adobe offered
  • Figma continues to lead by nonstop innovation, current team is doing really well in my view, not so well in the eyes of others (ny times perspective)

Still later …

  • Figma went public in July 2025
  • Offered at 33
  • Immediately went to 120
  • Slowly slid to mid 50s
  • Starting October at about 53
  • October market cap about 25 billion USD

Figma’s stock practices

UCD & Agile

Intro

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

Compatibility

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

Incompatibility

  • 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

Culture

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.

Teams

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

Summary

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

END

References

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.

Colophon

This slideshow was produced using quarto

Fonts are Roboto and Roboto Light