In my previous article, “An Introduction to Designing for Imperfection” I looked at the virtues of inexact design from a philosophical standpoint.
As designers and developers we forget to look up to see where we are in the bigger picture, blocking things out into pixels and comfortable code templates.
I believe that we should embrace errors and complexity. We need to step back and think in broad brushstrokes. How are our detailed decisions impacting the way the whole product works, and the way it will integrate with users’ lives?
I suggested that designers follow four guidelines when taking the nuanced approach I described:
- Assume the Unknown: No matter how many questions you ask or how much research you do, there will be behaviors you cannot predict or understand. This will keep happening. A minor change or a shift in trends will cause use of your system to change.
- Think Systematically: All the data we gather on personas and the concepts we use to develop storyboards are not inputs to the design process, they are the design process. In every phase of the project, explicitly discuss the user, your expectations of their behaviors and needs, and how those are met in every way.
- Use and Make Patterns and Guidelines: Art and science both evolve by building on what has come before. Use existing patterns by understanding how they apply to your work. Create patterns for your product rather than screens.
- Analyze and Focus: Admit you do not know a lot about the pressures, behaviors, and inputs of the user and customer. But don’t just throw your hands in the air and design for those you do know.
For this follow-up article, I’d like to discuss examples of designing for imperfection in action, using the example of a small startup I’m a part of called FoundHub.
Assume the Unknown
My involvement in FoundHub started in my favorite way: the moment the idea was a gleam in the eyes of the other founders, I was invited in. FoundHub is designed to be a local product-finding service, and it was clear that the challenges weren’t so much technical, rather the product needed to be appealing and easy to use.
I started with essentially no understanding of their concept, which was actually great. It reminded me to be explicit about asking questions and defining the audience, business goals, and expected user goals. From this, the whole team was able to understand that key attributes were location and immediacy. This screamed mobile and caused us to focus on mobile compatibility first.
We need to embrace the messiness of systems, our users, and the world outside
Our design could easily have been made absolutely rigid, with us trying to guide the user through the process, and solve every issue. But instead we all agreed that there was great potential for users to use the system in unexpected ways, so we essentially left gaps. Discovery of features and supporting optional entry of information are both key. The datastore allows as much arbitrary data storage and retrieval as is practical.
Think Systematically
When I was first brought on, it was assumed FoundHub would be a traditional website. I think partly because that matched the technical skill and general comfort zone of the others involved with it.
The conversations we had about audience, scope, and goals reopened up the whole project to discussion. Aside from the shift of focus to mobile devices, a goal-driven discussion led to new ideas, like experiments with image uploading, and a network of reminders on multiple channels.
Not all of this has been implemented, but planning for these features has future-proofed the design and allowed for the creation of APIs and databases. Planning for UX-centric features went hand-in-hand with avoiding technical debt. So far this has facilitated clean and quick iterating on the system—adding features instead of reworking them—and ew’re confident it will continue to forge a steady march forward.
Use and Make Patterns and Guidelines
As quickly as we moved on this project, it was critical to create documentation so we could keep track of what decisions had actually been made. In the end, I did mess up a bit on consistency. Moving at high speed it was very easy to make decisions about design with only a few components in mind.
Luckily, as I just said, the other part of this speedy design was iterative development and speedy change. As I became aware of inconsistencies and flaws, I created patterns, style guidelines, and redesigned concepts, so when the time came we were ready to fix everything.
UI and technical consistency go hand in hand, so eventually it became clear that the first designs were also difficult to update and maintain. Right now, we’re in the middle of redesigning the whole presentation layer. Being able to refer to a handful of repeatable patterns for color, type, interaction, and actions, results in many pages being all but automatically designed; there’s only one way the components go together, and it all works out.
Analyze and Focus
My kids routinely do what all children do: they don’t clean their room; they leave the wet bathmat on the floor; they leave the cereal box out. The typical response is “oh, I forgot…” Lately, that’s struck me: their expectations parallel those of most adults. Following the rules is about memorizing, and complying with, a long checklist of appropriate behaviors.
I remind them that I don’t remember anything, either. I have a terrible memory for processes and steps and procedures. So what remember instead is to turn around and look over my shoulder. Just like you look before crossing the street, you should make sure the bathroom looks neat before you leave it after a shower, or that the changes to the website make sense to every user.
As I designed FoundHub (and each time I am sent a revised build) I walk through it like an end user would, trying to make no assumptions based on what I know about the system.
- Does the information architecture make sense? As we added items, the answer, at least once, was “no” and I had to push to change the menu.
- What about errors? Can the user get out of them and complete their tasks? Over time, I have been working on eliminating errors, often with fairly robust changes to the system expectations.
- Throw away the happy path. What if, instead of the home page, users pop into a random page from a Google search or shared link? A nice feature of having many phones to test on is that I can press the Share button every once in a while, and switch to a new handset. It didn’t always work, so we figured out why, and fixed it.
- Are we lying? Does the structure or language obscure the true organization, data, or structure of the system or process? It is very easy to get caught up in jargon, or decide some technical feature is too much for the user and obscure it. For FoundHub, we had some very open conversations about privacy, and decided to not just be non-evil, but to tell everyone about it. I spent a week writing friendly, human-centric terms and conditions—not just for legal purposes but so we were never lying to or deceiving the customers.
Whenever new information, new issues, or a new idea comes along, I try to remember to assume the unknown, think systematically, and to make and use patterns and guidelines.
Executing on the Eternal Backlog
You might work within a larger organization of mostly IT-centric types, but all of your great ideas and processes are of very limited value if you cannot get everyone else on board.
Considering the unknowns means planning for the future, which meshes perfectly with existing processes and methodologies. The backlog of features for future iterations in agile processes inherently deals with the future, and even with uncertainty. Features in the future are only as defined as they need to be, and become more nailed-down as they need to be worked.
As any feature is explored or built, more problems and ideas are often generated, which are simply turned into their own features in the future. Even without external feedback, the inherent uncertainty of design and execution yields an almost inexhaustible supply of work.
For years now I have been using the backlog—or similar lists of features—as a place to store features, expectations, and ideas for the target experience, or the ultimate goal of the product. This target state is not fixed, so defining it past very general goals is hard to do. A shared vision that derives from an ocean of features allows everyone on the team to be prepared for the future, and over time to address them in new iterations and releases or with new product ideas.
Modularity to Avoid Complexity
You might have noticed that implementing the whole design as individual features empowers the principles of component-based modular (or maybe even object oriented) design and development. This is really the only way to attack the vast complexity of systems in an ordered manner.
For FoundHub, the form to post a new find has several thousand basic outcomes depending on user inputs and selections. Defining them all is clearly impractical, so instead each field is defined individually. They are already discrete elements, so this is easy and natural. In development, it speeds time to usable code, as dependencies are cut down. Now, you aren’t building a form, but a field, and as soon as there’s a submit button you can start testing it.
This translates across the process: making another unit test is a really useful part of the developer’s workflow. And the only change is one of conception. Instead of considering features entirely from the business point of view, or to make math easier when assigning features to iterations, you just need to make them smaller and atomic. That’s entirely about analysis and planning and how people work: not processes, methodologies or technologies.
Not incidentally, careful design of modules massively reduces total work, as re-use of these means you tend to have fewer total components to design, or build.
Conclusion
I said that development methodologies like agile tend to account for an eternal cycle of uncertainty, something that’s true for many contemporary processes and methodologies. But practically, it will only happen if the team understands complexity and believes in solving it by designing for imperfection and error.
If you embrace the principles outlined above, your job is not to push new processes on everyone, but to get everyone to let go of old ways of thinking. Remind everyone we cannot force the perfect solution to exist, and can create better, more robust systems and solutions. We need to allow users to play, explore, share, and discover. We need to account for distraction, boredom, and error.
We need to embrace the messiness and complexity of systems, our users, and the world outside the whiteboard and our computers.
This was most inspired by, and borrowed in some quotes and concepts from Gary Anthes’ article Inexact Design: Beyond Fault Tolerance” on probabilistic design of ICs in the April 2013 edition of Communications of the ACM.
Image of hard-boiled egg with two yolks courtesy Shutterstock
