Topics

Featured in Development

Understandability is the concept that a system should be presented so that an engineer can easily comprehend it. The more understandable a system is, the easier it will be for engineers to change it in a predictable and safe manner. A system is understandable if it meets the following criteria: complete, concise, clear, and organized.

Featured in Architecture & Design

Sonali Sharma and Shriya Arora describe how Netflix solved a complex join of two high-volume event streams using Flink. They also talk about managing out of order events and processing late arriving data, exploring keyed state for maintaining large state, fault tolerance of a stateful application, strategies for failure recovery, data validation batch vs streaming, and more.

Featured in Culture & Methods

Tim Cochran presents research gathered from ThoughtWorks' varied clients and projects, and shows some of the metrics their teams have identified as guides to creating the platform and the culture for high performing teams.

UI Design: Go Out and Get Data

Chris Atherton did the closing keynote of the GOTO Berlin 2015 conference in which she talked about designing software. She suggests that, in stead of relying on professional opinions on how software should look or work, it can be better to go out and get data from real users. InfoQ interviewed her about designing and testing user interfaces.

InfoQ: In your keynote "You Can’t Always Get What You Want" you talked about designing how a system should look or work. Can you elaborate why it’s important and what can make it so hard?

Atherton: Badly-designed user interfaces (UIs) fail to take into account who is using them and the context of use. Sometimes the effects of that failure can be mildly irritating (at best, maybe you don’t like the aesthetic) and sometimes it can actually be a matter of life or death, as in the aero or medical industries. In practice most of the cases we encounter are somewhere in between. Some UIs are frustrating to use because they aren’t sufficiently clear to the people who need to use them. Others are inefficient and fiddly because they weren’t designed in consultation with actual users and so the workflow is poor or there is a mismatch between what the person needs to do and what the UI will let them do.

UI design can be hard, but it’s achievably hard. Where it gets impossible is when there is no access to real users, so the designers and development teams who are actually building the product have to make guesses. No matter how well motivated the team or how much they try to make good guesses, they will never be 100% correct, because they are not the users. Having said that, this is an easy problem to fix: you just need to give software teams regular exposure to real users, and the chance to show them prototypes and get feedback, and to iterate based on that feedback.

InfoQ: When designing a system people often bring in their own experiences and ideas on how they want the system to look and act. Is that good thing?

Atherton: Assuming that you start with some idea of what the system actually needs to be able to do, there’s no harm in people bringing their own ideas to the table — it can be really helpful to have people on the project who recognise the patterns between what is required now and things they have worked on before, because there might be some easy design solutions to those problems that you can port straight across, or adapt with minimal changes. But that can’t be where it ends: the design of the new system must be driven by real user needs, not by adapting the problem to look like one that we’ve solved before. Again, by exposing the whole team to real users and their real problems, we break out of our existing ways of thinking and we get feedback about the designs we thought would be good but actually aren’t quite right. Also, it’s not enough to have an opinion about how a design solution should work: you have to test it, and get real data about its usefulness. So there’s often not much point in two people in the development team having an argument about whose way of doing things is "better" — show the users and let them tell you, since they’re the experts.

InfoQ: Can you give an example of when good design intentions weren’t enough? An example where they hindered UI design?

Atherton: Well, firstly I guess I should point out that nobody deliberately hinders anything — we just don’t always have all the necessary information at our disposal :) So as an example, I once designed quite a fancy dashboard for a client. I was given the requirement that users had to be able to view and change the values of the variables shown on the dashboard. And I put quite a lot of thought into the layout and interaction design, like making it possible to search, filter and sort the variables, because there were lots of them and you don’t want people to have to search through a long list for the thing they want. And then I showed it to the client and they said "but actually the end users of this are only going to want to view about 6 of these variables, and which 6 they want to view is very predictable, and of those 6 they might only change 2 or 3." Which totally changes how you might tackle the UI! So while I had really good design intentions, trying to use well-established design patterns to make this thing easier to use, it didn’t actually map very well to the kinds of things users were actually going to do. We ended up with a much simpler design that showed the bare minimum of things required.

InfoQ: Your suggestion is to get data instead of relying on opinions. Getting data can be difficult, it may take a lot of effort or come with a price if you want to have real evidence from actual users. How can you deal with that?

Atherton: First, I think getting basic data is actually pretty cheap. You identify someone who can give you meaningful feedback (could be a real user, could be someone who’s a reasonable proxy) and you sit with them, in person or remotely via the internet, and get feedback on designs or working prototypes or whatever you can stand up quickly. Right from that session you already know some ways in which the design needs to change. If you can do that a few more times you can be a bit more certain about what the most crucial bits are, for example because you’ve seen, 4 out of 6 people fail at doing something, or because even one person can’t do the thing they need to do — that one person could represent hundreds of thousands of real users.

But the other angle is that no company can afford *not* to do this work: it is the absolute #1 way of reducing project risk. Because building something for users if you don’t understand their needs can be very costly, very risky. If you only identify problems in your design once everything is built, then you’re either going to release something that isn’t fit for purpose, which is a huge risk, or you’re going to be making a lot of costly changes, which introduces its own kind of risks.

InfoQ: Can you mention some approaches that people can use when they want to test the design of their software product?

Atherton: Absolutely. The lightest-touch approach is to sketch, on paper, whiteboard, wherever, and show it to people internally so there is something to point at while you explain what you think it’s going to do. Having a shared understanding of the work to be done is vital; sharing even a quick sketch can surface a lot of assumptions, especially when there are lots of people with their fingers in the pie. If it’s a more complex scenario or you want to show it to end users, you might put together some wireframes or mockups in tools like Balsamiq, Axure, etc — these don’t have to be high-fidelity, they just have to be clear in their visual layout. You can ask people what they understand is happening on a given screen, and ask them what they would do next and what their imagined outcome from that would be. Better than wireframes is to actually make a clickable prototype: this doesn’t have to be high-fidelity either. It will show interactions and transitions, so users and internal stakeholders get a better idea of the flow from one screen to the next, and begin to understand what user journeys might look like from end to end.

There’s sometimes a debate about whether you should be prototyping in production code (so any design changes in response to feedback are quick to make, but standing the prototype up in the first place might take longer) or whether it’s okay to just use disposable prototyping tools such as Sketch and InVision, where it’s very quick to spin up new designs and make them clickable. I don’t think there’s a right answer: it depends on team’s available resources and skillsets. The important thing is to show people something, anything, to get fast feedback.

InfoQ: Is there any further advice that you want to give on designing user interfaces?

Atherton: Getting some feedback on your designs is always better than getting no feedback. Even if you only speak to one user, you will always learn at least one thing about what you could be doing differently or better. And it doesn’t have to be costly or time-consuming: in fact if you look at the cost of spending 6 hours with users vs. the potential cost to the business of *not* spending those 6 hours, it’s a no-brainer.