Take it iteratively. You’re working directly with the users, right? So it should never really be a mess.

First do the search page. You and the users should keep in mind that they’ll want to be able to do actions on the results. Do the users like it? OK, you’ve got your search.

Now add the “Change Password” (or whatever is next in priority). Oops, we need to change the search page a little–well, change is often part of the game. Do the users like it like the results? Good.

Now add the next item, and the next…

The agile approach says you always have feedback right away, so you should be good.

That said, there’s no real reason why you might not be able to attack 2 of these stories in the same iteration (adding delete user AND ban user). The key is to always be working with the customer to make sure it’s right.

You’re often (always?) going to end up with users thinking of something else they want to do from that search screen after your original “design” is done and implemented. So, you’ll end up modifying it at some point anyway. Just approach the whole thing with that expectation and you should be good.

I feel like I say this a lot. Agile does not mean you need to put blinders on to ignore the future and design yourselves into a corner. Agile is about how you deliver functionality, and has very little to do with how you design functionality.

In other words, it’s okay to look as far into the future as you want when creating your design, as long as it doesn’t postpone the delivery of functionality in the short term.

What that means in your specific example is that you go ahead and design the user interface such that it will be easy to add actions later. However, if working on getting the actions design right would delay delivery of basic user search by an iteration, it’s better to do a design without actions first, assuming a search without any actions has value to the customer.

The question to ask yourself is, “Is this design work delaying my first delivery?” Most of the time, the answer will be no. You have to do a design anyway, all you’re changing is some design criteria.

The first user story can be the design of the whole interface — they don’t have to design just one piece of it. It is the design as a whole that adds business value.

That being said, I see at least two distinct features here: the ability to search for users, and the ability to perform a function on one or more users. The designer could tackle each of those searately if that makes more sense.

Remember: the goal is to deliver quality software, it’s not to blindly follow some methodology. Ask yourself whether breaking the design up into pieces helps or hinders that goal. There are no scrum police, only happy or dissatisfied customers.

I had an opportunity to intern at an Agile/Extreme programming factory. They were using story-cards to drive the iterative development process. Each story-card drove an implementation or change. The key was user interaction. How can one successfully design an interface meant for a user without interacting with a user of the software?

A possible scenario is to begin with user interaction to decide what the user wants first. Then, iteratively, design the UI based upon increasing feedback, user priority, and what the user must have.

The user stories are there to drive how the user would interact, at what level, and in what manner. But they are only approximations until interacting with the user. If there are a multitude of users that would all desire something specific, then a small survey of people may be in order to define some baseline for the UI.