Any project goes through roughly the same process.  Even Agile projects go through it, though steps are often done in tandem or repeated as stories are identified.

1. Identify the problem.

All projects exist to solve a problem, whether it’s an issue with an existing application, the addition of new functionality, or the creation of something completely new.  The key to a great user experience is to identify the correct problem, which isn’t always the one identified in the project request.  Getting the best grasp on the problem is tied in to understanding the requirements.

2. Gather requirements.

Every project needs requirements gathering, even if it comes with a fully fleshed out requirements document (and how rare that is!).  I dive into the application/process that’s already being used to solve the issue, watch users do their work, talk to experts in the process/product, and constantly ask “why?”.

3. Research competitors.

Of course the new user experience should be the best out there, which means understanding what is already there.

4. Determine user flows.

Now that I understand what it is we’re trying to do and what’s already been done to solve it, I can start planning out how the user will move through the process.

5. Sketch wireframes.

It’s pencil and paper for me to start – though I sometimes use Balsamiq or Axure immediately, or Bamboo Paper on my tablet, but pencil and paper or whiteboarding lets me get the most ideas out with the least effort.  Once I’m relatively happy with the sketches, I clean them up into a presentable set.

6. Review with product and development.

If there’s a product manager, I’ll review my work with them before I present it to anyone else.  Otherwise, I’ll present to the project owner.  Once they’re happy, then it’s time to present the sketches and flows to the developers for their feedback and ideas.  Collaboration with product and development produces the best possible solution.

7. Create prototype.

After I’ve thought through the changes from the work with product and dev, it’s time to put together a functional prototype.  The prototype allows me to catch issues with the interface and flows that we may not have seen, as well as illustrate the interactions.  Axure is my favorite prototyping tool, though I’m expert in Visio and experienced in Keynote as well.

8. Review with product and development.

Although they’ve seen the sketches, this is the time to show them the full prototype and talk through it.  After their comments, I update the prototype again.

9. Test.

Any project should be user tested.  At the end of the day, a project isn’t about what I think is best, it’s about what actually works for the user.  Testing our best solution lets us see gaps, smooth interactions, and discover if our innovations are actually workable in the real world.  Testing can be as simple as stopping by a user’s desk, or can be a fully scripted and recorded session – or anything in between.  The right test depends on the project.

10. Update prototype with test learnings.

If the tweaks are small, I’ll just update the prototype.  If the feedback we’ve gathered requires a larger re-work, I’ll review my proposed changes with product before updating.

11. Document.

The level of documentation really depends on the project and the process we’re using to run it; it can be as in depth as a full functional specification, as basic as an email to the dev team, or anything in between.

After that, it goes off to dev, and I deal with issues/change requests as they appear.