Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'information architecture'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Management
  • Design
  • Requirements
  • Development
  • Test
  • Atlassian

Categories

  • Personal
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-Commerce

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Security
  • E-commerce

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Security
  • E-Commerce
  • Others

Categories

  • Thoughts
  • Debate
  • Health
  • Hobbies

Categories

  • Personligt
    • Åsikter
    • Humor
    • Spel
    • Träning
  • Allmänt
    • Internet
    • Program & tjänster
  • Intressant
    • Prylar
  • Professionellt
    • Management
    • Krav
    • Designs
    • Webbutveckling
    • Test
    • Atlassian
    • säkerhet
    • Förvaltning
    • Ehandel
    • Wordpress
  • Personligt_

Categories

  • Prologue
    • About This Book
  • The Tools
    • Jira Software
    • Confluence
    • Jira Service Management
  • The Inception Phase
    • Portfolio Management
    • Project Management
  • The Design Phase
    • Design as part of the Inception phase
    • Design as part of the Requirement phase
    • Working with design libraries
  • The Requirement Phase
    • Definition of Requirements
    • The four levels of Requirements
  • The Development Phase
    • Atomic design
    • Estimations
  • The Test Phase
    • The Definition of Test
    • Types of Test
  • The Operations Phase
    • Release Management
  • The Post Go-Live Phase
    • Incidents
    • Changes
  • Notes
    • My Muses
    • Research

Categories

  • Theme Building
  • Javascript Framework
  • CSS Framework
  • IPS: Pages
    • Database Templates
    • Block Plugin Templates
    • Page Templates
  • Custom Applications
  • Tips & Tricks

Categories

  • Europe
    • Central Europe
    • Eastern Europe
    • Northern Europe
    • Southeastern Europe
    • Southern Europe
    • Western Europe
  • North America
    • United States of America
    • Canada
    • Mexico
    • Caribbean
    • Central America
  • South America
    • Argentina
    • Bolivia
    • Brazil
    • Chile
    • Colombia
    • Ecuador
    • Falkland Islands
    • Guyana
    • Paraguay
    • Peru
    • Suriname
    • Uruguay
    • Venezuela
  • Africa
    • Northern Africa
    • Central Africa
    • Western Africa
    • Eastern Africa
    • Southern Africa
  • Asia
    • Central Asia
    • East Asia
    • South-Eastern Asia
    • Southern Asia
    • Western Asia
  • Oceania
    • Australia
    • Fiji
    • Kiribati
    • Marshall Islands
    • Micronesia
    • Nauru
    • New Zealand
    • Palau
    • Papua New Guinea
    • Samoa
    • Solomon Islands
    • Tonga
    • Tuvalu
    • Vanuatu

Categories

  • Shared Hosting
  • Virtual Private Server
  • Cloud Hosting
  • Dedicated Hosting
  • Co-Location
  • Hosting Services

Categories

  • Professional
    • Management
    • Design
    • Requirements
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce

Categories

  • Defects
  • Ideas
  • Development
  • ☑ Archive

Categories

  • Professional
  • Management
    • Agile
  • Requirements
  • Design
  • Development
    • Frontend
    • Backend
  • Testing
  • Operations
    • Hosting
  • Atlassian
  • Security
  • E-commerce
    • CRO
    • SEO
  • Interesting

Categories

  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce

Forums

  • General
    • Open Forum
    • Support
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Test / QA
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
    • Invision Community
  • Jobs
    • Looking for employee / consultant
    • Looking for Job / Assignment
  • Building The Site's Forums
  • Destiny 2's Discussions
  • The Journey's Discussions
  • Cinephilia's Topics
  • Diablo 4's Diablo 4 Topics
  • Shadownessence's Topics
  • sensory hyperreactivity's Topics
  • Wolcen's Wolcen Topics
  • Quality Assurance Heroes's QA Topics
  • Visual Studio Code's Forum
  • Adobe Illustrator's Adobe Illustrator Forum
  • Sketch Guru's's Sketch Topics
  • Requirements & test management in Jira's Topics
  • Microsoft Teams's Microsoft Teams Discussions
  • Figma's Figma Topics
  • Microsoft Planner's Microsoft Planner Topics
  • Psychology's Psychology Topics
  • Microsoft Word's Microsoft Word Topics
  • Microsoft Powerpoint's Microsoft Powerpoint Topics
  • WordPress Devs's Wordpress Topics
  • Ornamental Design's Ornamental Design Topics
  • Adobe Photoshop's Photoshop Discussions
  • Agile 2's Agile 2 Topics
  • Agile 2's Agile 2 Principles
  • Microsoft Outlook's Outlook Topics
  • My Book's Discussions
  • Outriders's Outriders Discussions

