Making the Quality Engineering comic

About a year ago I decided to make a comic with rvr about Quality Engineering/Quality Assurance, explaining what it is and why it is important. There were a couple of breaks in between, partly because of this virus you might have heard of, but it was finally published recently. This post explains a bit the creative process behind it.

High-level concepts

As soon as we decided we were going to make the comic, we started brainstorming to figure out how exactly we were going to explain it. We were mostly thinking of metaphors to describe QE people, but also added some associations and aesthetic ideas to the list:

• Wizards, detectives
• Team players, drummers
• Mad scientists making robot helpers
• Creativity, more freedom to build what is needed and adapt
• Build for developer, build for yourself
• James Bond’s Q / Q branch
• Proactive Mr. Wolf
• Rick and Morty
• Something like ​Mouse Guard? See also paper crafts.
• “Continuous disintegration”.
• SDETs are the real 10x engineers

Script ideas

One of the ideas for the script was to use some kind of Starship Troopers metaphor (“people killing bugs”, or “people making the weapons/tools needed for the soldiers to kill bugs”). We had a certain tension between being serious and in-depth, and being “fun” and grabbing the potential reader’s eye, and we ended up with the idea that we could open with a Starship Troopers scene, but then reveal that it’s just someone’s imagination, and let the rest of the comic be “serious” and more on the explanatory side.

Storyboard iterations

At first we were discussing how to iterate with the storyboard: we were looking for some online collaboration tool that allowed us to build the storyboards, comment on them, and modify them. However, we didn’t find anything I was happy with, and I prefer working on paper for those things, so I decided to just draw a very crude storyboard and take a picture of it. The initial storyboard was like this (click to enlarge):

We discussed it a bit, and after the feedback I create new panels to replace some of the initial ones, and stitched them together in a Frankenstein monster fashion, like so (again, click to enlarge):

If you want to know more about the rationale behind the panels, notice a few things:

1. Each line has a meaning, like a sentence in written language. Namely, the first line is opening/attention grabbing (“what happens when there is no QE”), the second expands a bit on the first one but from a serious perspective, the third explains why a development team needs QE, and the last explains the details of how QE achieves what they do and closes.
2. Every line ends with a “cliffhanger” to make the reader want to read the next line, and introduce what it is going to be about.

At this point we decided that the storyboard was stable enough to start figuring out how the art would be.

Art

Now that we had a stable storyboard we could look into the final art. We figured that we would still have to iterate, partly because once we used the final art, final font, and final sizes for things… we would probably see things differently: some panel might have too much text, some idea that seems to work in the abstract doesn’t work that well with the final art, etc. So from there we iterated further, but mostly on the language and on details that were relatively easy to change.

The first version with the kind of art we were going to use was this, in black and white:

This gave us a good sense of scale and available space, both for text and for illustrations, so it was much easier to tweak and improve. After a few iterations, we reached the first version with colour! You can see here that the art here has improved, and is at the level we would use in the final version.

Then we kept iterating and, after all the tweaks, reached the final, published version. Notice the difference in the last two panels, and also the text in 3-3:

Conclusions

There you have it! I don’t claim to know what I’m doing, but I love reading about (and writing about) creative processes, and I thought some of you might share my passion for that.

Now the idea is to make at least one more comic related to QE, expanding on more specific problems QE helps solve, or on specific facets on Quality Engineering. We’ll see what we come up with…

• qa
• quality
• comics
• storytelling
• programming
• projects

Control (PS4) story theory

This is my theory for what the story in the videogame Control means. Control is a videogame with a very surreal, dream-like story in the style of David Lynch and Satoshi Kon.

Why not take the story literally?

Judging from what I have seen on Youtube, most people seem to be taking the events in the game at face value. And maybe that’s what the developers intended! However, taking the story literally rubs me the wrong way for the following reasons:

• Dreams are clearly really important in this story
• Blurring/confusing reality and fantasy is a recurring theme
• If the bits about her being a janitor’s assistant and the “office scene” at the end are irrelevant, why are they there? Writing and programming that kind of stuff is hard

Even if everything here is wrong, it’s how it makes sense to me! Finally, note that I haven’t played Alan Wake or Quantum Break so I might not be on board with some assumptions or world-building or whatever.

Theory

Summary / Thesis

