LadderBot: A requirements self-elicitation system

LadderBot is an end-user requirements self-elicitation system using the laddering interview technique. The system is currently in a pre-final state, with most of its functionalities working. It is capable of conducting a laddering interview with end-users and visualizing the interview structure in a graphical interface.
LadderBot is configured to elicit consequences and values for three attributes. The list of attributes for the evaluation will be generated in a pre-test session, via triadic sorting. LadderBot asks the user to identify the most relevant attribute from the list. This attribute is used as seed for the ACV chain until the users switch to the next attribute, for which the selection process is repeated, excluding already chosen attributes. When asking why-questions repeatedly, the chatbot will rely on four techniques for rephrasing questions to help and guide the user. Peer-reviewed guidelines for human interviewers on how to conduct laddering interviews inspired the utilized techniques. For now, the four techniques are applied by LadderBot at random. However, no technique may be used two times in a row. The visualization of the current status of the interview on the left side updates itself for each elicited consequence before LadderBot asks the next question. To end the elicitation for a specific attribute, or the interview in general, a human interviewer would need to identify when an interviewee has reached the ‘end’ of an ACV chain. As the current iteration of LadderBot is not capable of recognizing whether a user has already described all values for a chain of consequences, the bot requires the user to indicate if they want to continue the laddering process for the current attribute, or switch to the next chain. The user can make this indication using the command ‘stop’. After eliciting three ACV chains, LadderBot ends the interview.

Example use case

The following example outlines results of an interview with LadderBot as well as sample outcomes that were coded manually. The example laddering interview case is to identify users' goals in smartphone use, as presented in [Y. Jung, “What a smartphone is to me: Understanding user values in using smartphones,” Inf. Syst. J., vol. 24, no. 4, pp. 299–321, 2014].

Imagine the following ladders that a user provided through the self-elicitation interview.

Browsing the web -> Mostly for reading the news and updating myself on the latest moves in the stock market -> Maybe the newspaper, but I'd have to buy these and they only update once per day, thats not enough -> I want the latest news and just-in-time information on whats happening in the world. Usually, I browse the web to distract myself a little from the challenges at work, therefore I need a source that I can readily access at all times

Email -> I need to know if someone needs something from me, and see I got any updates from the services I signed up for -> I use multiple subscription services, such as MIT Technology Review or Medium, that sends update mails once new articles are released that might be interesting to me -> I may easily distract me from my regular or current line of work. Actually, I don't use permanent sync, it only updates when I actively use it, to reduce distractions. Email should incorporate that feature as a default I think…

Instagram -> Good question. Mostly, I want to stay updated on what my friends are doing and whats going on with the people I follow. Its has motivational reasons for me, and possibly easily available distraction, too. -> Any other social media really. But I read so much during the day, I enjoy the occasional picture-based information input

For the first attribute "Browsing the web" we could build the following ACV (attribute - consequence - value) chain.

• Web browsing (A)
• Reading news (C)
• Stock market information (C)
• Cost of access (C)
• Continuous updates (C)
• Just-in-time information (C)
• Distraction (V)
• Easy access (V)