Case: Björkviks Takstolar

June 9, 2017

In 2015 I developed a website for a Swedish trusses manufacturer, Björkviks Takstolar. They explained that they wanted to construct an approach for their customers to order trusses online. A website was developed thus creating a business to customer relationship in an online setting. In spite of mostly delivering locally, around 10% of the orders are made through the website. According to employees at the company, their customers have voiced their appreciation of the online solution. 

Björkviks Takstolar has made minor changes to the website since then, added a logo and removed textual content on their frontpage which will be updated in a later stage according to employees at the company.


Defining the goals

With a meeting with Björkviks Takstolar they explained that they wanted an online approach for their customers to order trusses. It was made clear that Björkviks Takstolar always wanted to follow up on an order as they wanted to have a direct contact with the customer before starting construction.


Breaking down the task & information architecture

Therefore, a strategy was established to create an online shop with contact possibilities; although, arguably, the website lacks high complexity a user flow was constructed according to how a potential customer would go about ordering trusses online. An interview was conducted with a carpenter concerning what would be needed in a potential online form to order trusses. By conducting an early interview it enabled a process of learning, exploring a design, developing after early usability testing, and then refining the design in later stages. According to the carpenter (and Björkviks Takstolar) it would be highly unlikely that someone would want to order different trusses in one order and the interviewee felt they wanted a straight sequential path.


Hierarchical task analysis of customers’ online ordering of trusses.

Furthermore, by the interviewee mentioning having a “straight path”, I continued to built on the narrative for closely related pages and decided to try out a design that was heavily dependent on using modal windows. Although this entails not having to jump around onto different pages it still follows the classification of having a index page (home page or front page) leading to subpages.

Sitemap of navigational structure of website. 


Usability tests on early concept

Following the information architecture (displayed in prior section) mockups were created and later on tested on users with a paper prototype; unfortunately as this portfolio was built two years after this case I don’t have any prototypes to show. It became clear that the participants of the usability tests appreciated the few pages and relatively plain hierarchy. After testing with a low fidelity prototype the website was digitized using Balsamiq. When digitized, the same participants were recruited once more and then it became clear that one participant stated they wanted to have an option to add a sketch to their orders. The participants also stated that they wanted a sketch – as it would work in a blueprint – of the truss with variables making up a clearer picture of what needed to be done within the form. The digitized prototype also had a top-to-bottom hierarchy of the different stages within the form: enter measurements, enter tass (end of truss), and information about the buyer and delivery. The different stages constructed a hierarchy of the form to be filled. And as we know, by developing an hierarchy of information it easier to determine where things are and humans tend to be better at using applications in that way (Cooper et al. 2007, p. 187-188; Dix 2009, p. 28).

A prototype similar to the one used in the actual case.


Delivering & adjusting

After an additional set of tests the developing stage was ongoing where I programmed backend functionality as well as frontend. Furthermore, after initial orders it became apparent that some of the terminology was not understandable in a user perspective. Again, showing value, importance, and weight in a UX writer role in the grand scheme of things. One of the things that confused users were one of the original inputs in the form mentioning the “usage of the trusses” where Björkviks Takstolar wanted the customer to specify if the trusses were supposed to carry extra weight (cargo/load). However, customers seemingly did not know what to specify in this input thus the terminology was changed to “enter extra cargo/load” and added to the top of the form where the user specified trusses information (such as measurements). This goes to show that, even though the early usability testing was beneficial to the design, recruiting real participants (i.e. people wanting to buy trusses in this instance) would most likely exterminate the terminology issues.


Happily ever after

Björkviks Takstolar has voiced their customers’ appreciation of the website. Even though a relatively small company, the website gets quite a lot of visitors. Approximately 10% of the orders come through the website. Arguably, a large part of the target group of Björkviks Takstolar do want their orders to be through phone or at site for mentioning specifics and having a constant conversation. Consequently, the company itself want the orders, through the website, to be followed-up on by phone or mail.

Even though this case was not heavily UX oriented I still believe that the iteration of usability testing helped the construction of the website. Most of the work, in terms of time, was programming which was a good experience in itself.


Visit Björkviks Takstolar at



Cooper, A., Reimann, R., & Cronin, D. (2007). About face 3: the essentials of interaction design. John Wiley & Sons.

Dix, A. (2009). Human-computer interaction (pp. 1327-1331). Springer US.