Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
NYT method exercise - common mistakes and advice
Hi everyone
Good job with the NYT method exercise so far. I hope you enjoy coding and qualitative data analysis. I noticed some common mistakes, so here is my advice on how to better use the codes and avoid common mistakes:
- Use only (sub)codes for coding and not the code categories (for example, use “common terminology” code, but don’t code anything with “definition/design best practices”)
- Make sure to first read the codebook very carefully and only afterwards start coding. This way you will know when exactly to use each code. For example for the code “internal collaboration”, the When not to use rules is “Do not use this code for external communication practices, for strictly development or UXD definition best practices. Do not use this code for decision making practices.” Nonetheless, some apply “internal collaboration” code to the parts that should be coded with the separate code “decision making”.
- Code concepts and their discussion. For example, if you see that style guide is mentioned, don’t just code that part of the sentence with “style guide” code. Instead include the supporting arguments, counterarguments, if they are talked about. Often you only code the small part of the concept, where it’s obvious that certain code must be used. However, think about how useful this coding would be to a researcher. Having only a small part of the sentence coded means that the researcher will have to go to certain part of the interview and reread the paragraph/segment to understand the concept. Instead, if you code the concept now, afterwards it will be easier to realize your analysis. However, don’t overdo this and don’t just broadly code everything.
- Don’t confuse the “definition/design best practices” codes with those of “implementation best practices”. Especially, codes “central functionality” and “plug-in functionality” exist both under definition best practices and under implementation best practices, but they are very different. Basically, if the concept you are coding is about designing a UX component (let’s say creating a mock-up of the new plug-in interface), then use “plug-in functionality” that is under “definition/design best practices”, because this concept does not concern the development of the UX component, but rather its initial design/definition. Alternatively, if the concept discussed is about the development process of central UX components, use “central functionality” code under “implementation best practices”, because it concerns development and implementation of UX components. This could be confusing, so be attentive to make less mistakes here.
- Do not code the paragraphs in the interview that only describe the company or the product line without providing any best practices. Some interview questions focus on the company or the product line in general, but don’t include valuable insights or best practices. Such parts are useful when writing a research paper, because they present the context of the case study, but for our method exercise we only focus on best practices, so don’t code parts that are mere descriptions.
- Some codes are only used a few times during the whole exercise. This is fine, because some best practices are very specific for a company division or team. Don’t try to use all the codes many times. However, also don’t just use the broad sounding codes for everything. Each code has its boundaries that are in the codebook.
- Some misunderstood the code “UX modes”. This is about the best practices of having different usability modes in a software for users of different proficiency level. For example “beginner” view for inexperienced users and “advanced” view for more proficient ones.
- Codes “prototype” and “external evaluation” are often used together, because prototyping is one of the techniques of realizing external evaluation. However, this is not always the case, as sometimes prototyping is used in different contexts and external evaluation could be realized through other methods.
- Now that you hopefully understand better how QDA works, you should look through what you have already coded and improve your coding as you go.
I hope this was helpful. If you have questions, ask away here in the forum.
Hi,
thank you for your feedback.
How should a text be marked that is about internal collaboration and decision making on the same level.
E.g. (interview otto) […]This become a dialogue in order to get their feedback […] (Text shortened)
=> As this is somewhat about decision making [see also the answer from kevin “This means that you normally don’t make decision by yourself.”], the internal communication and collaboration code is not allowed
So it might be decision making on different levels and escalation → but this are not different levels → in my opinion the parties are on “the same level”.
=> Decision making on different levels and escalation is also wrong
So the internal discussion and the decision making process should not be marked here?
Greets and thanks
Dear Franz
Thanks for your question.
You argue that this segment is about decision making. However, it does not explicitly talk about decision making (who makes decisions, how are decisions made etc.). You are right that Kevin talks about decision making in the next line, but that is not enough to infer that our original segment is about decision making. The code “decision making” should only be applied to segments where decision making, related roles and practices are talked about. Also, “decision making on different levels and escalation” means how decisions are made, for example, on the level of user experience desgin, implementation, testing etc., while escalatio means decision making that is handled by higher management in the organizational hierarchy.
In any case, you should think about other more obvious concepts presented in this segment:
[…] This become a dialogue in order to get their feedback and to tell them what’s possible and what’s cheaper. […]
The code “value-effort mapping” is appropriate here, because the main argument here is to find find out “what’s possible and what’s cheaper”.
Furthermore, if you look at the broader context (which you should do to understand the whole concept that’s discussed), you will see that “internal collaboration” is being discussed. One simple example is the sentence before our segment:
[…] Here we start collaborative approach with the guys from the usability department […]
This clearly describes internal collaboration and so does “This become a dialogue in order to get their feedback”, as a consecutive argument.
Hope this helps.
Cheers, Nick
Hi Nick,
That makes sense.
Thank you very much for the detailed answer!
Greets