Categories

  • Jimi's Files
    • Curriculum vitae
    • Presentations
    • Certificates
  • Management
  • Requirements
  • Design
    • Fonts
  • Code
  • Test
  • Operations
  • Atlassian
    • Certificates of Excellence
  • Security
  • Ecommerce
  • Invision Power Services
    • JWSE Support Tickets
    • JWSE Task Management
  • Shadownessence's Files
  • WordPress Devs's Wordpress Files

Calendars

  • Project: JWSE Workboard
  • Project: JWSE Workboard
  • Community Calendar
  • Professional Events
  • Management Events
  • Requirement Events
  • Design Events
  • Development Events
  • Test Events
  • Atlassian Events
  • Operations Events
  • E-commerce Events
  • Destiny 2's Events
  • The Journey's Events
  • Cinephilia's premieres
  • Diablo 4's Diablo 4 Events
  • Agile 2's Agile 2 Events

Blogs

  • How to start your own blog
  • Sketch Blog
  • Building The Site's Blog
  • Destiny 2's Destiny 2 ramblings
  • The Journey's Stories
  • Diablo 4's Diablo 4 blog
  • Sketch Guru's's Sketch News
  • Requirements & test management in Jira's News
  • Agile 2's Agile 2 Blog

Categories

  • Personal
    • Humor
    • Music
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
  • Destiny 2's Videos
  • The Journey's Videos
  • Cinephilia's Trailers
  • Diablo 4's Diablo 4 Videos
  • Wolcen's Wolcen Videos
  • Visual Studio Code's Videos
  • Adobe Illustrator's Adobe Illustrator Videos
  • Sketch Guru's's Sketch Videos
  • Requirements & test management in Jira's Videos
  • Microsoft Teams's Microsoft Teams Videos
  • Figma's Figma Videos
  • Microsoft Planner's Microsoft Planner Videos
  • Psychology's Psychology Videos
  • Microsoft Word's Microsoft Word Videos
  • Microsoft Powerpoint's Microsoft Powerpoint Videos
  • WordPress Devs's Wordpress Videos
  • Ornamental Design's Ornamental Design Videos
  • Adobe Photoshop's Photoshop Videos
  • Agile 2's Agile 2 Videos
  • Microsoft Outlook's Outlook Videos
  • Outriders's Outriders Videos

