Posted on

Sveaskog – Property management system

  • Storyboard visualizing a scenario where the mobile app is being used.
    Storyboard visualizing part of one of the scenarios. During the project I sketched hundreds of quick storyboards and more detailed UI sketches.

Sveaskog is the largest forest owner in Sweden and sells saw logs, pulpwood and biofuel. Sveaskog also works with land transactions and develops the forest as a venue for hunting, fishing and other nature-based experiences. In order to keep track of all their properties they were using two different systems that were developed in the 90’s in what was then two different companies. For many years the company had made many attempts to replace these two systems with something more modern that would be easier to understand for new users. But for different reasons these attempts were not successful. In fact within the past five years there had been so many attempts to replace these systems that the employees had lost all faith and were no longer motivated to take part in the workshops for the current project. The project manager knew that without the trust of the users this project would be added to the list of failed attempts, and the stress was even higher given the tight deadline.


My first challenge being to gain the trust of the users I had to help the project manager finding a new plan for requirement analysis. We both agreed that the users need to see some concrete work very soon. Therefore I:

  • Introduced the user-centered design approach to the project manager, the users and the steering committee.
    We agreed that I need to start sketching very quickly, and we’ll have to do the design research along the way. Asking for more time to “understand the users and their situation” would most likely result in mutiny of the users. Instead I read up on the old material, so I could show that I already knew a lot of their thoughts and needs when I introduced them to the user-centered design approach. They all thought it sounded interesting, and everyone was more motivated after my first meeting with the users (even though some were still skeptical). I also introduced the steering committee to the approach, so that they would let us have access to the users as needed.
  • Set up a project plan for how to integrate the user-centered design approach with the agile approach of the developers.
    The project manager was under a lot of stress, and was only working part time in this project. I helped her by proposing a workflow from design research, to requirement analysis, to development. We divided the system into themes and within each theme we worked with a highly iterative approach to create user stories, sketch user interface, evaluate sketches with users, document (shortly!) requirements, develop and then demo for the users (and others with interest). This approach let me work tight with the users as well as the developers on a daily basis. Instead of detailed design specifications we discussed one-on-one or in group while looking at conceptual sketches and what had been implemented.
  • Performed contextual inquiry with simple sketches.
    As there was a lot of material from the earlier attempts I was able to sketch some ideas of a user interface before my contextual inquiry session. Over a number of sessions with 10 users I combined design research and iterative enhancement of the sketches. Through my meetings with users I realized that many users to a large extent were unique in their usage of the system. Many of the users performed tasks that no one else did. And because there were two different systems some tasks could be performed in either system. This gave us important input for the design of the new system as well as for prioritizing different modules and functions. It also informed the product owner of a new problem – there was a lot of data in the old systems that have to be consolidated.
  • Designed a product vision.
    When I joined the project there was a long list of 500 requirements in an excel sheet. Through my design research I steered the team to document a more accessible product vision. I created personas, updated process flowcharts, written scenarios and conceptual sketches. We used the vision to introduce new team members (e.g. developers) as they joined, to get feedback from users, and to communicate with the steering committee of the product.

Personal learnings

To me this was a very fun project because it was very challenging in the beginning, but very rewarding to see that I could win the trust of the users so that we could work creatively together – designers, users and developers. It proved to me that I can introduce non-designers to design thinking and convince them of how good it is! I also got to take a big part in managing the project, while leading the setup of the project plan.

Among the user group there were some that were always very skeptical whenever I presented an idea that was not as it used to be. This was a great way to remind me of the importance of balancing listening and observing. The user would say that it was a bad idea, but if I would test a little scenario with a simple prototype they would (often) actually like the idea.