Jesse is the janitor’s assistant and most of the events in the game don’t happen, or at least don’t happen as they are shown in the game. She is fantasizing about those things happening to her and lives a pretty mundane life.

However, see the “synchronicity” note below.

Timeline

Something awful happened in Ordinary

Whether or not most/all adults disappeared is not clear (maybe only her parents and older acquaintances?). It has nothing to do with supernatural elements, though.

Traumatised, she starts believing in conspiracy theories

Evidence:

• From a psychiatrist session recording: the psychiatrist says that there was an industrial accident in Ordinary, and Jesse replies “No. It wasn’t an accident. It was a cover up. The government knows about it.”
• America Overnight, the radio show you can find in-game mentions this event, and clearly boosts conspiracy theories. Jesse could have been a listener of that show.

She enters a mental hospital

She is forced into a mental hospital and has problems telling apart truth from fiction. Evidence:

• From a psychiatrist interview recording: “You know that we cannot let you go before you’re well. And that begins by understanding what’s real and what’s imagined.”
• From a psychiatrist interview recording: “As a child, did you ever fantasize about worlds inside pictures. You know, stepping into a painting, into a hidden world, escaping and finding adventures there?”
• From a psychiatrist interview recording: “You have mentioned a few times that there’s a piece of you missing. It’s natural that you feel that way. Your brother and your parents are dead.” Jesse: “No. Dylan’s not dead.”
• Jesse: “I was eleven years old the first time I saw behind the poster. They told me I’d imagined it”
• The motel is described as a “place of power”… but Jesse also says that it’s just her imagination (when the music video in the third room).

When she is out, she looks for a job

At some point she goes somewhere (the FBC? does it even exist? maybe it’s the FBI? Arish says that is protects American “from foreign threats”) to look for a janitor’s assistant job. Evidence:

• When she meets Ahti, he says “There you are. You come for the job. ‘Janitor’s assistant’“
• Late in the game, when returning to the janitor’s office, she says “I suppose THE janitor’s assistant does need proper janitor attire”, and she gets a new “Janitor’s Assistant” outfit
• The janitor assigns her tasks like “fighting the mold” (cleaning) and taking care of the plants
• She’s the one that actually solves everything around the office, why would she be the director?

She gets the job but struggles a bit

She struggles because she feels she doesn’t do her job properly. She is criticised/bullied by Emily Pope. Evidence:

• In the office scene, Emily Pope says “There’s the new girl. Standing around daydreaming when she should be getting work done. Who the hell does she think she is? The Director?”

She fantasizes with having lots of power

Under the everyday pressure, she starts fantasizing about having power, “becoming the director”, and possibly having power over and/or being respected by Emily. Evidence:

• The fact that the Object of Power that starts it all is a “projector” maybe it’s a metaphor with projecting our needs/fears
• Close to the end, Dylan says “My sister had this dream. A bad dream. And the whole world was dreaming with her. She’d convinced herself that she was awake. She’s always been stubborn. I knew I had to end her dream. I had to wake her up.”
• Upon finding the director dead, Jesse picks up the weapon and this definition is shown: “Objects of power can cause, or be the result of, AWEs (Altered World Events) intrusions upon the perceived reality”. Before that, nothing supernatural has happened yet.

The whole game is an epic version of what she’s doing

The whole game is her projection/fantasy of being powerful, and she imagines an epic version of herself doing an epic version of cleaning, taking care of the plants, improving at her job, etc. She never becomes the director of anything, but she believes that fantasy. Evidence:

• The Clog gets “anthropomorphised” as Mr. Clog. Ahti even says “My old enemy, the Clog, is blocking the pipes”
• In the “What a Mess: Even More Mold” mission, she says “Let’s get cleaning, she said, cocking her gun”
• Instead of Emily Pope and others ordering her around, Jesse is “the director” and is “taking care of things” and she just gets information about what has to be done.
• The sitting, flying hiss people are office workers in the office scene! There is a connection between the real office workers and the hiss creatures.

The fantasy could have bled into reality

It’s possible that most of the game really did happen like that, because her fantasies became reality through an extreme version of Carl Jung’s theory of synchronicity, mentioned in the game.

Extras

These bits are not necessary for the above to make sense, and are less solid than the rest.

When does the switch between reality and fantasy happen?

