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, stakeholder 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 (Requirements Gathering)
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 mockups, 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 / IA is invaluable at this time as it helps ensure the UI functions as a holistic application so there are no breaks in the consistency of the flows and the aesthetics can be created to exceed user expectations.
Design: Wireframe Iterations
For wireframes I like to design them quickly using Sketch or Visio 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 wireframes 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 wireframes in each project. That's simply because some clients have different preferences. Some may want balsamic sketches, while other clients want fully-annotated, grayscale wireframes in Visio or Photoshop and only in a very specific design or template. Others may want red-lines and pixel-perfect wireframes 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 (grayscale) wireframes 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 wireframes are ready, I first hand them off to peers or the project lead first to review and then after its had a lookover with no issues, I then present the wireframes to the stakeholders as soon as I can.
I then listen to any feedback to make sure the wireframe 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 either use Sketch (and Invision) or Axure to quickly create fully-interactive prototypes. Its much faster than hand-coding which is more prone to iterative changes when alterations need to be made to the overall design.
Iterate & Validate: Usability & User Research
Validating the prototypes (& wireframes) by peer-review is the first option that I depend upon to give a critical lookover of what will be presented. Typically wireframes 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.