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.

Yes, please write your story :)! I think a lot of IAs and IDs involved in an agile software development process share exactly this experience. The term that hits the bull’s-eye is “FEAUTURITIS”. The reason fot that is: Agile processes in IT companies are mainly established by devolopment teams to develop new software parts in a peacefull workflow. What’s very often missing is a well established process for the analysis and conceptional phase (for IAs to do their work peacefully as well!) to guarantee beforehand that the planned information architecture meets the needs of business and user requirements in an equal understanding. And yes, business thinkers, user thinkers and system thinkers need to be involved in these phases. There are ways(methods) though to optimise the agile development processes continously. Again, I’m very interested how we continously communicat about this topic and establish new ways to support the agile development processes.

Requirements change constantly so this is one point why agile software development has an advantage to the waterfall approach. Working with an UI-Team in an agile approach we made it to work constantly on research, design, prototyping an development to support the system developers in an excellent way.

There are several things that helped:
1. While the system development holds 4 week sprints (iterations) in which my team is involved as well in the estimation as in sprint demos and retrospectives to stick as close as possible with them my team keeps one week iterations (sprints). These very short sprints keep us flexible for changed requirements from outside but stable enough to constantly work on concepts and designs.
2. The high pace and cycle enables us not to block the system development but support them with paper prototypes exceeding their ability to code until they sprint as well as building an full fetured HTML-Prototype which sales and buisness can use to do presentations and elaborations with customers way before the product will be ready.
3. Contextual enquiries are done in the one week sprints as well on a small basis where we reserve time to do hallway tests. Some research can still be improved.
4. By having the described approach an a strong UI-Team guiding and supporting development and sales the featuritis decreased and might find a low point when bringing the UI-Team closer together with the IA and concept generation.
5. A system never is finished in the time IT is changing so fast. So we use the redesign being done by the system developers in the area of architecture to get more meat in analysis and market research to be ready once the pressure is getting harder on the UI requirements.
6. Having short cycles of 1/2 to 1/4 of the iterations of your developers will keep your pace optimal to support them.
7. Asking in advance of the planning and having your ear on the door to know what’s coming up will give you the ability to start with your work one or two weeks in advance of the start of the system developers. You might not need more time to provide them with prototypes and design.
8. Get your work into Design and Interaction Guides so you don’t have to sketch some parts of the design over an over again.
9. Plan user testing in your iterations even if you don’t know what to test. You can do this as hallway test.
10. Short Iterations make you flexible but stable enough not to have an escalation into your team every 2nd day.
11. Take care of your team.