When Jesse takes the lift at the start of the game (she goes to an interview), the scene cuts to show the credits. Afterwards she arrives somewhere with a lift, and it’s when she goes to the Director’s office and the supernatural things start to happen. Do those two things even happen the same day? Why would the janitor’s assistant have an interview with the Director?

Even less solid, mostly fun to think about: when she arrives in the lift, there is an alarm and you can read on some screens that the building is on lockdown and that there is an “HRA emergency”. What if that means something entirely mundane, like “Health Risk Assessment” and it’s actually some problem in the building that forces them to quarantine? A health issue would explain the obsession with the mold.

Dylan

He is dead, or maybe never existed, or maybe it’s another personality of her:

• From Dylan’s dreams: “In the dream, I was alone. It was just me. I was the only child. A girl. My name was Jesse Dylan Faden.”
• From Dylan’s dreams: “You’ve always been here, the only child”
• From a psychiatrist interview recording: “You have mentioned a few times that there’s a piece of you missing. It’s natural that you feel that way. Your brother and your parents are dead.” Jesse: “No. Dylan’s not dead.”

Polaris

It might be another personality, or maybe the player?

• From “Ordinary AWE: Stage 4.a”: Dylan says that “Jesse said we should call her Polaris. It’s because she was doing stars at school”
• At the beginning, when presumably talking about Polaris: “I forget, ‘it’s all in my head’. There’s no you, right?”
• From Dylan’s dreams: “Polaris is using you. The bureau is using you. You are a puppet.”
• In a psychiatrist interview recording, Polaris is referred to as an imaginary friend from her childhood.

• games
• storytelling
• theories
• videogames

A year of Elm

It hasn’t quite been one year since I wrote the first post on Elm, but it’s not that far off and the title was clearer that way. In this time I have written three programs in Elm, each one more complex than the last:

1. Client for the catalogs generated by cataloger. My RPG resources catalog is an example of the result.

2. Prexxer, a “Dress-up” application to combine sprites and create characters. You can see the code on GitHub.

3. NARROWS, a storytelling system halfway between online role-playing games and improvised Choose Your Own Adventure books.

The first one was useful to get to know (and love) Elm, and of course to get my RPG resources catalog online. With the second I learned about Elm ports (the interface to interact with JavaScript) and got a bit more comfortable with Elm. With the last one, the only one that has a back-end (written in ES6, though; Elm is only for front-end), I learned how to structure big applications in Elm, how to use the excellent ProseMirror, and how to use much more complex Elm ports.

What I like about Elm

• It’s a simple language with few concepts, easy to learn and understand. After my initial (small) struggles, I have mostly loved it since.

• The Elm Architecture is really nice and simple, and it’s nice that it’s integrated into the environment. It’s like having a framework for free with the language.

• Everything immutable: the easy way is the right way.

• Nice, clear, useful compiler error messages.

• Generally nice toolchain.

• Static types help you a lot, mostly without being annoying.

• Newer major versions of the language simplify things further and make things clearer and less error prone (I’ve been through two major updates).

What I don’t like about Elm

• The compiler seems slow and often seems to compile older versions of the code. This might be my own fault, as I have a custom Brunch configuration with an Elm plugin and I don’t even understand Brunch all that well. In comparison, the TypeScript compiler was amazing.

• Some complex types and interfaces, notably the modules for HTTP requests and JSON parsing. The former improved a lot in the new version, Elm 0.18.

• Newer major versions of the language break compatibility and you have to rewrite parts of your application, which is really annoying… but also worth it.

• I’m not that fond of currying. Sometimes I feel like it makes some compilation error messages harder to understand.

Conclusion

I’m really happy I gave Elm a try almost a year ago. Although I’m looking forward to going back to ClojureScript for some project, I really, really enjoy Elm, and it has almost become my defacto front-end language/framework.

• elm
• frontend
• functional
• functional programming
• projects
• role-playing games
• rpg
• storytelling

Book Summary: Storytelling for UX (3/3)

And this is the last past of the summary of “Storytelling for UX” (first part, second part). In this last part I’ll cover the tips to create stories. At the end I’ll do a mini-review of the book and will add some extra comments.

How to create a story_ _

Stories have four elements: audience, ingredients, structure and medium.

Audience

There are two important relationships in stories: story-audience and you-audience. About the first, you want to include details that fill the gap, and also stories are a good way to make the audience see a different perspective by feeling it. Finally, endings are important. They should be memorable and settled (“take them home”).

