Read time 4 min
A look at UI design in agile projects at CHI 2016 in San Jose
Are agile and UX fundamentally incompatible? If not, how do you design UI/UX in an agile project setting? Last week, to share our experiences on the matter, we gave a course on UI Design in Agile Projects at the CHI 2016 conference in San Jose. Here’s a look at what we discussed.
Design creates a great framework for agile
Actually, agile methods benefit significantly from UI design: creating a backlog is easier and faster when it’s based on UI designs, which in turn are based on observing and interviewing real users.
We use the GUIDe method to “derive” the design from the realistic, observed user cases. Since every feature can be tracked back to a real user need, disagreements on features are no longer an issue.
But, when to create the UI designs? And how should they be communicated? And how should the designers work? We have tried out several ways.
Over 10 years of experimentation
We started with a design-implementation waterfall in 2005-2007. The UIs were done iteratively: finding out needs, creating design, and evaluating them with users. The converged design was documented in a UI spec, which was split into a backlog and implemented with agile methods, typically Scrum.
The UIs served users pretty well, but only in cases where the understanding of the design was transferred correctly to the developers. There were a lot of communication problems, since the design team worked at our office and the rest of the team at customer premises. It didn’t help that one designer could be working on 3-6 projects at the same time.
In roughly 2008–2010, the designers started working mostly at team premises. This boosted communication with both the customer and the team, and improved communication reduced the need for comprehensive UI documentation. More importantly, the implemented UIs were significantly better, since the developers were more involved and grasped the ideas behind the design.
Things got even better around 2010, when designers became full-time team members at customer premises. Design and implementation were still a 2-step waterfall, but the results were better. In fact things went so smoothly, that we started seeing problems in a new direction: the business.
Not always purposeful
Sometimes the work just didn’t pay off: the smooth implementation of an efficient UI with beautiful graphics wasn’t always worth the money. There could be a competing less refined system available for free, which was more popular than the one we had made, for example. It dawned on us that a Product Owner, if there was one, can’t perhaps give us all the answers. And even when she can, the answers should be verified somehow. Even more, sometimes it would be better to refrain from building more software.
To better understand the business, some teams started to apply methods from Lean Startup around 2011-2012: pivots, MVPs, doing simplest things that work.
Early versions of the software were put in the hands of the end-users and the users’ behavior was analyzed to get more insight and knowledge. Software was no longer built to cover rare cases – the users were encouraged to send email to the team instead, and a team member could then write the relevant things directly to the database, for example.
The multidisciplinary teams used all the skills necessary – design, implementation, coaching, data science, … – to get the users’ and customers’ problems solved with the least amount of money.
Design’s new realistic role
This had a dramatic effect on design: a design that is enough to make an experiment is far from the “final” one. When the software is released constantly, everything is as final as it gets: the design, the code, everything. If a less-than-optimal UI is enough for the users, there is no incentive to make it better, until it becomes the most pressing problem in the software. And though design must still precede coding, there is no longer any point in doing a lot of it in advance.
The waterfall has now been replaced with a short loop of field studies, design, evaluation, implementation, deploying and watching for the signals gained from real use. The design is still the map of the project, but it’s drawn with only a short radius from wherever the current position is.
We’re continuously looking for better practices, but so far we can say that we’ve learned at least four things:
- Design brings great value as an addition to agile software methods
- “Designers in a team” are so much more than “a design team”
- POs aren’t always as necessary as you would think
- Small and continuous experiments help maximize efforts
A big thanks to my co-instructors and co-writers: Toni Strandell, Marju Kettunen, Mikko Romppainen, and Tuomas Husu.