Category: teaching

Structuring Your Dissertation

The Single Key Tip for Structuring Your Dissertation

With your dissertation, you tell a story about the research journey you undertook during your work on your thesis. It’s a story about what you set out to find, how you investigated your topic, and what you found out in the end. This gives you three key components:

  1. Your starting point
  2. Your path
  3. Your end point, and where to go from here

It’s important that you describe all three points in as much detailed as possible so that people can follow your journey. Take a journey from Edinburgh to London, for example. If you want to describe the journey in detail, you need to say where you set out, what means of transport you used, and where exactly you went. You should also add a reflection to evaluate what you did.

For example, I went from the Informatics Forum to the Alan Turing Institute in London by train. First, I walked from the Forum to Waverley Station for ten minutes. I walked via George IV Bridge, as that path has fewer slow traffic lights. I then took the fast Virgin Trains service directly to London Kings’ Cross, which takes 4 hours 20 minutes. We had a signal failure on the way and got stuck behind a slow train, so we ended up being 25 minutes late. When I arrived at King’s Cross, I turned right, left the station, crossed St Pancras Station behind the Eurostar Terminal, and walked down to the staff entrance of the British Library, where the Alan Turing Institute is located. Overall, it was an efficient way of travelling, but it’s worth adding a buffer of 30-60 minutes to your travel time because trains are often late.

(You see that I referenced all locations, except for well-known ones like Edinburgh and London. Detailed referencing is important – this is how you show your reader that you are aware of what is already known about your topic.)

What does this look like in practice?

Common Elements

Well, all of you should start with an Introduction that motivates your work (why are you doing this), and a brief overview of what you set out to achieve (your research questions / the problem that your app or artefact is designed to address), what your main methods were, and what you have ended up creating – a kind of summary of the story in a couple of pages. Ideally, you end with a list of the following sections and the parts of the story that are told in them in more depth.

Next, you should have a Background or Literature Review chapter. In the background chapter, you describe the starting point of your investigation. This is where you review the relevant theory and previous work. You should aim to show that you have a good grasp of the concepts that you use in your work, explain relevant theories as needed, and tell us about who else has done similar work, and what they found.

After that, thesis structures start to diverge, but the final chapters are again always similar. Discuss your overall journey, reflect on what you have learned, on the main decisions you made, and tell us what could be done next. This is typically done in two chapters, one called Discussion, where you summarise your findings and relate them to what is known in the literature, and Conclusion, where you reflect on your journey and describe possible next steps. The Discussion is a good place to bring in aspects of the literature or previous work that tie in to your findings.

Telling the Tale of Your Work

Design Informatics

In Design Informatics dissertations, you have more freedom to explore different designs, and to show how the theory you’ve read, the theoretical stance that you take, and the research you’ve done have affected your design.

You will typically do one or more iterations of your work. You will do the bulk of your user research for the first iteration, and that usually deserves its own chapter, which you can call User Research or User Requirements. Then, you create your first prototype, and evaluate it. That can be in one chapter, Prototype 1 or just Prototype. If you have time, you will do another prototype and evaluate it, and that’s again a chapter.


Well, you’ve got it easy. If you are doing a traditional experiment, the American Psychological Association has you covered. For each of the experiments you do, including pilot studies, you follow the time honoured structure of Method, Results, Discussion.

Informatics App Development

The strategy I recommend for you is similar to the one for Design Informatics students. In your case, you may have an initial section on User Requirements, followed by iterations of your app. I recommend at least one initial prototype. This can be wireframes only, but it’s a good way of getting feedback from your end users. Your final, working app should always be evaluated with end users. So, your middle chapters will typically be User Requirements, Prototype (Design, Implementation, Feedback), Final Prototype (Design, Implementation), and Evaluation (for the final prototype).

Make sure that your Prototype chapters contain a formal description of your app – a flowchart, an UML diagram, specifications for all the databases you use. Provide pseudocode for your algorithms (not actual implementations) and describe key implementation decisions. Which libraries did you use? Why?


This page is by no means exhaustive. It’s meant to complement the Informatics MSc Dissertation guidelines, and when in doubt, the official guidelines have precedence.

Basic Demographics For Your HCI User Study

Many HCI studies, especially student studies, involve a small section on participant demographics. In this post, I summarise the guidance I tend to give to my own students. There are many aspects of designing demographics questionnaires that this post won’t cover, but for a relatively simple basic user study, this should do the trick.

Principle 1: Don’t ask too many questions.

Make sure that what you are asking is relevant to your study, and focus on the most parsimonious way of getting that information. Fewer questions with fewer tick boxes are less daunting and generate more answers.

For example, when you ask about people’s age, don’t use age groups that cover ages 18-60 in increments of 5, unless you really need that level of granularity.

Principle 2: Respect people’s privacy.

Don’t ask detailed questions which may enable others to identify your participants, given what they know about when you conducted the study, and where you recruited the participants, unless they are relevant.

For example, questions about people’s country of origin are most often used to distinguish between native and non-native speakers of English – which matters if you test a system that extensively uses language. Yet, knowing somebody’s country of origin can easily identify participants who might be the only student from their country on your particular Masters programme.

Principle 3: Make demographics optional

Demographic data can be used to potentially identify people. Also, some people  may not feel comfortable sharing that information with you, especially if all they are asked to do is to evaluate or use an app or a product that you have designed.

Principle 4: Put demographic questions last

If you make somebody reflect on an aspect of themselves that is associated with social stereotypes, they are more likely to conform to or enact those stereotypes later. This is an instance of a phenomenon called Stereotype Threat, and Wikipedia has very useful resources about this topic. If you want to amplify effects of stereotype threat in your data, put demographics first, otherwise, put them last.

Principle 5: Cover the basics.

The basics differ by discipline and research lab. I always like to include the following:

  • age (18-24, 25-34, 35-44, 45-54, 55-64, 60+), with additional categories above 60 if I am working with older participants
  • gender (male, female, prefer not to say, other), which makes space for gender fluid people
  • occupation (student, employed full-time, employed part-time, self-employed, retired, home maker, unemployed, other), which acknowledges the important work that men and women who stay at home do (otherwise, they’d have to refer to themselves as unemployed). I also recommend making this a checkbox category, because people can be students while employed full time
  • highest educational qualification (high school/secondary school; vocational qualification; university graduate; postgraduate qualification). This is the most country-specific one, and there are no hard and fast rules. I mainly like to include it because level of education is a potential indicator of socioeconomic status, and may also affect people’s performance on task

Principle 6: Check whether your participants have exposure to the technology / products that you are testing

There are several formal and informal sets of questions floating around that assess digital literacy, exposure and attitudes to technology, and the like. I prefer to stick with the minimum, which looks at what technology people own and use.

Below is a very basic example of a table that requires people to tick what technologies they own, and how frequently they use them.

Don’t own one





I hope that you find these hints useful. If you want to cite them, feel free to do so; if you have any comments, or would like me to expand on some of the points I made, please leave a comment. Comments are moderated, as I get a lot of spam, but I check regularly.