I work as a user experience (UX) designer at Visma Commerce, striving to make TendSign – our web-based tool for public procurement – easier and more enjoyable to use. This year will mark my 10th anniversary as a UX designer, and one of the things I’ve come to believe in the most is that my work is very much about bringing product development closer to the actual users in different ways.
The obvious reason is to be able to build better products by understanding the users better, but there is also another reason that I’ve come to see as increasingly important over the years: to boost motivation in your own organization. If we increase the feeling that the work we do is actually important and means something to real people that are using the products, I am convinced that this improves the quality of the products in many ways. We all want to do things that other people care about, right?
When you feel that your work matters to others, you tend to care more about it yourself, feeling a stronger drive to improve the product and making something really great instead of cutting corners and settling with an semi-sloppy solution. I think this holds true for the entire product development organization: developers, testers, product owners, graphical designers and UX designers alike.
So in this blog post I want to share some things I’ve tried at Visma Commerce, from using screencasts to quickly reach out to a lot of users and getting feedback to making sure that our developers also get praise from the users and not only complaints.
Some of them are quite representative of classical UX work and some of them are less traditional, but hopefully they can inspire some of you to try to bridge the gap between your R&D department and your actual end users. Here we go:
1. Inspirational greetings from the users to the development team
When we did a very large redesign of TendSign, changing the entire navigation and graphical design of the system, together with a front-end developer from our team in Vilnius and a graphical designer from the team in Sibiu, I started with redesigning the user interface and created a prototype that we could show to users and get feedback.
When it was time for the back-end team in Stockholm (yes, the project was truly a multi-national cooperation!) to take over and make sure the stuff actually worked, I called one of the users who had tested the prototype and asked her if she could talk a little bit about herself and what she thought about the prototype. I then recorded a Skype call with her and could play it to the developers to show that there were real people out there waiting eagerly for them to finish the work and get the new design out the door. It was a nice little surprise for the team during the first planning session of the back-end work.
Since then, when I ask for user feedback in surveys (see below) I often also include a question at the end where users can leave a greeting to the development team if they want.
2. Nano user observations
Before coming to Visma Commerce I had worked at design agencies in Stockholm and Tokyo for seven years, doing consultancy work for various clients. It was often a struggle to get clients to pay for user observations, testing and other activities involving end users, as the clients saw us designers as all-knowing experts. During those years I got used to doing quick and dirty observations and testing, and firmly believe that something is always better than nothing.
Not long after I started here, I came in very late in a project aiming to add better support for a new type of procurement to TendSign. Development was almost about to begin and I was just supposed to do some small tweaks to a couple of screens. But I felt that I needed to see how our users actually work, because I was not sure about the best solution for some key issues. I called Arbetsförmedlingen (the Swedish Public Employment Service) – one of the clients that had an office not too far away – and they agreed to let me come and visit them.
A friendly guy called Peter allowed me to sit behind him and observe how he went about his work tasks, processing a large number of requests from suppliers to get a contract with Arbetsförmedlingen. Suddenly he opened an Excel spreadsheet and added a company name to it. When I asked about it, he explained that he kept a separate list of companies who needed to provide more information before he could process their request and take a decision. As it turned out, our system had support for three request states:
1. New (undecided)
2. Qualified
3. Disqualified
But in reality, there was a need for a fourth state: for the requests that could not be processed until the supplier had provided more information or clarified something in their request. In the TendSign user interface, those requests got lost in the huge list of “new” requests so Peter kept track of them manually outside the system, in the Excel spreadsheet.
Luckily, when looking at the request details in TendSign there was already a checkbox to unlock it for the supplier so that they could edit it and upload more files etc. So what we did in the end was a couple of quick tweaks, to rename that checkbox, show a little notification flag next to those requests in the list and finally add a filter to only show the flagged requests.
The project had been going on for months, with several meetings with an end user reference group and a lot of requirements discussions back and forth, but no one had ever asked for something to make it easier to track “pending” requests. However, 1.5 hours of observations with just one end-user revealed the obvious need for it – a need that could be met by just tweaking the user interface a little bit. As an added bonus, the “flag” feature is handy also in the classical procurement processes where the number of requests or tenders is not as high as in the newly added special process. A fine example showing that even “nano” user observations can be very valuable!
3. Making sure developers get praise and not only complaints from end-users
Continuing the heartwarming story of Peter and the flagged requests above, the implementation project was done under crazy stress and like I mentioned the project had been going on for months before I got involved. Despite me coming in at the very last moment with completely new feature requests, one of our senior developers agreed to do the tweaks needed for the “flag” feature.
A few weeks after the feature had been released, I was curious about whether it was just a good idea that would be more of a nice-to-have than something bringing real value to the users. So I contacted Peter and asked what he thought now that it had been released. He forwarded my question to his colleagues and I received a lot of nice feedback, that I sent to our developer and also thanked him for implementing it despite the crazy time constraint and the feature being out of scope. He was very happy and thanked me, noting that as a developer you almost never hear about positive feedback from end users – only complaints when something is wrong.
4. Recording a sneak preview video of a new tool and asking for feedback
We are currently rebuilding some core features of TendSign from scratch. Early on in the project, before we got a demo environment that was accessible from outside of Visma’s corporate network, I recorded a 7-minute screencast where I demonstrated what had been built so far and explained some of our main ideas for the new system.
I used the movie as a little teaser when inviting people to take part in a reference group, where they would be able to follow the development and be involved. I also asked them to send feedback on what they saw in the “sneak preview” movie. We got a lot of feedback and kickstarted engagement in the new project, with many people signing up to be involved.
5. Combining screencasts and surveys as a complement to prototype testing
Even now, after we got a publicly accessible demo environment, I have continued using 5-10 minute screencasts as a tool to solicit feedback, most often with a structured Google Forms survey with specific questions around the screencast. It has turned out that it seems to lower the threshold for people to get involved and leave feedback. Of course, this can not be the only way to validate the design, since you are explaining exactly how the user interface is supposed to work but to quickly get feedback from a lot of users it can be very valuable. I have even been using the screencast format to show rough UI mockups of features that have not yet been built and talk about them.
With that, I leave you for now, but don’t hesitate to get in touch if you have comments or want to know more about any of the things above!
