Boxes And Arrows : The Design Behind the Design

This is exactly the type of article I’d like to read about. My experience with agile and Interaction Design has been chaotic at best. Adequate requirements gathering and user testing have been sacrificed at the expense of quick iterations and feeding the “beast” or developers as quickly as possible.4-5 days is not enough time to understand the domain digest the requirements and come up with an adequate user interface as well as get some validation from user testing. I think we’ll see the backlash very soon. There has to be a happy medium between traditional waterfal and all out agile. Maybe when the tail stops wagging the dog so to speak.

Our company creates and develops custom software (web sites, web-based applications, internal biz apps, etc.)
I’m currently working on an internal project, which I can’t talk much about except to say it’s a type of CRM app. The issue I’m running into right now is that we have an Agile methodology, but the user research and visual design has never been completed. Therefore, we’re doing IA and UX in iterative cycles.

The process is that I’m designing, starting with wireframes, then writing my code to kinda-sorta get close to the wireframes. There’s no color, and the buttons aren’t exact, etc. The half-finished doc then goes to the developers to start working on the functionality. Then i move onto the next section for the site.

The idea is to return to the screens later to make them “right.”

But this FEELS so wrong to me, and is almost more time consuming than if I’d had 2 months to really get the design done, interactions thought out, and delivered final markup/css.

Yet, the general consensus I face is that this is Agile, it works, and we are using it.

Any comments? Insight? Am I not seeing something?

To me, the Agile process should begin after the design is done being iterated over and we have final markup.

My experience with Agile development had been positive. It was not even our own product development. We were providing outsourced product developement services to our clients. We could build and deliver as much as 70 products that went to market and clicked over a period of 4 years.

The questions put forth by Ioredana are more related to the project execution and management than that to be addressed by an ID. The described situations arise when there is no strong negotiator on the delivery side. It requires a strong Delivery Manager who keeps the requirements realistic and work out a convinient iteration cycle time. Also, if it is a product company who using agile for development, the management having ‘right’ understanding of Agile helps. Else, the engineering ends up doing shabby work against their will.

So the solution to Ioredana’s questions is not an ID or any other fellow in engineering getting adjusted to whatever ‘version’ of Agile thrown to you, but to get the ‘Agile’ right to the basic and having a strong negotiator who understands this and keep the expectations leveled.

Remember that there are many wrong conceptions abound on Agile. But the one who understands the Agile right can only leverage it.

Manoj Potdar

Designing means Re-designing

The “agile thing” does not necessarily have to be just chaos and irritation. In order to make agile work one has to clear a few misunderstandings that bubble up regularly in day-to-day business:
- Sprints (iterations that is) are not a miniature waterfall. Often sprints are misconceived by developers and designers as a sort of controlling device imposed by the management. Or even as a means to constantly rise the pressure to the level usually met at pre-release.
If this happens something is wrong with how the team’s unterstanding of agile is tackled and of how the process itself is run. This, in my opinion, directly challenges the Scrum-Masters competence, since it’s his/her job to make sure that a) collaboration happens and b) workload is managable.

- Daily Scrums are essential and not just hassle. Even if the whole teams sits in the same office all the time daily scrums are indespensable: sharing an office does not get a project organized. The main function of daily scrums is not actually to solve complex problems. It is a way of how the team can coordinate itself efficiently and a place where problems are brought up, action can be taken and impediments are dispelled.

- Evaluation of User-Stories must be tangible. The evaluation scale must be clear. The evaluation process basically makes a projection of what is manageable in the sprint that lays ahead. If those involved in the evaluation do not have the same scale for weighing the issues in question the process is bound to fail and people likely to suffer. This may sound silly but not having the same scale is more common than one might think. Some use a scale based on hours/days of work required, others use gut feeling. I advise using a more complex rating system involving triviality/complexity, numbers of roles involved, dependency on third parties.
The point is that there is more than one way to manage estimation. Every team should find out together what type of scale it wants to use, and finding the scale should be a prominent issue in the beginning of any agile project.

Agile is a prime example for collaborative design. Designers must be aware that collaborative design is not a choice in agile, but a requirement of the method. One way to avoid the constant changing of requirements is keeping track of User Interface / User Interaction Guidelines established during the process. Stick to them and have them ready if the product owners want to change requirements: these changes often contradict the guidelines established.
One thing I noticed about the tendecy towards requiremnt-hopping is that it often breaks very simple, basic rules of interaction design. Mostly changes break the rule of Consistency or they are just laying rubble in the way of the user, forcing the user to do something unneccessary, dull or incomprehensible.

The reason why agile applies also to the design process is that it rises the quality of the product. If it is done right you’ll get a pretty good product that satisfies not only the customer but is actually useful to users. The way to achieve this is by being aware that designing means re-designing.

Memi Beltrame

For the record: Here’s a scale that made somehow sense in the projects i was/am involved in.
It turned to be quite accurate in having 1pt correspond to 1 days work. But you’ll have to fin out for yourselves…

1 pt: trivial, without involvement of any other department
2 pts: trivial, involves more than 1 department (e.g. GUI and middleware)
3 pts trivial, requires input/data frm third party
5 pts complex issues
8 pts core features with dependencies on other core features of the department
13 pts core features that go accross departments or plain killertasks

We just evaluated the agile DSDM method in a development project and came up with a couple of findings that strongly indicate that “agile” does not mean “do your research on the way”. On the contrary, it became clear to us that the “agile” just refers to the way how the coding is done – you don’t create the full specification, start coding and test after development has finished, but you have shorter development cycles and test units as you go. But you still need the specification before you can start writing code. The specification might not cover 100% of all requirements, but you need to have the full outline of scope and functionality first. And you have to manage the scope strictly to avoid “featuritis” – agile is not “managing features as you go”.
Wireframes have been very helpful in this process (actually we started them too late). We also found out that it is very important to involve the development team into the requirements session, to get them an understanding of the product. So agile is not “keeping ahead of developers”, but to include them into the team from the beginning.