User Experience Design
In my User Experience design work I have used UML, wireframes, screen mockups, Use Cases and User Story cards. These are the lessons I have learned:
Users
Observe users in their natural habitat. Listening and watching while they work gives a better understanding than meetings and requirement documents. Often, I don't understand everything I see or hear. Then I simply ask "why?" Sometimes I ask this even when I think I do understand, and then discover my assumptions were wrong. It is much easier for users to explain and demonstrate when they are in their own work environment than when they have been removed to a meeting room.
I have observed users inside main battle tanks in Germany, in air traffic control centres, oil refineries and upstream plants, hospitals and cubicles. It's very encouraging and I always discover there is more to people's jobs than I might have guessed.
User Stories
Resist the urge to immediately start designing the details, including the screens. At the start of a project, the focus should be on the users' goals and the scope of the system. People like to see screens and to explain details, but moving into design at this stage risks missing the important decisions about scope and alternative concepts. At this stage, the user stories should be nothing more complicated than a list, or a stack of cards.
Concepts
The concept level is unfamiliar to many people involved in software development. Other industries involved in product design understand the importance of a clear concept. For example, car manufacturers are careful to position a new design as either a car, minivan or a truck. They may design a new vehicle that falls outside the existing categories, but this will be a deliberate decision, not an accidental result. In agile software development, the "system metaphor" is the concept. I believe the choice of concept is a critical design decision, best made after identifying a number of alternatives. The choice of concept is driven directly from the list of user stories.
In one project, the users actually needed to see a spatial representation of their assets. But the business had already chosen a concept that had no GIS component, to avoid positioning the product in competition with another company's product. The users' need for a map view refused to go away, and this capability eventually had to be added to the system. Adding the map view later may sound agile, but the requirement had existed from day one. The original product concept had not been a deliberate choice and did not match the users' actual needs.
User Stories, Step by Step
After choosing the concept, we can now start to walk through user stories, identifying the steps needed. For each user story, I try to answer these questions: Where does this story start? Where does it end? How does it get there? This approach allows for some creativity.
One example would be a calculation. In one project, a calculator feature had been requested. This was implemented. If the focus had been on users' goals, rather than on features, the requirement could have been seen as "calculation" rather than "calculator", and a fully automatic calculation could have been provided which would have completed the user story without any manual steps.
Visuals
People need to see screens. The rule I now try to follow is one screen shot per screen. The aim is to have enough visuals to walk through the user stories with end users, but not so many that it becomes impossible to keep all the screenshots up to date. That problem happened on one project, where I created screenshots for each step in each of the main user stories. It made it very easy to walk through the user stories with end users, but it became impractical to maintain them as design and implementation moved on.
So now, I prefer to create one mockup of each screen, and re-order these as needed (without duplicating them) when walking through stories with users.
Personally, I like simple sketches that just identify the main elements within the screens. But some users and managers may feel a need for detailed mockups. One advantage of sketches is that they leave room for the design to adapt and evolve. A detailed screen mockup may tie down the design prematurely and remove some of the flexibility that allows a good UI designer to adapt the design to match the real requirements as they become better understood over the life of the project.