Ingredients

See checklist on p. 209.

• Perspective. there isn’t a neutral POV in stories. Types of perspectives are realist (3rd person, “absent” author), confessional (focused on author experience) and impressionist (mixes descriptions of events with a strong structure). The last intends to spark ideas/actions and while they can have an ending, they might end with implicit question. An easy way to add perspective is letting the main character do the talking.

• Characters. One of the reasons why UX stories are useful is because they add specificity and texture to the usually one-dimensional view of users. Also useful to highlight needs outside the mainstream. Tips to build characters: (1) choose (only) details that add meaning; (2) show, don’t tell (show in action instead of describing traits); (3) set up “hooks” that you can use later in the story; (4) leave room for imagination.

• Context. Five types: physical (time, date, location, location scale), emotional (how characters feel), sensory (5 senses), historical (“when phones had dials”), memory (storyteller’s memory, flashbacks).

• Imagery. Things that make us picture the story (example in p. 205). Don’t use too much!

• Language. Tips: (a) speak in the language of the characters, (b) make the story active, (c) focus on telling the story, not describing, (d) don’t judge characters, context or events.

Structure/plot

Structure is the framework/skeleton of the story. Plot is the arrangement of the events. Strong structures help the audience, the author and the story (p. 215). See types of stories on p. 216. “Checklist” for good structure and plot on p. 235.

Medium

Four big media: oral (mind the gap to written, p. 243), written (make the point explicit, keep it short, make use of cultural cues as in p. 253), visual (comics and storyboards work, see p. 258-260), multimedia/video.

See tips on how to integrate stories in reports on p. 265 and p. 266. See strong sides of different media on p. 272.

Mini-review and conclusions

I quite liked the book, although I admit that the last part (the one summarised in this post) was a bit disappointing. I guess it’s hard to give tips about something as complex as creating a story, in a book. The book has a very clear structure and it’s easy to follow and read, which helps in figuring out what to read, what to skim and what to leave for later.

Another thing that really struck me while reading the book (the second book I read following the tips from “How to Read a Book”) is how little I used to understand of the books I read. I now go through the book three times: one to get an idea of the structure and the most interesting parts, one to read the content, and one to review and make a summary. So even while I was reading it for the last time, I made sense of things that I hadn’t realised while reading the book (and that was after knowing the structure, knowing what to expect from each chapter, and having made some preliminary notes!). Not only that, but I also feel that I’m much more critical with what I read and I compare it much more with what I think myself.

If you aren’t doing it already, I strongly recommend that you give those tips a try…

• books
• review
• storytelling
• ux

Book Summary: Storytelling for UX (2/3)

This is the second (and longest) part of my summary of “Storytelling for UX” (see the first part). It will cover how to fit stories and storytelling into the UX design process.

There shouldn’t be “a storyteller” in the team, as many as possible should be familiar with the technique. Prototypes based on stories allow exploration of new ideas, esp. if they’re big changes.

There are several parts of the UX process were stories are useful:

• Collecting input from users. You’re already hearing those stories. Do it consciously.

• Exploring user research and other data. Summary of hard data.

• Experimenting with design ideas. See stories that help launch a design discussion (type) and the role “spark new ideas”.

• Testing designs. They can evaluate if you have stayed true to original needs and if they will work with real users.

Collecting input

Being in the user work environment helps noticing things people don’t mention. When you just arrive, everything is unfamiliar. Take notes then. If you can’t talk to your users, you can get some limited info from: search/server logs, customer service records, people who do training and sales demos, market research and satisfaction surveys.

Getting people in groups can help make people talk (build on each other). Also asking people to recall specific events is really useful.

Tip: be open to tangents, but don’t waste too much time in them if you don’t see value. Also, a user avoiding talking about what you want is information, too.

Tip: Use a structure for the interview (first closed questions, then open), see p. 82. Try to have the interview in the context the product will be used.

Selecting stories

Characteristics of good stories:

• Heard from more than one source

• With action detail

• Make user data easy to understand

• Illustrate an aspect the UX team is interested in

• Surprise or contradict common beliefs

They should help explain something about UX beyond data, bring data to life. They should also connect with other stories and resonate, leading to action.

Experimenting with design ideas

Three possible uses of stories: brainstorming, concept and specification. When no user research is available, you can brainstorm to create user stories. See a good technique/game for it on page 111.

When you do have user research, you can develop those stories. For that, some rules: (1) defer judgement, (2) encourage wild ideas and (3) build on the ideas of others. See adaptation of the game for this case, p. 118. Concept stories should include: (a) focus on activity set in a specific context, (b) description of motivations that trigger action, (c) describe the characters well enough to set them in context.

Specification stories are useful to summarise results. They are included in specs. They keep the real-world context available for reference.

Testing/evaluating designs

Three uses of stories: create scenarios/tasks for usability testing, serve as guide for expert reviews, and quality testing.

If in usability testing you ask the user first what her interests are, you can turn that story into a usability test task.

Stories and personas from them are very useful to set a context for expert reviews. Give each expert a persona and make them try to complete a task from that persona POV.

[I didn’t really get the “quality testing” part, whatever that means, so I don’t have notes about it]

Sharing stories

When communicating with people, stories get the audience attention, set context and inspire action.

Listening exercises make you understand your audience, and make them understand how diverse/similar they are.

There are three typical types of audiences:

1. Strategic leaders: generate and maintain a common vision (p. 143). Things that work for them: identify point of pain and offer a solution, identify gap in market and show how to fill, show new approach by reconfiguring common/existing components, and identify UX trends and show impact on business.

2. Managers: have a mission and have to make decisions (p. 146). Don’t have time to spare, prefer short meetings to brainstorming sessions. If you bring bad news, show why it’s important to care. Don’t go into much detail.

3. Technical experts: implement a vision (p. 149). Can be difficult to reach them with stories, esp. if not grounded in details. Tips: (a) use representative characters and situations and be ready to back up with hard data, (b) make the action of the story specific and tangible, (c) keep the story on track, (d) use technical terminology accurately.

And that was the end of this part of the summary. In the next and last post I’ll cover the tips about creating stories and will write some sort of mini-review and conclusions.

• books
• review
• storytelling
• ux

Book Summary: Storytelling for UX (1/3)

This is book is the first book chosen for Oslo’s UX book club. It was a quite interesting book about using stories and storytelling techniques in different steps of the User Experience design process. The following is the first part of my (long) summary of the book. The summary is mostly intended to remind me things I read, but probably/hopefully it will be interesting and useful to others. As the book is more or less divided in four parts (introduction, listening, how to fit stories in the process and how to create a story), I’ll cover the introduction and the notes on listening in this post, and will leave the other two parts to other posts. Edit: see parts two and three.

Introduction (chapters 1-2)

Stories help keeping people at the center (p. 2). There are different types of stories (p. 5):

• Those that describe context/situation: describe the world today. Not only sequence of events, but also reasons and motivations.

• Those that illustrate problems: show a problem that a new product or design change can fix. They should describe it in a way that opens the door for brainstorming.

• Those that help launch a design discussion: starting point for a brainstorming session. Enough detail to make sense but leave room for the imagination.

• Those that explore a design concept: explain/explore idea or concept and its implications for the experience. Helps shape the design by showing it in action.

• Those that prescribe the result of a new design: describe the world as it will be in more detail. Similar to the 1st, but describe a user experience that doesn’t exist yet.

Interesting quote in page 10, with the message “until you hear a story, you can’t understand the experience”.

Stories are interactive, change with the audience (p. 14). They also not only describe actions, but add context and why (motivation). There is a fine line with how many detail to include in motivation, because of shared cultural understanding and other things (p. 17, 19).

Stories have different roles:

• Explain: give context and sensory experience, not just events. This is different from use-cases.

• Engage the imagination: surpass linear logic and evoke new ideas.

• Spark new ideas: as we fill in the gaps, we can hint details but let people come up with their own ideas.

• Create a shared understanding.

• Persuade.

In any case, stories are not “made up”: they’re based on data.

Listening (chapter 3)

Really listening to users (e.g. in interviews and such) gives you access to a lot of info you can’t get anywhere else. Open questions are very important for this. Giving time to answer sometimes gives people time for second thoughts (not just what they think you want to hear), which has more value than the first reply. Also, pay attention to the context, people forget to mention “obvious” (for them) everyday facts.

Practising active listening is very important, see the following links:

• Eight barriers to effective listening

• 10 Tips to Effective & Active Listening Skills

And that’s it for the first part. Stay tuned for the rest of the summary.

• books
• review
• storytelling
• ux