Often my process follows one or both of the two cycles in the diagram below, depending on my role in a projec.
In this early phase of a project the product scope is first defined, ideas are transformed into attainable goals. The research that follows helps me better understand the client, their business, proposed and current products, the problems that the product should solve, and for what audience/users. Getting this phase right - determining the requirements and resources needed - plays a key role in determining the success of the next steps in the process, so business requirements and goals must be carefully considered.
Tasks in this phase may include: Stakeholder Interviews, User Research, Technology Research (limitations, opportunities), Competitor Review, Analytics Review, User Surveys.
The data data that was collected during the Discovery phase is organized and evaluated. A UX designer tries to draw conclusions from the data and test out assumptions with team members and stakeholders. If there is an existing/legacy application that can be mapped out.
Tasks in this phase can include: Value Proposition, Storyboards, Personas, User Stories, Use Cases, Journey Maps, Mind Maps, Site Maps, Taxonomies, Process Flow Diagrams.
I should note here that some projects with a Lean UX process which I've been a part of tend to keep this step very thin or remove it altogether, and in some cases this makes sense. If so the need for stakeholder feedback and user testing in the later stages becomes even more important tool to guide the project, so internal and external validation is often broken out into its own distinct step after the Prototyping phase.
This phase focuses on conceptualization of the interface and designing the flow of an application or site as a user tries to complete certain tasks. For me this phase involves quick iterations of potential solutions using Sketches, Wireframing, Mood Boards. Wireframes may include notation that allows a user to jump in mid stream, and also to clarify proposed features and behavior.
This is where we see partially working implementation of the idea in order to present proof of concept for validation/testing. A clickable demo, which may involve working HTML/CSS/JavaScript code and generally uses static data, is presented to stakeholders and then to users for feedback. These demos are often limited to a handful of primary user tasks in order to decrease the time needed to iterate. User feedback is crucial to deciding whether the process needs to cycle back a step or two in order to work out any challenges the users faced, cover any gaps in the use cases, and so forth.
Tasks can include: Visual Design, Screen Mockups, HTML prototypes, Clickable Demos, Style Guide, Stakeholder Validation, User Validation, Usability Testing.
Once the steering committee has signed off on development either the UX or business analysis team can then create detailed requirements for the Engineering and QA teams to use for the estimation process. Excellent written communication skills are required here to make sure the application is built as envisioned, and I have filled this role when involved in the Development cycle of the application.
Engineering builds the working product. I write the front-end code if I am involved in this phase.
I have been deeply involved in the cross-browser testing of front end code, page interactivity, and ensuring the style guidelines are be followed. This phase is a great point for user testing before the product is finally released. Depending on how significant the feedback is, the client can choose to move the project back to an earlier phase in the UX process - usually Design or Prototyping - in order to address valuable insights.
From here the UX team will eventually have access to a lot of data through metrics, support feedback, and user testing/feedback. The UX team can then begin the process all over again, proposing new enhancements, which are then scheduled into the product roap map along with bug fixes to create a steady cycle of improvements.