UX Prototyping
UCD and Agile

Mick McQuaid

2/22/23

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?

• Hacker News: https://news.ycombinator.com/item?id=32850178
• https://hunterwalk.com/2022/09/19/why-figma-is-worth-20b-and-other-observations-from-the-adobe-acquisition/
• https://adamnash.blog/2022/09/16/figma-a-random-walk-in-palo-alto/
• https://finance.yahoo.com/video/adobe-figma-deal-ive-never-193650708.html
• https://www.cnbc.com/2022/08/25/figma-growing-inside-microsoft-testing-longtime-deal-with-adobe.html

Questions

• 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?)

Will Adobe get the Figma team? No. Evan Wallace has already moved on. Dylan Field has just been given a billion dollars and asked to choose between sitting in a lot of meetings with empty suits explaining to him why they won’t change their business to suit him OR go pursue his passions. Which would you choose?

Plus, Adobe doesn’t need the team. If they get patents to Figma’s technology, they are set to move Creative Cloud to the cloud for real. Figma runs well on any machine. Does Creative Cloud? It will, soon. I’d buy Adobe stock in a heartbeat right now. No dividend this year, though.

Speaking of Adobe stock

Why do we care?

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

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?

First we’ll talk a little about UCD, then a little about Agile, then both. We can start by answering a few questions about UCD.

(then read the slide)

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

(first read the slide)

In the early days, efficiency dominated the discussion of users as computers were still a scarce resource. Efficiency receded in importance over time while effectiveness and later satisfaction came to the foreground. Satisfaction originally had to be linked to productivity to be justified, rather than being an end itself. Later that changed and context became more important.

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

(first read the slide)

We started with a pure focus on the liminal state between the human and computer, then later thought about context.

Eventually, UCD took on the form we see today, a combination of UI and UX, which takes into account the context of use and overarching goals that may be served by the software.

But first, we have to consider the road UCD took to get there.

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

(first read the slide)

Other phases were harder and the whole arduous process was made more difficult by one of the hallmarks of waterfall: that there’s no going back from one phase to a previous phase. If you find out you’ve taken a wrong turn, that’s tough. This rigidity about phases allows for easier budgeting and accounting and makes waterfall appealing for expensive projects. Line for line of code, waterfall is always cheaper than iterative, although it is more likely to fail because of its rigidity.

Waterfall phases

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

(first read the slide)

Different authors use different names and numbers of phases. In fact, we’ll see a slightly different picture in the next frame.

On paper, this phased approach looks like a good idea. It breaks work up into manageable chunks. The fatal flaw is that everyone signs an agreement at the end of each phase, declaring that they are satisfied that that phase is complete. Hence, waterfall is commonly used when the administrative distance between parties is great. That distance can occur between departments, agencies, or companies. The farther up the food chain you have to travel to resolve disputes, the greater the administrative distance.

A waterfall picture

waterfall phases and products

This picture emphasizes the no-going-back aspect of each phase and shows the product of each phase, which must be approved by all parties before moving on.

Iterative software development

Iterative software development is a three-part circle

Another approach, and the dominant one for small to medium projects, is the iterative approach. Different authors use different names and numbers of nodes in the circle, but they all feature a circle and an emphasis on getting everyone on the same page, often through joint activities. The small boxes list some of the activities.

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?

(read the slide first)

It’s less risky because client and provider have more chances to be on the same page. It’s more expensive because there’s a lot of intermediate work that just gets thrown away: intermediate prototypes and demos that help get everyone on the same page but can’t be used in the actual software product.

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

(read the slide first)

Let’s review the Agile Manifesto to see why it was so attractive to so many people, then talk a bit about measuring Agile development.

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

The Agile Manifesto listed twelve principles, of which these are the first four. Let’s read them.

(read the slide)

Agile software development principles (2)

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

(first read the slide)

The items on this list are intuitively appealing to a lot of people despite little empirical evidence for their value. For example, managers often micromanage because they don’t understand what developers are doing. They require time-consuming reports of little real value in lieu of understanding. Principle 5 seems like a sensible reaction to this phenomenon.

Agile software development principles (3)

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

(read the slide first)

Again, these principles react to overly rigid top-down management of the development process by managers unfamiliar with that process. It sounds good, albeit very expensive. It sounds like it reduces risk.

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

Diagram found at https://commons.wikimedia.org/wiki/File:Unified_Process_Model_for_Iterative_Development.svg

The key issues in my mind are whether the people in charge can say “It’s too early to test” or “It’s too late to change”. If they can say those things, the process is too waterfally. Can a process be too agiley? The Wikipedia article gives a long list of Agile pitfalls.

Major Concerns with Agile

• Cultures
• Teams
• Tasks
• Work per iteration

(read the slide first)

Culture can be a problem since agile is inimical to traditional top-down management.

Teams are often not trained and team roles are not properly specified. Teams may have trouble focusing on the project given other work.

Tasks are often assigned by people who are removed or tasks are assigned too early in the process.

Taking on too much per iteration builds up too much work in progress.

Agile + UCD

Compatibility

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

(read the slide first)

These characteristics of Agile are compatible with UCD.

Incompatibility

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

(read the slide first)

These characteristics of Agile are not compatible with UCD.

On the other hand, Agile means different things to different people, so not all approaches that call themselves Agile face all the same problems. Here we’ll stick with the NordiCHI findings, which are mainstream but not completely pervasive.

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)

Note that the book uses the expression SME to mean small to medium sized enterprises, not subject matter expert, its usually meaning. The book also uses UXS to refer to any UX specialist, evidently including designers and researchers.

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 them
• Templates seem to work

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.

END

Colophon

This slideshow was produced using quarto

Fonts are League Gothic and Lato