Considerations and Processes

 In Research -, Standards and Processes -, UX Design -, Web and Application Design -

During my 5+ years as a UX Specialist, I have learned just how many considerations go into a single project.  In the beginning I designed with only basic UX heuristics in mind, but as my knowledge base grew, I realized the extend of what goes into making the best product possible.  To help elicit the most pertinent information, I started compiling a list of considerations and processes for approaching a future project.


Product specifications

  • Is this project a re-design, new concept, or expansion of what’s already there?
  • What type of application are you looking to make?  
    • Internal/external program
    • website/ full application
    • gathering/dispensing information
  • What type of platform do you want the final product to be on?
    • Mobile
    • Tablets
    • MS/iOS
    • streaming/downloaded
    • on the web
      • IE, Mozilla, Chrome
      • verison? – old/new
    • single or multiple platforms
  • What’s the timeline for the product?  
    • Will it be rolling out in phases, or is this a one-time release (Agile or Waterfall)?  
    • Where are you in the process of creating the product?
  • For websites I prefer a responsive site, but I would ask the clients if they would prefer having separate sites for mobile/desktop, or if they would prefer a more responsive/fluid approach to the site.
  • I would also ask here about preference for the underlying structure
    • aka Bootstrap, YUI, Google Materials, etc
  • Will it be a CMS based site? 
    • If so, what are your preferences for site performance?

      • WordPress/Drupal
      • Confluence
      • MS Access


Client specifications

  • What types of actions are you hoping the user will be able to do?
    • Submit data (complexity of entry fields)
    • download data
    • do searches/queries/reports
    • have help content
    • transact money
    • log information or tasks
    • connect to other users
    • auto-complete
  • Depending on who is doing the coding for the client, I’d ask about what code base that they would be trying to use.  
    • Would they be using an already compiled base and just want to make CS changes?
    • Will the developers need to be creating new code to accomplish the tasks?
  • What are the main target audiences that you are trying to attract?
    • Describe their age, gender, lifestyle, hobbies, general routines.
  • How important is accessibility to your product?
    • (i.e. text-readers, visual impairments, reading level)
  • Explain a bit more about the culture around the product.  
    • What are the main “lingo” words that everyone using the program would know?  
    • What abbreviations can we use?  
    • What are basic category/bins that normally form for your product?
      • In the medical world MRN would be an abbreviation understood by all, and a natural category bin on a site might be “Medical Record History”
      • In the financial world the abbreviation ACH might be understood and a natural category might be “Accounts”
      • Clothing shop categories like “jackets”, “shirts”, “dresses” vs “maxi dress”, “body-contour”, “avant-garde couture”
  •   What type of a style are you going for?
    • Modern
    • Retro
    • Stylized
    • Kitchy
    • Sleek
    • Clean
    • Fanciful
    • etc
  •  What color scheme are you looking to incorporate?  
    • If they don’t have a prescribed color scheme, then discuss possible choices for them


Process for project completion

  1. Once all these questions have been answered and discussed I would take this information back to start creating user stories for what the system needs to be, and start providing options for the group to choose from.  
    • Options should be based on desired timelines and balance user needs and wants.  
    • If there are too many changes desired or too much effort needed, the product may want to consider phases where highly desired /easy features will be rolled out first, and more complex/ less desired features will be phased in later.
  2. Once all basic options are chosen, the underlying information architecture should be laid out.  
    • Sometimes this architecture grows or changes with additional site/application content, but an initial architecture should be set so that designers have a place to begin.
  3. Basic standards documentation would begin at this point.  
    • Depending on the level of effort on the project (simple 3-page website redesign vs complex multi-application system) standards would include greater or less detail.  
    • Standards should include basic typography and color scheme information, common workflows, special scenarios or conditions, error treatment, and basic accessibility requirements.  
    • As the project grows and more elements are determined, they should be integrated into the standards documentation for trace-ability.
  4. I would begin designing by creating lo-fidelity wireframe workflows, providing several options when needed. 
  5.  At the same time I would begin working with with the main developers and other designers to start creating the basic skin for the application.  
    • Based on the code base that we decide to build on, there may be certain skin restrictions that we need to adhere to.  
    • Using the expertise of each team I would bring the clients several skin options overlaid on several of the determined workflow.
  6. Once the basic skin and workflow are teased out, I would create Axure prototypes to test the possible workflows and ensure that everything was in place before we start composing the final pages.  
    • This is where the best user testing will be done as users will be able to interact and play (limitedly) with the application.  
    • Confusion and frustrations will be easily teased out in these demonstrations.  
    • A/B testing can be done to test designs, layouts, and flows.  
  7. If re-designing a new application, or an application with a new code base, I would start developers with creating a basic library of components that will be used to create the pages.  
    • If done smartly, by the time final designs are determined, the development should be able to mostly work from the library, for faster development time.  
    • The more work that is put into standardization of pages upfront, the less changes we’ll have to make on the fly later down the road.  
    • Depending on how closely the Front/Back end developers and visual designers work together I might break down the skin into desired code.
  8. Throughout this process we’d also keep the client involved in daily/weekly/monthly scrum meetings to see progress and to ensure everything is moving ahead as planned.
  9. Upon completion of the first iteration I would work with analytic and research teams to ensure that changes made increased conversion-rates.
    • Developer teams should also be performing bug checks along to way to ensure all new code is integrated in correctly.
    • Clients would also be informed at this point to check in and ensure that the project is moving ahead as planned.
      • If compromises need to be made along the way, the client’s involvement throughout will ensure no surprises at the end.
  10. Design iterations will continue with input from research tests and new stockholder requirements.
  11. Before final release the client’s will be brought in for a final review to air any last minute requests, changes, or concerns.
  12. Once the product is released tracking of user concerns, bugs, and complaints will inform the next round of updates.


Recommended Posts

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt