Using design cards to facilitate redesign: initial findings

When developing new design concepts and redesigning existing ones the idea of using design cards to facilitate the process and creativity has been explored in several different fields. The idea of using design cards as part of design workshops has been explored when developing new design concepts such as game designs [7], “playful experiences” [6], and tangible interactions [5]. For example, design cards have been used to “…probing and provoking users’ past experiences and current assumptions.” [3]. Several design cards have been developed based on theoretical frameworks and used to rephrase abstract frameworks into something more operational. Through this transformation the theory can be more tangible and applicable by making cards with keywords, pictures, and questions [5]. It is out of the scope of this blog post to include a detailed review of related literature. Instead, I will briefly outline recent HCI-related research about design cards.

In recent research design cards have mainly been evaluated during initial design phases, and a few during other phases such as evaluation of designs, and redesign. Past literature has pointed out the several general strengths and advantages of design cards. On an abstract level design cards can be considered a design material useable in a collaborative setting when making designs [4]. Wölfel and Merritt (2013) [8] conducted a review of 18 different forms of design cards or card methods used as part of a design activity, and highlight that design cards have been reported to:

  • Supporting design dialogues.
  • Cards can act as a common reference among participants.
  • Cards are something specific and concrete to talk about.
  • Making the design process visible and less abstract.
  • Facilitating a design process, for example, by providing structure in the process.
  • Physical tokens in the form of cards are easy to include, use, and manipulate.

They divided the purpose and scope of the card systems into three different categories:

  • General (8 card methods) (open-ended inspiration.)
  • Participatory design (7 card methods) (engage designers and users in the process.)
  • Context-specific/agenda driven (3 card methods) (focused on a particular context or design agenda.)

They divided the methodology of the design cards into three categories:

  • No methodology (3 card methods.)
  • Suggestion for use (7 card methods.)
  • Specific instructions (5 card methods.)

In usability engineering, a challenge for developers is how to correct usability problems, especially non-trivial problems. Running redesign workshops with developers and designers actively collaborating has been proposed as one method for exploring redesign opportunities [1, 2]. In a recent study, we decided to explorer if including design cards in redesign workshops would improve the proposed redesigns and support the process of fixing usability problems.

In summery we asked groups consisting of two – three students, following a class about designing and evaluating user interfaces, to make redesign proposals of a given web shop. We provided the groups a list of known usability problems. The groups were divided into four group clusters. The groups in three of the clusters were provided a design card system, a different system for each cluster. The groups of one cluster were acting as control groups and did not receive any design cards. During the redesign exercise, we observed a subset of groups. Afterward, we had the students filling out a survey about their impression of the quality of the redesign, and usefulness of the design cards. Finally, we interviewed a few groups. In addition, six evaluators, three academic researchers, and three practitioners involved in the development of the web shop assessed the quality of the redesigns.

