Tim (it’s a pseudonym, I’m taking the one from the enchanter in Holy Grail), Tim writes to me: “Is it done to merge the role of UI designers and QA?”. That’s UI for User Interface and I put UX in my title, for User experience, and finally QA for Quality Assurance. So the question is: can someone who has responsibility for the user interface, all the appearance, (even beyond when I reformulate by talking about UX and therefore the experience), can this person also intervene downstream to validate that everything is OK (this notably implies the appearance).
Why do I link UI and UX? They’re different, okay okay (mustn’t offend them), but let’s say that for my proposed answer it’s the same.
Tim adds:
- “I like the form of accountability that it engages from the UI designer
- In terms of workload it works well from a project point of view because the UI design workload is mostly at the beginning and QA/tester at the end of the project
- While transferring a (large) part of the responsibility for unit tests to the devs (#TDD)
On the other hand, that means not being able to share UI designers between projects (and since it’s apparently a rare skill…)”
And yes, this Tim is serious, they do TDD (Test Driven Development).
How to answer him? It’s never simple to answer in a so-called agile environment, because, by definition, it’s an environment that doesn’t have ready-made answers. That’s exactly what people criticize about it: not being able to apply recipes to the letter. You have to base yourself on principles and adapt them well to the context. What principles would I call upon here?
Several things come to mind. First, UX or UI people are very close in my eyes to architects (we’re talking about digital, IT here). They have the same flaws and the same qualities. The qualities? They need an overall vision, to see the whole, to imagine a coherent system. Hence the term Design System which is only the expression of that, or IT architecture plans. So they have an appetite for understanding the issues, for having perspective. They have the flaw of this quality: they want to foresee everything too early, too precisely, and even if that’s not the case, when they’ve defined something it’s difficult for them to let go and accept change.
At the beginning of a product (or project) the UI (I’ll keep this one for Tim) envisions their global vision, and through an approach I would appreciate they build the details of their vision as they go. Or, but I appreciate much less: they define everything before the slightest line of code, which will prove to be a real waste of time and a brake on reflection. The UI I like is also capable of being able to change elements, of being able to shift parts of their global vision to something else, for that they’ve built their elements with this possibility in mind. Like an architecture that is flexible enough to be able to remove an element and replace it in its chain.
I come back to Tim’s question. I note or take note of several elements:
Where is the person who carries the product (what we call product owner) in his description I have the impression they’re missing? We can decide that it’s the UI person, but then they become first and foremost “product owner”, before being UI. And that’s what I hear when Tim talks about accountability.
QA? (doing tests, generally business tests, but really not only): there are several schools that clash on the subject. The school I belong to thinks it’s better to test as you go in a robust way (so in an automated way) much more than at the end (it’s more costly). But we can imagine a testing moment at the end of a cycle (and let’s hope the cycle isn’t too long): another question then arises, is it a dedicated team or the one that just built it? Ideally we prefer the one that just built it, they code better knowing they’ll have to correct if they let things pass.
Load balancing at the beginning and end of the project, between UI and QA. Actually that’s not my opinion. Yes the UI will have to get a little ahead (but really not much, and I hope iteratively), and yes we’ll finish with tests when everything is developed. But in my way of seeing things, the best would be for the UI to build as they go the elements and therefore at the same pace as the team, and for tests to be carried out either as you go as well, and for larger scale tests (broader functional coverage), in batches, during the project. So this balancing story could hide a trap.
About TDD: it’s really a good development practice.
I summarize: If the UI person (responsible for user interfaces) also becomes the one who validates at the output, in fact they effectively probably become the product owner, the product owner. Product owner whose role is to define what we want and why and to validate if what we’re building is indeed what they wanted, or that they find enough value in it to say “OK I’ll take it”.
A trap is hidden in this shift if Tim operates it. The strength of good teams is born from the good balance between the one who says what and why, and those who build (who say how). If the one who says “what” and “why” also imposes the “how” on those who build, they annihilate their commitment, their accountability, and therefore really the quality of their work. There are plenty of ways to frame this how because we don’t do just anything of course, but if it’s throughout the project by the product owner that can lead to many drawbacks. The trap is therefore that the UI if they become PO (product owner), will have one foot inside (they build the interfaces, the how), and one foot outside (they decide the what and why). You just need to keep this in mind and in my opinion that’s enough for conversations to go well.
Second trap: what tests are we talking about? I have the impression that Tim is talking about tests like: the appearance, and the functionality are OK. If we distinguish two large sets: “it works well” (it functions, there’s no anomaly, when you press a button something is triggered), and “it does what I wanted” (when I press the button, it’s the right calculation that is performed in the right way), we could say that the “it works” tests are the responsibility of the developers, hence TDD, and the “I have what I expected” tests are the responsibility of the PO. In that case his strategy (UI -> PO) works. We must not forget probably more extensive work by developers on automated tests beyond their code. Load? Response time? End-to-end automated functional tests? But it all depends on the amplitude of the project, or the product.
In any case two clarifications: rights and duties of the PO (also UI), and of the team (of which the UI is part). And a clarification of tests and different responsible parties.
And I arrive at the same conclusion as him. Usually the flaws of UI, UX can be accentuated because precisely they are less numerous and less available than developers. We find this normal, because a) the habit of not working iteratively and incrementally is really very ingrained b) we like to have grand plans and grand rational and false designs to awkwardly reassure ourselves at the beginning. It’s a mistake in my eyes, but well. And so yes if the UI becomes PO, they must focus on one project, one product, because they will have a constant conversation with all team members about everything that’s moving forward (or not) every day. It will probably make them a much better UI/UX because, with their feet in the muck, they will find many more reasons to adjust, not to anticipate, their work as a designer.
When I share this with Tim, he replies:
“So in summary:
- Thanks for the UX/UI correction. It’s true that’s how we say it now
- It’s not usually done
- It’s interesting if you also merge with the PO
- You need to automate load & perf tests
- The UI must remain flexible. 100% agree but in a contractual context I don’t know if you have that flexibility. "
I clarify to him that:
- No not necessarily load or perf tests, it depends on the context, the need, the effort/value ratio.
- If the UX/UI doesn’t take on the responsibility of the PO in what he describes they get too many rights without duties, and it can turn sour (naturally it always depends on the people).
- If the client is involved in the iterative process (they participate in reviews) they understand its value, and welcome change. But yes contractually that implies billing by time spent, and not by result. With these agile approaches the client wins even if at first they’re afraid of the “time and materials” versus “fixed price” side. They can stop when they want.
thanks Tim.