User Experience is full of surprises. Each challenge is a bit different, necessitating a unique approach. Good User Experience (UX) achieves the goal of the software and meets the expectations of the user.
Recently I was invited to speak about User Interfaces & User Experience during the Future Trends in Nuclear Physics Computing workshop at the Thomas Jefferson National Accelerator Facility (JLab) in Newport News, Virginia (program info here). I was quite excited as I am a bit of a science nerd and I was interested to see what kind of unique UX & UI challenges these scientists face and how I could help.
There’s no checkered flag when a piece of software achieves “good UX” – it’s an ongoing process of iterative improvements driven by data and insights. However, you can gauge the quality of an application’s UX by simply working with the software – good UX is usually completely transparent. Most times we notice bad UX because it is frustrating or doesn’t work the way we think it will. Bad UX can result in people not using software, or, in some circumstances, can even be dangerous.
One JLab scientist brought up a good point, mentioning that the user of most of the software are scientists who are used to command line interfaces. In this case, is good visual UI needed at all? The answer to that question could very well be ‘no.’
Sometimes it’s all about the initial question. If when we went to the moon we asked “Is there a reason to go to the Moon?” the answer may very well have been ‘no’ as well. But what if we approach this question a little differently, like ‘How would good UI affect our scientific process?’ we might get different answers. Here are a just a few ideas showing how changing the question can change the experience.
What if the UI was so simple even someone unfamiliar with the experiment could use it? Then they could use lab assistants or even volunteers to monitor the experiments while they do other important tasks. Imagine a scientific experiment where all kinds of users can take part and the visibility that would bring.
What if UI elements like alerts were activated so a scientist wouldn’t have to keep their eyes glued to a screen, but could get alerts if something started to go wrong?
The Funding/Stakeholder Element of Design
Scientists also have to apply for grants by showing how their results could impact the world or the scientific community. Many people they will present their experiment to during this application process aren’t in the scientific community. So a good User Interface may increase the understanding of their experiment and make the information more accessible to those outside of the scientific community.
My job as a UX/UI Designer is not only to design better software, but to present the software in an understandable and engaging way to project stakeholders. This means I’m not always presenting UI directly to the user. In most cases, I must present to clients and stakeholders that don’t always have a thorough understanding of every use case. Many times, they come to the table with their own agendas based on business objectives for a piece of software without fully understanding the software from the user’s perspective. In these instances, it’s vital to present a UI that clearly shows how the software fulfills the user’s needs and, in so doing, accomplishes the business objectives.
It can be difficult for those outside of the scientific community to understand the complicated inner workings of scientific experiments. Yet, communicating the details of these experiments and the value they bring to stakeholders within the complex infrastructure of governments and universities is what allows scientist to continue their work. This makes creating a simplified User Interface to present experimental data even more important.
One of the requests of the workshop was to present a “User Interface 101.” The organizer said ‘Most people in this community are used to command-line interfaces and have no idea how to group information and design a GUI that focuses on the user and not the program.’
Given this request and not knowing the specific challenges they faced, I wanted to plant some seeds in what I’ve generally found makes good UX/UI. A lot of UX is the approach, asking the right questions, and opening your eyes to how people are actually using the software instead of making assumptions. You can read through my presentation deck here.
There were a lot of questions during the Q&A portion of my presentation. Luckily, I had the last slot of the day and there was an allotment of discussion happening after, so quite a few people asked questions and spurred some great discussion.
I learned a lot about the process these scientists work through for their experiments. I’m sure it gets way more complex than this, but let me summarize the process based on my observations:
From what I gathered, they essentially have to design two types of UI, one for the running of the experiment, and one for the interpretation of the data results.
$ & Specialization
In the scientific community where funds are typically from governments and universities and money is tight, scientists must do a wide range of complex tasks and there isn’t much money for dedicated resources or much specialization. Many of the scientists I spoke with are also coders and code most of their experime
nts themselves in Java or other languages. It’s quite amazing the wide range of tasks they face.
In some ways this is not unlike my own experience as a UX/UI Designer. In a full-blown, consumer facing app, a UX/UI Designer might work with other disciplines and spend weeks crafting a superior User Experience. With smaller projects and smaller budgets, there’s not as much time available for design or UX and many might do little user testing or QA (quality assurance). As a UX/UI Designer, I’m constantly challenged with how to make better software with a limited budget or time frame. Below is a list of possible solutions that even non-designers with little UX experience can use to craft a better User Experience.
1. Define the User
One particular area that goes a long way in software design is defining the User using user personas and user stories. Basically, what we want to do is define who will be using the software and what situation they are in. User stories help define why the person is using the software, which helps bring out key elements (#2 on this list). At a basic level it doesn’t take much time, but better software usually takes into account all the different types of users and edge cases.
2. Prioritize key elements & rank importance
Before building software, it’s good to come up with a detailed list of what the software is supposed to achieve. Sometimes software is confusing or hard to use because it tries to do too much and doesn’t do any one thing well. Rank what the software should do and list the order of importance of features. Sometimes this helps cut out features that could be added later or can be removed, and makes sure the features that are important and will be worked on most will have the the biggest impact. Doing this before you start on any User Interface design can be helpful, because you’re thinking about features from a top level instead of how they look, separating function and form.
3. Use resources around you to conduct usability testing
Sometimes colleagues, friends and family are incredibly valuable resources. I constantly show my work to people who haven’t seen what I’m working on to get their thoughts. This allows me to get an opinion that is less biased than one of someone who has already seen it. Conducting usability testing with the people around you can give you insights into the User Experience of the software you design. Many times, they will give you insights on obvious things that somehow were missed. Or they may add a small idea that has a big impact. I can’t tell you the amount of good ideas I’ve generated from showing people and incorporating their opinions.
You can test people with drawings, mockups or complete software. Try not to guide them, but ask them to complete a task and sit behind them and see what they do. You might consider asking them to talk out loud what they are thinking. This is very basic user testing anyone can do, and in my experience, the insights are always unexpected and highly valuable.
4. Leverage knowledge and online resources
The stacking of technologies is what makes the pace of technology so fast. We are in the era of software creating software. A designer uses software that runs on software to design software. If designers had to start from scratch, we wouldn’t have any time to develop and enhance the look and feel of the software we create.
Designers have created a community to share resources for the platforms we design for. We have magazines and blog articles. We have created UI kits and icon kits so we can make things faster and more conducive to the platform, giving us more time to concentrate on UX and harder problems. Developers have done the same thing with GitHub. Front end developers could use WordPress or something like Basecamp. Leveraging knowledge and prior work is key. Anyone developing software can find free icon kits and code to reuse from a multitude of resources.
During the questions I suggested the scientific community do the same. If one scientist has built an interface, reuse it if possible. Share knowledge. Build upon what other people have done, what works. It was great to see a few people in the room had already leveraged these resources to increase the impact of their UI.
It was a fantastic opportunity to learn the current challenges of scientists from places like NASA, MIT, JLab, & Fermi Labs and how they are learning to overcome them. I trust my presentation, talk, and this blog article can improve the spread of good user experiences and encourage a multi-faceted approach to improving software for the people who use it.
Links:
Future Trends in Nuclear Physics Computing
March 16-18, 2016
Thomas Jefferson National Accelerator Facility
Newport News, VA