Our initial findings indicate that design cards did not, at least not how we used them in this study, have any major positive effect on the quality of the redesigns. When comparing the quality assessment of the redesigns, we did not find any significant differences in comparison to the control group. The students did not find the design cards particular useful. However, some mentioned that the cards did provide some initial ideas and inspiration. These initial findings might be surprising when looking at the positive results reported from previous studies [5-7]. One major difference in this study is that design cards were included in a redesign workshop, and not during an initial design development or ideation workshop. The students were provided both an existing design, and a list of known usability problems. These seemed to be the main drivers and basis for the redesign proposals.


  1. Bornoe, N., Billestrup, J., Andersen, J. L., Stage, J., & Bruun, A. (2014). Redesign workshop: involving software developers actively in usability engineering. In Proceedings of the 8th Nordic Conference on Human-Computer Interaction: Fun, Fast, Foundational (pp. 1113-1118). ACM. DOI: 10.1145/2639189.2670288
  2. Bruun, A., Jensen, J. J., Skov, M. B., & Stage, J. (2014). Active Collaborative Learning: Supporting Software Developers in Creating Redesign Proposals. In Human-Centered Software Engineering (pp. 1-18). Springer Berlin Heidelberg. DOI: 10.1007/978-3-662-44811-3_1
  3. Bødker, S., Mathiasen, N., & Petersen, M. G. (2012). Modeling is not the answer!: designing for usable security. interactions, 19(5), 54-57. DOI: 10.1145/2334184.2334197
  4. Halskov, K., & Dalsgård, P. (2006, June). Inspiration card workshops. In Proceedings of the 6th conference on Designing Interactive systems (pp. 2-11). ACM. DOI: 10.1145/1142405.1142409
  5. Hornecker, E. (2010). Creative idea exploration within the structure of a guiding framework: the card brainstorming game. In Proceedings of the fourth international conference on Tangible, embedded, and embodied interaction (pp. 101-108). ACM. DOI: 10.1145/1709886.1709905
  6. Lucero, A., & Arrasvuori, J. (2012). The PLEX Cards and its techniques as sources of inspiration when designing for playfulness. International Journal of Arts and Technology, 6(1), 22-43. DOI: 10.1504/IJART.2013.050688
  7. Mueller, F., Gibbs, M. R., Vetere, F., & Edge, D. (2014). Supporting the creative game design process with exertion cards. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 2211-2220). ACM. DOI: 10.1145/2556288.2557272
  8. Wölfel, C., & Merritt, T. (2013). Method card design dimensions: a survey of card-based design tools. In Human-Computer Interaction–INTERACT 2013 (pp. 479-486). Springer Berlin Heidelberg. DOI: 10.1007/978-3-642-40483-2_34

Installing MaraDNS on CentOS

