I got a comment on Avoid user interface refactoring
. Andrés Taylor
brought up a few questions, in essence it was:
How do you work iteratively with UI?How do you incorporate new and changed user demands into the upfront UI work?How do you give developers enough UI vision to work on?
Now this is getting interesting. I am convinced that there are a way to combine upfront and agility. There are always different views of the problem and the combination provides different perspectives that complement each other.Just one thing, it's not upfront requirements
we are talking about, it's upfront understanding
, not a document or a list of requirements, but an understanding of the user, the context in where he lives and meet his problems his needs and goals. You can't just listen to a user requests, you have to grasp the context they come from. Henry Ford is supposed to have said: "If I had asked my customers what they wanted, they would have asked for a faster horse.
"The understanding comes first. You cannot just dive in and start building. What Interaction designers do is parted in two activities. The first part, and this is where I put the big upfront part, is to observe and listen to the user. Interpret the user’s surroundings and his problems. Interaction designers have the training to note what the users struggle with, not what they say they have problem with. This is also the time when the vision, metaphors and design guidelines are formed. They are not finalized, hopefully they never will be, but they are stable enough to start build upon. But you should not start build before this stability is in place.
The next part, the iterative work, this is when the agility begins. I am convinced that you cannot just hand over a document with interaction requirements. You have to continue to work with and be a part of the team. Ready to guide and share your knowledge of the user. The personas that interaction designers create are a great focal point for this sharing. The scenarios and user stories are the described problem and the design guidelines are the blue print. But you have to be there as Interaction designer to be able to transfer your knowledge and vision. And more important, keep the personas and vision alive. Only then you are able to give developers enough UI vision to work on.As the application evolves, and it will, the interaction designer keep with the basic idea, make sure the interaction stays within the vision but gives freedom to creative solution where possible. They have the knowledge to make sure the separate features fit together and hopefully this knowledge will transfer to developers. (I would love to try out pair programming with designer/developer and see the result.)Requirements should not only be evaluated in developer customer perspective, but also in interaction perspective what basic user problem it solves. Often it could be re-written to another requirement that actually solves the root cause instead of the problem that is perceived by the user. This will also make sure it stays with in the vision.The most important thing here is communication
. Interaction designers will have to work together with the developers. And the developers have to actively participate, agile development has opened the door between the developer and customer (I would rather have it to be the user
), but I am convinced that you will have to include the Interaction designers in this mix as well.