I've had the name IDEA Software since I finished school and I began designing websites.  I typically work as a C2C (Corp to Corp) consultant in most cases, so I use this company to receive a paycheck.

In a perfect and static world there would only be one way to approach UX in the way of a precise and uniform step-by-step process. Yet, since that normally isn’t the case in the real world of UX consulting, I have to be flexible to take into account what my clients and each individual project will allow in the way of time and resources and any plan of action as to their own company and team's accepted approach to UX.

As a professional UX consultant, on most occasions I quickly adjust to each client's own way of doing UX.   And rarely is it like the last UX project I had just completed for another company where even different UX teams at that same company approached UX processes in a noticeably different manner altogether.  Startups don't usually have the time and money to invest in a formal UX process, but need the added wisdom of an independent consultant who can use their best judgement to help the project succeed especially at the fragile and critical ideation phase and pre-MVP (minimum viable product) stage to present to a potential client or investor(s).  As a consultant, I never attempt to define the project, but I will be glad to help refine it.

So as a consultant, it’s necessary for me to quickly adjust to each project accordingly and do my best to provide the best aspects of UX I can using the best of my own abilities and experiences.  The following is just a rough sketch of most of the UX processes that I perform for most projects, but in no case is it set firmly in stone - but this is what I try my best to accomplish at the very minimum for each project.

     Research: Strategy and Discovery Phase

This most important initial phase of research and discovery includes stakeholder interviews, reading the business and design requirements and/or functional specs, studying the competition (competitive analysis or industry sector analysis and competitor software features) and understanding the marketplace and end-users (personas, user-research or previous customer feedback) and then understanding how to put all it together into a multiple design concept solutions.

I've always felt that doing this due diligence regarding research and interviews are the best strategy to begin with because it’s what I've always gotten to do on successful projects  (study the business objectives, the requirements, the overall vision, what others have said about the previous software version, and listen very carefully during all stakeholder interviews of what new features they want to add and what they want fixed about the old version).  It is also the time I am taking photos of whiteboards and taking notes of the requirements, stakeholder conversations and sketching out the UI during pauses and breaks in the discussions.

 Planning: Documentation & Diagrams

If the project is complex and I have the necessary permissions, I really enjoy creating the necessary documentation (taxonomy, personas, style guides, process flows, interaction flows, screen flows, gap analysis, risk analysis, web analytics, journey maps, personas, sitemaps, design sketches, and concept mock ups, etc.). With these documents in hand I can keep better track of the nuances of the business requirements and begin to architect the overall UX solution to the problem(s).  Even though on agile teams, documentation is very light, its still appreciated to create documentation on the UX design portion to help achieve a superior result than to just rely on subject-matter expertise alone.

For me, it has always been that UX Architecture and Information Architecture can be invaluable at this time as it helps ensure that the overall UI and features function as a holistic solution so there are no breaks in the consistency of the flows and the aesthetics can be allowed to exceed user expectations and not take away or distract due to over-designing with a short term focus on form over substance that was thrown into the equation.

     Design: Wire-frame Iterations

For wire-frames I like to design them quickly using Sketch or Axure. If I get to use Sketch or Axure for a project, I'm usually relieved, because it's rather quick to go from wire-frames to interactive prototypes since I would be using the same software for both.

If you get a chance to review my projects, you will see a difference in the types of wire-frames in each project. That's simply because some clients have different preferences as to what artifacts they need or wish to use. Some may want balsamic sketches, while other clients want fully-annotated, gray scale wire-frames and only in a very specific design or template. Others may want red-lines and pixel-perfect wire-frames in Photoshop or Illustrator.  It all depends on the client and who is leading the project (even inside the same company that has an entirely different UX process!).

During first iteration of projects it's normal to produce abstract, low-fidelity (gray scale) wire-frames to go over the abstract (high-level) details to make sure it's what the stakeholders had in mind.  Yet during the next iterations, most stakeholders I have dealt with, prefer to see more detail and more fidelity before they can approve the project going forward.  

When the wire-frames are ready, I first hand them off to peers or the project lead first to review and then after its had a look-over with no issues, I then present the wire-frames to the stakeholders as soon as I can and listen to any feedback to make sure the wire-frame designs are sound and what the stakeholders and sponsors had in mind.

     Prototypes: Interaction Design and Visual Simulation

Once the initial wire-frames have been chosen and approved by project stakeholders, I quickly follow through with the first iteration of prototypes.  On all projects I created wire-frames and could easily use Sketch (and Invision) or Axure to generate HTML and JavaScript so I could focus on creating and designing a solution rather than hand-coding a feature which is always more lengthy and prone to iterative changes when alterations need to be made to the overall design. 

Lately more clients want something more fast and simpler than Axure, and so we use Sketch and Invision for fast wire-frames and prototypes.  On rare occasions with very large corporations, I will have to use iRise™.  Actually it's great for visual simulations, especially if any project calls for simulating large data sets of closely modeled and filtered information in real time - like large data sets of tables filled with relevant information or displaying a new product catalog with images and pricing and the ability to search and use sort capabilities to display a large data set of items in a table.

     Iterate & Validate: Usability & User Research

Validating the prototypes (& wire-frames) by peer-review is the first option that I depend upon to give a critical look over of what will be presented.  Typically wire-frames will go through various cycles of iterations and peer review, depending on what a client or UX team will allow for.  After peers have reviewed the work in most cases the deliverables will only then get passed on to stakeholders for more rounds of iterations (updates and changes).  Normally at this point of iterations on the prototype - I will already begin fine tuning everything until it inevitably gets approval to go into usability testing & user-research sessions which are put in front of real individuals for the valuable feedback they provide.  Often, if I’m lucky I get to make final adjustments to the designs after participating in either conducting or listening in on the usability tests and user-research sessions.  When this phase has been completed the prototype sometimes goes back to the stakeholders for one more final round of approvals with all the test results and updates to be signed-off on before being put in front of the developers with an optional functional spec document - all ready for production.