MaraDNS is a simple lightweight domain name service (DNS) including both an authority and a recursive DNS. In a few words DNS is used to translate domain names (for example, into an IP address (for example, bound to a specific server on the Internet. An authority DNS contains information about specific domains and which IP addresses they should translate into. For example, the authority DNS of is This server knows the IP address of the server hosting A recursive DNS is used to request the IP of a domain name from an authority DNS or the hostname of an IP. You can read more about the differences between authority and recursive DNS at Wikipedia.

In this guide I will go through a basic installation of MaraDNS on CentOS (MaraDNS can also run on other Linux flavours such as Debian) and have MaraDNS act as a primary (master) DNS.

Note on IPv6 support: MaraDNS does support IPv6, but needs to be compiled in a IPv6 mode. How to do this is not included in this quick quide.


  • Easy to install and configure.
  • Secure.
  • Fast.
  • Low memory intensive.
  • Free and open source.


  • Does not support instant transfer of zone records to secondary (slave) DNS. As MaraDNS does not support “notify”, changes to DNS zone records (depending on specific setup) will take a while to transfer to secondary DNS. This will most likely be the case if you are using a slave DNS hosted by a third party.
  • No existing graphical user interface. All configuration and changes must be made through a terminal making changes to the zone files a bit complicated. Changes in the zone file are done manually using a specific MaraDNS syntax. This can easily result in mistakes leading to miss configuration.
  • Cannot explicit be used as a secondary (slave) DNS. Through some work arounds it is possible to setup MaraDNS as a secondary DNS, but the primary (master) DNS must also be running MaraDNS. Especially if the primary DNS is running another DNS program, it will require quite some customization to get instant transfer of zone records.
  • Requires restart after modifications to any settings. Every time changes are made to any settings including modifications to NS records MaraDNS needs to be restarted. Generally this will be less of a problem to most users.

In conclusion MaraDNS is a great lightweight and secure DNS option great for people wanting to learn and experiment with DNS, or for professionals only requiring simple standard DNS. For non technical users it is a hassle to update zone files, and terminal access to the server running MaraDNS is required. This can be problematic if several users need to modify zone files. Due to the requirement of manual configuration it can also be a hassle to maintain a large amount of domains, especially if modifications are made on a common basis. MaraDNS is a great choice for a low end server or VPS due to low hardware requirements.

Installing and configuring MaraDNS

It’s relative easy to install and configure MaraDNS. By installing MaraDNS you also install the recursive DNS Deadwood, but you can decide if you want to use it or not. Often it’s easier just to use a publicly available recursive DNS or one provided by your ISP.

Step 0: Preparation

Terminal access, root privileges, and static IPv4 address.

You will need terminal access to the server and root privileges. Your server must also be assigned a static IPv4 address. Optionally you can also assign an IPv6 address in addition to the IPv4 address, but this requires additional configuration not covered in this guide.

Text editor

During configuration you will need a text editor. Use your favorite text editor or install one. A very simple editor is nano, if not preinstalled it can be installed with the command yum install nano.


To compile the MaraDNS source code you will need the compiler GCC installed on your system. If you do not have GCC installed, it is very simple to install by using the following command:

# yum install gcc

Disable other DNS software

In case your server is already running a DNS program you will need to disable or uninstall it before you install MaraDNS.

Optionally find a secondary DNS service

This step is optionally, but it is always recommended to have one or more secondary (slave) DNS for your domain. Some domain registrars will even require a minimum of two name servers. You can either host your own secondary DNS, or use a third party. There are several good paid and free options. DNS and BuddyNS are two stable providers offering free secondary DNS.

Adding a glue record at your domain registrar

This is optionally, but highly recommended. Glue records are added at your domain registrar. See documentation from your registrar or contact support to get information about how to add a glue record.

Step 1: Download MaraDNS

First thing is to download MaraDNS from the official repository (you can check to see if a new version has been released, this posted has been updated to include version 2.0.15 released February 5, 2018.)

# wget 

Step 2: Unpacking, compiling, and installing MaraDNS files.

Next step is to get MaraDNS installed on your system. This is a fast procedure that only takes a couple of minutes.

Step 2.1: Unpacking MaraDNS.

# tar -jxvf maradns-2.0.15.tar.bz2

Step 2.2: Go to the directory containing the MaraDNS files.

# cd maradns-2.0.15

Step 2.3: Compiling MaraDNS.

# make

Step 2.4: Installing MaraDNS.

# make install

If you want MaraDNS to start automatically every time the server boots, use the following command. This is not mandatory.

# chkconfig maradns on

That’s it! MaraDNS is now installed on your server.

Step 3: Configuring MaraDNS files.

Now that MaraDNS is installed on your system some simple configuration is needed.

Step 3.1: Configuring the “mararc” file.

Open the MaraDNS config file /etc/mararc The file is relative self explanatory. Here a snippet of the default /etc/mararc file:

# The address this DNS server runs on. If you want to bind
# to multiple addresses, separate them with a comma like this:
# ",,"
ipv4_bind_addresses = ""
# The directory with all of the zone files
chroot_dir = "/etc/maradns"
# The following line (commented out) tells MaraDNS to look at the
# file to get the zone for
csv2[""] = ""
# Naturally, we can have multiple zone files
#csv2[""] = ""

Locate this line: ipv4_bind_addresses = ""

Add the public IP (v4) of your sever to the IP list so the list will look like this: ipv4_bind_addresses = ", <public server IP (v4)>"

Next you will need to add a list of zone files containing information about the domains that should be served by MaraDNS. One line for each zone reference. For example:

csv2[""] = ""
csv2[""] = ""
csv2[""] = ""

Every time you add or remove a domain from MaraDNS you will need to update /etc/mararc.

Step 3.2: Configuring zone files.

Each domain served by MaraDNS will need a separate zone file that by default should be saved into the directory /etc/maradns/

The names of the files should match those used in the file /etc/mararc so in this example you would need to create three files named, and

Here a simple example of what the zone file could look like:

/origin ~
# SOA and NS records of the domain. In this example is the primary DNS and are slave DNS.
% +14400 soa [email protected] 2015072422 3600 3600 604800 14400 ~
% +14400 ns ~ #This is the hostname assigned to your IP
% +14400 ns ~
% +14400 ns ~
% +14400 ns ~
% +14400 ns ~

# A record pointing to the IP
% +14400 a ~

# CNAME record pointing to the IP of
www.% +14400 cname % ~

# Another A record pointing to the IP
ftp.% +14400 a ~

# MX records for mail received
% +14400 mx 1 ~
% +14400 mx 5 ~
% +14400 mx 5 ~
% +14400 mx 10 ~
% +14400 mx 10 ~

To make the file as simple as possible I have in the first line, /origin ~ specified as the domain in question. This way I only need to type % instead of

It’s important to remember that all hostnames must end with a . (period), and all lines must end with a ~ (tilde). For example if you want to add a MX record: (or as in the example above simply use % instead of +14400 mx 1 ~

Assign a hostname to the IP address of the server running MaraDNS. In the example above this would be the hostname For example:

ns.% +14400 a <IP of your server> ~

You only need to add this record to the domain used for the NS hostname.

To add comments to your zone files simply begin the line with a # (hashtag).

This is just a simple example to get you started. You can get more details about all options here.

Step 4: Start, stop, and restart MaraDNS.

To start MaraDNS:

# /etc/init.d/maradns start

To stop MaraDNS:

# /etc/init.d/maradns stop

To restart MaraDNS:

# /etc/init.d/maradns restart

Setting up DNS zone transfers and DNS query over TCP

In case you are using a slave DNS that requires TCP and to allow DNS query over TCP you will need to configure MaraDNS to allow this. You will need to run the build in server zoneserver along with MaraDNS.

Step 1: configuring zoneserver.

Open the file /etc/mararc

Add the following lines:

zone_transfer_acl = "" 
#This allows all system to make requests to your DNS. Separate IP addresses with a comma if needed. 
#You can replace with a specific IP of the DNS slave that will make requests. Allowing all systems to connect is generally a bad idea.

tcp_convert_acl = ""

tcp_convert_server = "<IP (v4) address of your server. If you need to add more than one IP, simply separate with commas.>"
#For example, tcp_convert_server = "" long_packet_ipv4 = "<IP (v4) address of your server. If you need to add more than one IP, simply separate with commas.>"
#For example, long_packet_ipv4 = ""

Step 2: Start, stop, restart zoneserver.

To start zoneserver:

# /etc/init.d/maradns.zoneserver start

If you want zoneserver to start automatically every time the server boots, use the following command. This is not mandatory.

# chkconfig maradns.zoneserver on

The zoneserver is now configured and running.

To stop zoneserver:

# /etc/init.d/maradns.zoneserver stop

To restart zoneserver:

# /etc/init.d/maradns.zoneserver restart

Making changes to MaraDNS configuration and zone files.

You will need to restart MaraDNS and zoneserver every time you make changes to the MaraDNS configuration file mararc or add, modify, or remove a zone file.

As shown earlier this is easily done with the commands:

# /etc/init.d/maradns restart
# /etc/init.d/maradns.zoneserver restart

Every time you update a zone file you will need to update the SOA serial number as many slave DNS services only will download changes to the zone file when they notice a new SOA serial number. The example of a zone file above contains the line:

% +14400 soa [email protected] 2015072422 3600 3600 604800 14400 ~

The first number, 2015072422, is the serial. Update this number by simply adding a new value, for example, + 1 to the current number or using todays date and hour.

Setting up Deadwood

Deadwood is the recursive DNS server of MaraDNS. As mentioned earlier you do not need to use Deadwood. You can also use a publicly available recursive DNS or one provided by your ISP. If you do not want to use Deadwood you can simply skip this section.

Step 1: configuring Deadwood.

Open the Deadwood config file /etc/dwood3rc

locate the line: bind_address=""

Add the public IP (v4) of your sever to the IP list so the list will look like this: bind_addresses = ", <public server IP (v4)>"

By default only localhost is allowed to connect to Deadwood. If you need other hosts to connect to Deadwood, you will need to locate the line: recursive_acl = "", and add the IP’s of the hosts allowed to use Deadwood. Notice that recursive name servers can be abused for DDoS attacks, so make sure only to allow trusted hosts to connect if any at all. If you do allow external access then make sure to check that your configuration is safe. For example, use to check if your recursive DNS is open for potential abuse.

Step 2: Start, stop, restart Deadwood.

To start Deadwood:

# /etc/init.d/maradns.deadwood start

If you want Deadwood to start automatically every time the server boots, use the following command. This is not mandatory.

# chkconfig maradns.deadwood on

Deadwood is now configured and running.

To stop Deadwood:

# /etc/init.d/maradns.deadwood stop

To restart Deadwood:

# /etc/init.d/maradns.deadwood restart

Remember to restart Deadwood if you make any changes to the config file /etc/dwood3rc