Continuing my AI Design Principles series. While this post doesn’t specifically reference AI design, it is to open a discussion that will continue in Part 2.
There’s a common challenge in system design in general that applies strongly to AI design – making sure that your system solves the problem at the correct level of abstraction. In general, this can be posed as the question “does the system let users communicate my problem in the same way I think about it?”
Imagine the interface to work a car:
- the steering wheel
- gas pedal
- brake
This is exactly the correct level of abstraction – each component has distinct uses that are mostly orthogonal and the controls correspond to how we think of driving, e.g.:
- “turn left” -> rotate steering wheel counter-clockwise
- “go faster” -> press down on gas pedal
- “make a sharp right turn” -> use brake to slow down to appropriate speed and turn steering wheel clockwise
Level of Abstraction too Low
This is the mistake I see most often in system design – making controls too granular.
Imagine if instead of one steering wheel you had four, one for each wheel. This would be madness and unnecessary for most people. While you would (technically) have the ability to steer more precisely than with just the one steering wheel, most people would not intuitively know how to use the controls to steer the car. For example, you can’t just rotate all of the wheels the same way – that would change the direction of the car but not actually change the direction it was pointed.
Designers make this mistake when they design too much for super-users. While they exist (and may be very loud), in most cases they aren’t the bulk of your users. Adding the ability to tune everything is often at the expense of making it easier for new users – adding a large learning curve as well as usually mandating setup before even using the tool at all.
I recognize this one when I think “I know it’s possible to communicate what I want to the system, but I have no idea how.”
Level of Abstraction too High
This is the opposite case – where individual controls try to do too many things that common activities aren’t possible. I see this is less often, but it’s no less a hindrance.
Now imagine if your steering wheel controlled both direction and acceleration – with the acceleration lower the more you turn the wheel. The designers were probably thinking “When I’m not turning I want to go faster, and when I’m turning I want to go slower, so let’s tie those things together!” They neglected the obvious (to the user) case of stoplights and traffic.
This is more often made when designers don’t go through the legwork of requirements development. I’ve had the experience more than once of sitting in a room where people are happy to hallucinate the problems of users and avoid actually talking to them. If you only understand a subset of the problems users have then your solution will be incomplete.
As a user, this one is characterized by thoughts of “It isn’t possible for me to communicate what I want using the controls given to me.”
If Users Think at the Wrong Level of Abstraction
One danger is if users have only worked with solutions at the wrong level of abstraction. They may have been trained to think at the wrong level, and in requirements development your job is to divine that.
Suppose you are designing an app that lets people make artsy customized tables and all of the competing apps require users to create and upload .svg files of the shape and size of the table top. When you go to users, they talk about streamlining the .svg upload controls to make things like scaling easier. Another common complaint is that it is too hard to find exactly the coloration pattern they want – the selection other apps offer isn’t big enough. You ask several to get a sense of the sorts of tables they make, finding that most go with rectangular table tops but vary wildly on the coloration.
It strikes you that it should be easier to tell the system “I want a rectangular table top with these dimensions” since it is such a common use case. The bit of intuition here comes from looking for patterns in how users use the tool. When a user thinks “I want a rectangular table top” they aren’t thinking “I want a table shaped like this .svg file” even though that may be what they may literally say. The users are thinking at too low of a level.
On the other hand, you notice that the table coloration patterns users want varies so wildly that each requested pattern would essentially just be used by one person. As many of the users are artists themselves, they show you pictures they’ve drawn of their dream table coloration but have no way of telling the apps (or, for that matter, finding a close one in the thousands of different patterns available). In this case the users are thinking at too high a level of abstraction – there really needs to be a way for them to just upload their own designs as the coloration pattern.
Choosing the Right Level of Abstraction
This requires actually talking to the people whose problem you’re solving – requirements development. The point – too often overlooked – is to figure out (1) what problems your users have and (2) how your users think about those problems. They’re not the system designer – you are – so of course you won’t usually be able to literally use their suggestions. That doesn’t make what they say any less valuable.
When I go through this part of the design process, I ask myself these questions about the system I’m designing. Does the system:
1. allow users to solve most problems the users have?
2. communicate possibilities in the same language users think of their problems?
3. make it easy to solve problems that are easy to think about?
4. allow for too many nonsensical inputs?
In the car example where the level of abstraction was too low, it is easy to think “I want to turn left” but difficult to communicate that to the system through the four steering wheels. This violates (2) and (3). It also lets the user do many things that don’t make sense – like turning the left wheels to the right and the right wheels to the left, violating (4).
These aren’t easy problems to solve. Choosing a good level of abstraction requires a mix of talking to people, thinking about how they perceive their problems, and being aware of the larger context influencing how people talk about what they need.
