I see design and development as a continuous process and importantly, a single team effort. I wanted to capture some of the passion from our software engineers, the passion for blurring the boundaries of design and development, the passion for being a software engineer who cares about users and using researching efforts to inform the products we build. To this end, I could think of no one better than our very own, Elena Vilimaite.
About Elena
El joined us last year and has since worked across multiple customers delivering public sector digital services alongside civil servant multi-disciplinary teams. Currently El is working for central government organisation building tools that enable government departments to digitise paper forms, rapidly.
What follows is an informal Q&A between myself and El.
What excites you about being a software engineer?
“I want to build products that people actually use. This is particularly exciting within the public sector. I love the challenge of government – it’s big and often stuck in the past so there is an opportunity to make a big impact.
I love understanding users and gathering requirements. My parents used to ask me to fix issues with our computer, or help them to buy online, and I’m driven to empower users like my parents to do things themselves. That’s why as a developer I’m keen on making sure a product is fit for purpose through continued user research and I love to be a part of that process.”
How does a developer get involved in user research?
“I’ve actually been involved in user research before working at Made Tech, at a charity I previously worked for. We used focus groups to provide feedback on web applications. We would sit in another room watching videos of users attempting to use the products we’d built. We’d have to put our hands over our mouths to stop us shouting at the users for not using the software in the way we had intended. It was a really good lesson. We used those sessions to iterate on usability.
More recently, for a local government organisation, we were building software for staff users. We would collect feedback on a weekly session, both with managers and day-to-day users, separately, to understand the varying needs of the product. We would also shadow staff as this was the most insightful way to really find out what people were thinking.
Of course, it’s not about doing everything a user asks, it’s about distilling their feedback. As much work is needed in order to turn that feedback into something usable, if not more than the actual work itself to implement it.
Lastly, we had showcases and demos with users on a regular basis to introduce new functionality in order to help with its adoption.”
Why do you think it is important for a developer to join in with user research?
“As a developer you need to understand how a product will be used. What you build should not require specialist training. We are building self-service software – it needs to be usable, for users to be autonomous.
Software engineers can help uncover technical feasibility with technical discoveries. You can hear what users are asking for, what designers are recommending, and then a developer can provide feedback on what is realistic. Designers can interpret usability from research, but it’s the developers who can determine feasibility. Having first hand context of research is invaluable for this.
If the whole team understand context, understand users, and have empathy for the user, the team can function better together, working towards a common goal, delivering successful outcomes for the user.”
Can you tell me more about technical discoveries?
“Technical discoveries are about researching technology to understand feasibility. You might do some in depth analysis of APIs you are considering integrating with. You might want to better understand non-functional requirements including security and maintainability. You might want to interview other developers who may consume an API or using a developer tool you are planning on building.
Actually a lot more technical research should be carried out during discoveries, much more than currently is at least.”
Are there challenges having developers get involved with user research, or designers getting involved with development?
“It’s positive if the whole team are aligned, and want to work with each other in this way. It wouldn’t be fair to burden a developer with user research unless they were keen. Problems can arise when taking on a role that isn’t fun to you.
It can also lead to overworking, you need to understand that if you are partaking in user research, you won’t be able to have the same velocity as you would if just doing development work within a sprint. This needs to be factored into planning.”
What advice would you give a developer joining in with user research?
“Listen. What you hear might not always be pleasant or useful. There is meaning behind what people say. They are the users or future users of the software you a building. Build something you would want to use yourself, something you can be proud of. And be prepared to compromise.”