Pragmatic Design Solutions

Limit the Product Scope

A similarly strategic, consulting-level approach to making your limited impact and their small budget pay off is persuading the team to change the scope of the project entirely.

I often get asked to come in and “make an iPad app”—or otherwise find that they’ve already assumed what technology they’ll use. Once I get into the project, I’ll find that there’s no compelling reason for that choice. It may even be a bad idea because, say, very few of their users are on that platform. I love a mobile app, but if you don’t need one for technology capabilities such as hardware integration and the budget is tight, start with a solid Web site that works well on every platform instead.

An organization may be very locked into their thinking, so be careful about asking for such changes, but if the team is open to considering a different platform and you get on it early enough, it can save them a lot of money—even to the level of not hiring developers for the unnecessary platforms. While this savings rarely translates into more budget and time for your UX design work, it might at least cut down your effort. Plus, you have proven your value and your outside-the-box thinking, right away, which sets you up well for having other discussions outside pure UI work.

Find Out What You Really Know

Don’t trust what the team tells you at first. Ask for followups, investigate, and get real data. For starters, always confirm the scope of work, timeframe, and all the details of technology and collaboration with everyone who is involved. I have often found that so-called clean-sheet design projects already have their scope locked in, that we must keep using very limiting legacy technology such as old data stores or bad APIs, or they’ve got only two weeks of development time assigned to implement the UI changes, which is essentially nothing.

When you are revising an existing design or even a launched product, you need know how it works today. If you’re already working on a limited engagement, you probably won’t be able to get usability testing much less fly around the world to do ethnography, but at least start with a heuristic evaluation. Don’t let them just give you a demo or take a look at their training PowerPoint deck. Get a real account and try the actual product.

In general, try to gather your own data. Don’t trust the goals and objectives you see on the kickoff PowerPoint. Instead, find out where those assumptions came from and why. If one executive or a few customer complaints are driving all of them, dig deeper. I have often seen a few complaints lead to changes that angered the many other customers who liked the user interface the way it was. Complainers are always loudest, but not always right.

Even without usability testing, you can learn more by reading other sources of data such as customer-care records, digging into analytics logs, and trying to get the raw data from whatever surveys or focus groups Marketing conducts. Gathering data from multiple sources may be useful and is a good way to tell how valid their results really are.

Watch Out for Third Parties

When you need to ask your product team questions about what technologies they’re using and the scope of the project, ask explicitly what they’re building and what is hosted, what is on a different server that uses a different framework, and what they’re buying off the shelf from a third party. A lot of organizations buy various functions such as their help system from some vendor. The problem is: they are what they are. You can’t usefully integrate such functions, so just link to them and maybe add the company’s logo in the corner.

Think about how to deal with third parties early and at a high level. Say you are working on a registration process inside an app, with a nice step-by-step wizard that shows the user is on Step 1 of 4. But Step 3 is payment-system registration, which a third party provides on a Web site, with minimal opportunities for you to customize their user interface. You can’t just decide that you’ll do your part well, then open a dialog or go to the Web for an unlabeled Step 3, and finally, pop back into your app for Step 4. Doing that would make nonsense of your process, so you’d need to consider everything again from scratch. Similar issues arise with development frameworks and other infrastructure. Companies may purchase them for their amazing capabilities and cost savings, but they can end up being very limiting.

Perhaps the most troublesome issue for the UX designer is that organizations often assume the biggest providers of such services and frameworks are all knowing. Even when you could modify them or use an API to get your own user interface, companies often reject such approaches because they assume the vendor knows best. We, of course, know that success does not equal quality, and the design choices such vendors make are very often demonstrably wrong. Security providers are a good example of this, with many of their user interfaces still in the 1980s, despite the current state of the art, government advisories that say passwords are bad and long passwords are horrible, and the fact that governments have all but banned secret-question systems from use.

There are two tactics you should take when you find out that you are working with limiting frameworks, environments, or third-party services.

• Push for more. Pushing back directly never works because they’ve already made the decision to use these services, but you can often push for more details and greater capabilities. Many of these platforms have tiers of service that offer more options, other templates, or even full UI customization. Often the documentation of these capabilities is poor or hidden, so you need to ask about them.
• Find the limits. Understand what you can and cannot do, and try to stay within these guardrails. Pushing against them won’t usually get you anywhere, and you might get a reputation for “UX wasting time,” which doesn’t help in your future work. To level set again, be sure to remind everyone occasionally why you’re limiting your answers. It’s not your fault that the solution isn’t ideal if your hands are tied.