Categories

  • Movies
    • Action Movies
    • Adventure Movies
    • Animated Movies
    • Comedy Movies
    • Crime Movies
    • Drama Movies
    • Fantasy Movies
    • Horror Movies
    • Romance Movies
    • Sci-Fi Movies
    • Thriller Movies
    • Western Movies
  • TV Shows
    • Action TV Shows
    • Adventure TV Shows
    • Animated TV Shows
    • Comedy TV Shows
    • Crime TV Shows
    • Drama TV Shows
    • Fantasy TV Shows
    • Horror TV Shows
    • Romance TV Shows
    • Sci-Fi TV Shows
    • Thriller TV Shows
    • Western TV Shows

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 2 results

  1. Atomic UX Research. Sounds like something amazing, doesn't it? Something that will fit right into the modular design and development processes in Atomic Design. Unfortunately it is just a fancy name for having a proper documentation strategy for UX Research made up by UX Designers who work in poorly structured workplaces. When I first read the article "Foundations of atomic research", I had no idea what the person was talking about. Was it a process, a content strategy or maybe even how to present the findings. I looked up the Atomic UX Research further and found the article "What is Atomic UX Research?" and it seemed like it was all about how to organize the documentation of the findings. I watched the video (added blow) where Daniel Pidcock try to explain this new, revolutionary way to organize data, and I was both amazed and a bit disturbed over the fact that the audience actually seemed to agree with this nonsense. The reason I felt that way is that there is nothing in this new made up word that have anything to do with UX. It's just common sense on how to manage documentation. Any documentation. Anyone working with research should know that you always connect current research with relevant research that it is related to. It is also standard practice for anyone working with research to add metadata to make the research findable in different situations. Anyone working in UX research, especially towards the web, should know that data get old very fast and loose relevance very fast. That is not how you work with any form of documentation that is supposed to be alive. If you make UX research then that data is ever-changing as you continue to learn and experiment. This does not warrant a new way of working, you just need to start working the right way. Proper documentation is always a part of research, as is traceability so you can understand where the conclusions come from and how you used it to formulate new theories to be tested. The Atomic UX Research suggests that you should divide the research into smaller bits and then tag each type with metadata. The idea is that by doing that you can discover other data that is related to your research. If you have hundreds of theories going at once in multiple teams, or you want to bring in similar research on other systems or services then maybe that would be useful. Then again, if you have that many experiments going, then the volume of data would be immense and you would have no way of knowing what data would be relevant. You would spend a ton of time on matching old experiments that probably will be obsolete as the design have already been updated since it was conducted. This is the image used to illustrate the four main parts of the Atomic UX Research. Note that the structure start with the Experiment. Now it may be implied, but an experiment should be tied to a theory. What are we trying to prove and why do we think this is worth exploring should be the starting point for all research. While I think this may be implied, for me this is where this theory fails. By having the theory as the highest level, all experiments fall under that theory. All theories are built on previous learnings so while there is no problem having the information structure dividing the content beyond experiments I think that if you ensure you have your theories in order you would not see many insights related to multiple theories at the same time. Even if you have an additional level of information for insights you would not have multiple conclusions. The conclusion would be tied to the theory we are working with based on the result of the experiments we run to test that theory. In the event that we make findings not related to the theory we are testing, this would be marked in the conclusions as separate theories to explore at a later date. My take on the Atomic UX Research approach is that instead of inventing new names, you should start working with research properly. UX Research follow the same basic structure as every other research field. In order for any research to have the desired effect you need to formulate theories, conduct experiments to test that theory, analyze the result and finally take what you have learned and form new theories and of course activities to improve the service or product you are doing UX on. The result is documented in a searchable tool with metadata and connection to previous theories that support the decision to make further testing of the current theory. You do not need a new methodology for it, just follow the standard research praxis that has worked for many, many years. Doing random exploratory testing is not research. It is exploratory testing/discovery. Atomic UX Research = UX Research. View full blog article
  2. Atomic UX Research. Sounds like something amazing, doesn't it? Something that will fit right into the modular design and development processes in Atomic Design. Unfortunately it is just a fancy name for having a proper documentation strategy for UX Research made up by UX Designers who work in poorly structured workplaces. When I first read the article "Foundations of atomic research", I had no idea what the person was talking about. Was it a process, a content strategy or maybe even how to present the findings. I looked up the Atomic UX Research further and found the article "What is Atomic UX Research?" and it seemed like it was all about how to organize the documentation of the findings. I watched the video (added blow) where Daniel Pidcock try to explain this new, revolutionary way to organize data, and I was both amazed and a bit disturbed over the fact that the audience actually seemed to agree with this nonsense. The reason I felt that way is that there is nothing in this new made up word that have anything to do with UX. It's just common sense on how to manage documentation. Any documentation. Anyone working with research should know that you always connect current research with relevant research that it is related to. It is also standard practice for anyone working with research to add metadata to make the research findable in different situations. Anyone working in UX research, especially towards the web, should know that data get old very fast and loose relevance very fast. That is not how you work with any form of documentation that is supposed to be alive. If you make UX research then that data is ever-changing as you continue to learn and experiment. This does not warrant a new way of working, you just need to start working the right way. Proper documentation is always a part of research, as is traceability so you can understand where the conclusions come from and how you used it to formulate new theories to be tested. The Atomic UX Research suggests that you should divide the research into smaller bits and then tag each type with metadata. The idea is that by doing that you can discover other data that is related to your research. If you have hundreds of theories going at once in multiple teams, or you want to bring in similar research on other systems or services then maybe that would be useful. Then again, if you have that many experiments going, then the volume of data would be immense and you would have no way of knowing what data would be relevant. You would spend a ton of time on matching old experiments that probably will be obsolete as the design have already been updated since it was conducted. This is the image used to illustrate the four main parts of the Atomic UX Research. Note that the structure start with the Experiment. Now it may be implied, but an experiment should be tied to a theory. What are we trying to prove and why do we think this is worth exploring should be the starting point for all research. While I think this may be implied, for me this is where this theory fails. By having the theory as the highest level, all experiments fall under that theory. All theories are built on previous learnings so while there is no problem having the information structure dividing the content beyond experiments I think that if you ensure you have your theories in order you would not see many insights related to multiple theories at the same time. Even if you have an additional level of information for insights you would not have multiple conclusions. The conclusion would be tied to the theory we are working with based on the result of the experiments we run to test that theory. In the event that we make findings not related to the theory we are testing, this would be marked in the conclusions as separate theories to explore at a later date. My take on the Atomic UX Research approach is that instead of inventing new names, you should start working with research properly. UX Research follow the same basic structure as every other research field. In order for any research to have the desired effect you need to formulate theories, conduct experiments to test that theory, analyze the result and finally take what you have learned and form new theories and of course activities to improve the service or product you are doing UX on. The result is documented in a searchable tool with metadata and connection to previous theories that support the decision to make further testing of the current theory. You do not need a new methodology for it, just follow the standard research praxis that has worked for many, many years. Doing random exploratory testing is not research. It is exploratory testing/discovery. Atomic UX Research = UX Research.
×
×
  • Create New...