I have worked with some fabulous user experience designers who have really changed the way that I thought about a problem. A great designer can get into someone else’s head as an artist, can generalize from observation as a scientist, and can develop and communicate their design like an engineer.
I have also gotten frustrated with some of the user experience designers I’ve worked with, though I think it’s not really their fault: their tools and incentives let them down. Pixel-perfect mockups in Sketch or Figma lead everyone to focus on the wrong things, and the designer’s next job interview is going to need to see a portfolio of lovely images. Consequently, while they will talk about user experience during the interview process or over beers after work, what I actually see in work product and hear in working sessions is lots of concern over user interface. A rare few have done formal user experience testing; a great many are pushing pixels around. How the product looks, how it lays out at different resolutions, the colors of the buttons. Is it clean, uncluttered, does it pop.
What really bugs me is the interface-focused concept of progressive disclosure in which we end up with lots of little kabob menus, advanced mode twisties, and invisible hover-states. Oh how I hate progressive disclosure. The feature you’re looking for is in the hamburger at top left… no, the slide out draw on the right, or maybe it’s that twisty at the bottom center, no the other one with the strange icon and a tooltip saying “advanced”. Maybe it’s in the context click on the object’s grabby handle, the plus sign by an object container, the pencil icon by the object name, the ellipses menu that sometimes appears when you hover at the non-grabby corner of a container, or maybe a context click in the middle of my screen? I once documented a port of a three click process to a tool built like this, it ended up needing fourteen clicks.
These are some user experience design principles I like to steer with instead.
Whatever you’re building is a consumer of whatever exists
Unless you’re at ground zero of a new startup, you’re probably making a product to work on another product’s platform or a feature to improve an existing product. This new thing produces or receives data, makes decisions, takes actions, records results. If the existing product/platform already has sufficient support for those functions, then use it instead of reinventing the wheel; if it doesn’t, then your best outcome is to get it extended with the necessary capabilities. The reason for this goal is to reduce the amount of new user experience that you have to create: your new thing should be using or extending the abilities of the existing product. Can your new thing be built entirely from existing components? Why not?
Intuitive flows come from sticking to established patterns
Enterprise software has a very small set of common patterns. That is not an invitation to break the mold and forge your own path.
- There is a navigation bar with highlights or a breadcrumb tray or something to indicate the user’s current position in the object space. This is probably on the top edge or the left edge. It might be complicated with folders or accordion sections or submenus.
- There’s a settings manager and state tray, usually together in one of the corners, where the logged in user is named and notifications are surfaced. That’s never the only place notifications show up, of course.
- There is a landing page where common task entry points are called out, and maybe a guide to the categories of objects or tasks in the product. Executive staff may have large sway over this area, and it may look more like a marketing web page than a product, which is typically great for new users’ First Time Run (FTR) experience. Expect there will be some way to turn off the FTR and customize this page for regular users.
- For each type of object, there are lists of objects and CRUD forms for those objects.
- In a few cases, you may need to view or manage relationships between many objects on a graph or in a table.
- If your objects are very complex, you might want a fancy listing page with expandable ribbons instead of simple table rows.
- The lister should be searchable and the search should work on all fields.
- The CRUD form should reveal all object metadata.
- It should be clear when you’re using a CRUD form if you’re able to edit, if you have edited, and if your changes take effect immediately or when you click a button.
- For each type of task, especially if it’s a licensed sub product, there will be at least a listing page for related objects, if not a landing page for that task or product.
An experience that is consistent with user expectation is more important than patterns and principles
The prior principles are great, but they can conflict with each other. Principles are not a good reason to force a square peg into a round hole. Your job is to make a successful product for a market. If the users in that market expect an object visualization that doesn’t line up with anything your existing platform has done, that means you need to expand capabilities to match the market. Said differently, don’t re-work common interactions so they align with your internal abstractions: instead, expand your platform to support the new user’s experience. If the user needs to publish static reports and you only have interactive dashboards, you should make a static reports feature.
Compliance is not just a good idea, it’s also a requirement
If you think about ADA and WCAG and translatability now, then we won’t have to fix those things later. Please use text buttons instead of images, please don’t hide necessary functionality behind menu objects, and if you’re going to put a set of controls into a Subject-Verb-Object sentence construction, please consider how that’ll work in German and Japanese. Even if you don’t do those translations today, chances are good that when you do, you’ll have to do them in a hurry to win a deal. Better to ensure that it’s easy then by using a design that could work now, even if time constraints make you leave it imperfect.
There is an alternative approach to planning ahead of future requirements: some people say software ages like milk, not wine, and they’re often not wrong. Many projects are built more like a strip mall than a cathedral, front ends need to be rewritten in the latest framework every five years anyway, and you might as well tear it down and start over when the new requirements come along. It can be demotivating to tell your team that though, especially if you have a lot of less-experienced developers. My opinion is that both approaches (planning ahead for future requirements or accepting that the future will require restarts) can work. Just be aware of which one you’re selecting and why so you can speak clearly to the team about choices made.
Design Is How It Works
Apple in the 21st century is a Microsoft class juggernaut, and a resulting prevalent theory is that their user-first attitude to design is why. From Steve Jobs to Jony Ives to Ken Kocienda, the message is clear and attractive. Don’t confuse the user with extra fluff, do bring focus to the job at hand, and let the care of your craft shine through. I think that last point is where enterprise folks can get confused though, especially if they’re not really close to the pain the user is trying to solve. Every graphic designer or user experience designer is personally a computer user, and it’s probably a Mac; every designer is spending most of their work day in a browser and it’s probably Chrome. They can empathize with the decisions that go into OS or browser design. I’ve watched these designers struggle to make the leap to empathizing with a data analyst making charts for a report, or even understand the task at hand. Sometimes we have to reject lots of nice looking but counter-functional design which makes assumptions that don’t understand where the user stands in their organization’s priority stack; as a blunt example, a patching process that doesn’t allow stopping or rolling back isn’t going to fly in production.
The user, enterprise or otherwise, is not in your product to appreciate your interface design, they’re here to get a job done. They don’t want it to be distractingly ugly, it should look like it’s worth the eye-watering cost, but amazing instead of nice won’t win a deal. This is why wireframe products exist and are a good tool to use. That said, a sufficiently determined designer can waste as much time in Balsamiq or Miro as they do in Figma. When the situation is that desperate, I’ve also broken UX logjams by drawing on a whiteboard or with a pencil on paper. Tools can distract from the task, and experts in tools can forget that because using the tool is second nature to them; but that Figma designer is still multi-tasking through the process of selecting objects and placing them and layering them while they try to respond to your ask. As a product manager, you need to do whatever it takes to bring that designer’s focus back to the user’s experience.
Monkeynoodle.Org 