Do It Right Anyway

While I have done a lot of work in whatever tool the client wanted—for example, I have drawn high-fidelity user interfaces in PowerPoint and Visio—and working within their process, I often agree to a limited engagement, then do more than they asked for or do it differently. For example, just this past week, I did a quick UI design for just a few pages, as a concept for a client review. However, I also sketched some extra pages and added many notes about process and conditionality, making me more confident that the user interface that I drew makes sense for the process. As a result, we’re well prepared for the next stage of work.

Remember that digital systems are arbitrarily complex. Most interactive systems aren’t just a page, but a view into the system. Don’t even try to draw every possible view of every page or let development add many error messages and popups for all the conditions they haven’t addressed, but design for complexity. Specify how everything works, with tables describing component behaviors, instead of drawing dozens of variations. While a lot of teams might initially reject this approach as adding needless overhead, a set of rules for specifications or a table is generally no slower to create and much faster to update, revise, and maintain as complexity grows and new features get added over time.

Make a Style Guide

The biggest design issue that I see resulting from UI-only design methods is consistency. Too many design groups are their own worst enemy and approach each feature and each page individually. To create a single vision of a product design, you need a style guide.

Note that I am saying style guide, not design system. We have two terms because they are two different things. The currently trendy design system bridges design and technology. The UX team builds actual widgets in code, which the development group then uses in implementing the user interface. Ideally, the design system is so well organized and so cleanly named and commented that the code is the guide on how to use it.

But I still say we need style guides, in the old print-media sense. These are documents, wikis, Confluence pages, or whatever that define how everything in the user interface should look and work. The style guide can extend to overall structure and provide details on writing formats as well. The best part is that they are more about look and feel than how to achieve them. This means you can use them across codebases. Rather than just sharing parts between apps and the Web, you can use your app or Web experience across many platforms or even apply it with agreeable third parties and partners.

A style guide keeps your design on track, and as long as it’s a style guide instead of a design system, you can do it yourself without actually getting approval or even telling anyone you’re doing it. Just design a few pages that cover most of the primary design cases, declare them the templates, and create a document in which you can store the templates and all the widgets you make. Again, the minor overhead of creating, storing and maintaining all of this massively and almost immediately pays you back because it makes you much, much faster as you build other parts of a user interface.

Use UI Defaults

Consistency is important, but identifying what must be consistent and with what can be the trick. The style guide can help you maintain consistent structure and a general look and feel across platforms, but you mustn’t take this guide too far. You should use a whole lot of things just as they are for the operating system (OS) or Web browser.

Dialogs, toasts, delay indicators, pickers, and input fields and buttons for form elements are some of the things for which you should always leverage the defaults and, at most, style them a bit to make them work better or mesh with your design. OS defaults are mostly well thought out, bug free, accessible, automatically get improved over time, and behave in ways the user expects.

This principle plays well with the concept of doing most of your UX design work at the architectural level, then letting the user interface be what it is. Or, as someone I worked with long ago called it: Programmer User Interface, or PUI, which is what you get by default, without doing explicit design. With Web frameworks and defaults built into app-development tools, they don’t look that bad. Plus, doing this sets up the product well for customization in a later release—simply and easily.

Don’t Build What You Should Borrow or Steal

Let’s take this even further—to features, not just UI widgets. As an example, a lot of the products I have worked on had a mapping feature, which would take some enormous amount of development effort to complete, be hard to build and buggy so would take more effort to maintain, and would also be pretty hard to design around, in part because maps are two-dimensional scrolling areas.

In many cases, once map features get launched, it turns out creating them was actually a bad thing for users—literally worse than not having the map—and when the team removed and replaced the map with a link to a map app, the satisfaction and star ratings on app stores went up. In many cases, duplicating functions with which users are familiar just annoys and confuses them, reducing their usage rates. So, instead of designing and building such complex features, just link to other apps.

Especially for mobile apps, this is a very simple, effective approach. Just link to the user’s favorite map app for driving directions to your store, to their email program for a feedback form, to the camera app, and so on.

It is important to design these features as options that other apps are clearly providing. For store locations, list each each location fully, then provide a link the user can click to get directions. Integrating the link in such a way that users would be surprised when a new app opens is as bad as for the third-party processes that I discussed earlier.

Conclusion

The user experience matters, not just the user interface. Keep pushing your clients and product teams to make sure they use your skills properly and fully. Let’s reject the trend to become pure UI designers, just taking orders and giving back what they’ve told us to create. Instead, we should do our part to make the product our team is building safer, better, more ethical, and more effective.