In the context of ICSE’19 Software Engineering and Education Track (SEET), I presented a paper on Dual-Track Agile in Software Engineering Education [1]. The presentation focussed on two questions:
(1) Why do we need to teach Interaction Design (IxD) to Software Engineering (SE) students?
(2) How could we teach IxD while staying away from “Big-Design-Up-Front”?
This post addresses the first question, while another post addresses the second question.
As a short answer to the first question (Why do we need to teach IxD to SE students? ), let me borrow a quote by Bill Buxton from Microsoft Research: If we don’t teach interaction design, our students “might get a sub-optimal design right, but will almost never get the right design” [2].
Exploring Alternatives
One underlying reason given by Buxton [2] is the fact that interaction designers explore various equality viable alternatives before fully developing one idea for the solution (as illustrated in Figure 1).
Fig. 1: Explore various equally viable alternatives [2]
Exploring alternatives is not typically done in SE, where we tend to fixate on the first idea that comes to mind.
Note about Agile: The fact that the Agile Manifesto [3] values working software and delivering software early only reinforces the “idea fixation” behavior.
Co-evolution
Another underlying reason is the fact that interaction designers refine their understanding of the problem (or opportunity) and their understanding of the solution at the same time (as illustrated in Figure 2). For instance they use sketches, which have been shown to be a very effective way of reflecting on both the problem and the solution [4].
Fig. 2: Co-evolve problem and solution spaces
Again, co-evolution of problem and solution understanding is not typically done in SE, where we tend to by-pass the creative process by going directly from the problem to writing requirements (like user stories).
Note about Agile: Agile’s short iterations support co-evolution by providing repeated opportunities to review the solution. However, if we think about what typically happens during a Sprint Review for instance, the discussions are often in the solution space, and about accepting the requirements (like user stories), with few opportunities to refine the understanding of the problem.
A direct implication is that we should generally hold off writing detailled requirements until after the creative process has generated a concrete idea for the solution (i.e. a solution concept). Only then, requirements (like user stories with acceptance criteria) should be created to decompose the solution concept into small chunks for implementation. As a positive side effect, having a concrete idea for the solution makes writing those user stories fairly easy compare to writing stories in the abstract only based on a potentially sub-optimal understanding of the problem.
Conclusion
Interaction design supports creativity. It encourages students to explore early solution concepts so they can deeply understand the problem (or opportunity), select the best alternative, and hence create the right solution.
The outcome of the creative process is an innovative solution concept. Detailled requirements, like user stories with acceptance criteria, should generally be created only after the generation of the solution concept. They should be created as a mean to organize the implementation work versus a way to imagine a solution.
References
- [1] Cécile Péraire. “Dual-Track Agile in Software Engineering Education”, 41st International Conference on Software Engineering: Software Engineering and Education Track, ICSE-SEET (2019). Available online.
- [2] Bill Buxton. “Sketching and experience design”, Stanford University Human-Computer Interaction Seminar (2007). Available online.
- [3] Manifesto for Agile Software Development (2001). Available online.
- [4] Bill Buxton. “Sketching user experiences: getting the design right and the right design”, Morgan Kaufmann (2010).
