Tautologically UX concerns itself with any factor that influences a user's experience with a machine
Proper UX design touches upon most of the steps:
UX arose as a field of study and practice as more and more people in various occupations came to an unsettling conclusion.
UXers seek to bridge the widening gap between people and new technology that can improve their lives
Paradoxically, it is this multiplier that causes the gap to widen.
A technology sufficiently complex to be useful will be too complex for a majority of its beneficiaries to understand how it works.
Some short years ago, the touchscreen was born—an invention that literally puts data at our fingertips.
How many smartphone users understand how a mutual capacitance touchscreen works?
Rightly so! It took dozens of patents, and thousands and thousands of R&D hours to bring touchscreen smartphones to market.
A UXer strives to make technology serve the user.
And to prevent the user from serving the technology.
Understanding people and their motivations is the primary responsibility of the UXer
Purely functional technology is frightening, sometimes ugly.
A sponsor, client, or business provides the objective
Identifies a problem worth solving
Provides support to solve it
"The proper application of these algorithms to this problem will yield untold returns and stimulate an inordinate tidal wave of heuristics"
A very good place to start. Find a problem that you are passionate about solving and capable of solving given your resources and abilities. Define the goal, and depict success. Draw pictures, write stories, realize it any way you want to, any way that gets you and your team excited about solving that problem.
Survey those who experience the problem you aim to solve. Figure out what drives them, what a solution would look like to them, and how much time or money they have to devote to solving this problem. Many call this market research or user research.
As you become familiar with the audience, archetypes will arise. Build dossiers around personas that exemplify the archetypes to give the team a clearer, outside perspective on the product. Give 'em a name, face, age, occupation, and all the relevant ethnographic data you can muster.
Interaction design is at least 5-D: 3 spatial dimensions, time, and a number of other dimensions resulting from the user's choices. A flow map can help to convey and discuss the intracacies and complexities before you begin prototyping. A flow map of the interactions you aim to enable will make it much easier to break the product into discrete features and functions.
Before diving into the nuts and bolts, it's imperative to write about the product you plan to build in analytical framework. Rather than putting together an old-fashioned requirements document that few will reference and fewer will read, I like to break the product—as envisioned in the flow map—into features in a versatile task manager like Asana or Trello. Then we can stage the features into releases.
With the wealth of frameworks and open source libraries available, it's likely we can bootstrap our efforts wihtout having to build everything from scratch. A comprehensive survey of the tools at hand will inform our architeture and save us a lot of work down the road.
Once we know what's out there we can design our architecture to support the features and specs. A flowchart can be a wonderful living document to illustrate architecture. Iterate on it as you build.
The prototype comprises the minimum set of features necessary for a hands-on test of the concept. Why bother drawing pictures of an interface when you can build the interface and actually try it out? A working prototype accelerates progress like nothing else.
Said another way: if you want build a product, just start building it.
Once you've got a working version of your idea, it's a good idea to polish the rough edges that might distract those doing the hands-on testing. It's much more difficult to polish an imaginary stone than a real one. Design in CSS, and only use mockups to develop the visual aesthetic, not to dictate the structure, dimensions, or (heaven forbid) a pixel-perfect replica of a drawing of an interface.
The character of the product may now be presenting itself through the prototype. This is good stage to examine naming, branding, and aesthetic. Call in the designers, make a mood board, give it a coat of paint.
Progress on a product no one has built before can be difficult to measure. So in early days it's best to focus on momentum, or its lazy cousin inertia. Giving team members freedom to create at their own enthusiastic paces, rather than focusing on blockers and linear processes, will keep productivity and morale high.
When a prototype starts building steam, you can maintain momentum with a staged work cycle that keeps the product folk, designers, and developers all busy. Many features do not follow a linear path from product, to design, to development, so choose a teamwork tool that allows features to bounce around as needed.
Try not to get bogged down in process though. Only build processes to solve real problems.