Designing in the Age of Impermanence
A product having a place in our hearts as something to be ogled at and enjoyed for what it is simply because it was designed and then actually made physical, is getting rare as far as media goes. The process for which materials like ink and paper stock choices are crucial, and the arduous burden of measuring everything, is all encompassing in a designers life; it is (as it has been repeatedly described to me) a “labor of love”. When an idea gets implemented through an applied design in just the right way, form ascends to communication and art. You can feel it resonating between the designer and the beholder over and over again. It’s frickin’ magical, but it takes planning.
As a developer and designer, I craft with digital things - things that can easily be moved around, mashed up, and mixed in. Things that can be inherited from, and built on top of. Things that are not precious, when done right. Things that (and this is important) interact but don’t usually impact on that same tangible level.
That’s not to say these digital things couldn’t attain the same level of wonderment, but from a client / agency perspective, there is a real tendency to think that “Eh, it’s ok… we can just change it later to meet our needs” without really thinking about it at all from the start. Just belt that layout or code block out and ship it. Do it live, so to speak.
So, when faced with a task of designing for a thing that does a thing, I tend to start with the bare essentials: a notepad and a pen. With these real tools, you learn to work out the things’ story and journey, construct workflows for the things’ users, evaluate functionality that will bolster the thing as a viable thing among other things like it. You eventually bust out a wireframe tool and draw what you believe should be the elements of the thing that does a thing, with solid research to back that layout up.
One issue with this process, however, is that many clients and agencies haven’t had enough experience building a thing that does a thing to learn to value the steps necessary to prepare for making the thing that does a thing.
And really, what does a client know about making a thing? They’d make it themselves if they could, but can’t so they look to someone else to just get them to the end result as fast as possible. This usually equates to a request for a fully realized design to know what the thing looks like. Parallel to that request, most endeavors lack real explanation of what the thing does, so when they can’t envision functionality by description alone, clients will ask for a pictorial rendering of each and every function, just as you would a proof before a print run.
This, my friends, is the downhill slide into a terrible habit I like to call Permanence Mentality, and it breaks my heart. To lock yourself into one look and not prepare for the future is an easy way to rack up a hefty bill from non-progressive iterations, haggle over myopic changes with people who are guessing your needs, and generally come away from the project feeling like it was a waste of time.
I’ll say this right now: I consider the agencies’ team responsible for making the thing that does the thing the real root to permanence mentality.
The agency flow that creates this is roughly as follows:
- An initial discovery meeting starts that gets the client pumped
- Eventually the client asks for next steps
- The agency or team promise to show design soon
- The agency skips every bit of meaningful discovery that should be done ahead of time and forges ahead into the unknown wilderness of the project.
Yep, this is still happening. And in many agencies or teams, this is one of the fastest way to get a client genuinely excited about the thing they want (and possibly get a first cut of the accounts payable). No questions in between, no understanding of the user base outside a few known facts parroted by the client (which can be wrong), and certainly no measured approach to build up an inventory of working content or user goals. It’s all gloss from here on out, with a lot of pain and suffering through out the process.
This is like trying to craft a watch from really expensive materials without knowing how it works, or who’s going to buy it.
Once this path is chosen, you can then feel the ethos (particularly mid-project) where the client “just isn’t cooperating” or “isn’t getting it” and your team has done “like thirty-seven versions of the same button rollover” or “rebuilt that search box eight times because they wanted [xyz] feature they saw on [abc] site”. Your team feels like the project is a loss, and really starts to question why the thing is being built in the first place. Eventually everyone on the team ends up conceding on every decision, saying “welp it’s there product, just design it and send it out” — usually accompanied by a very short email to the client saying “here”.
Killing the cycle
So how do we stop this cycle of massively over-representing a things purpose through it’s looks and start pinning down it’s true functions? Well, let’s negate the top reasons why we skip ahead:
- We don’t have time to do real discovery. Yes you do. Discovery should be billed as one of the thickest parts of the project — which will save you from having to chop design and development time from the budget. If you think you can just wing it, you will certainly be using the time you thought you didn’t have making functional patches for a half baked product, or redesigning small disparate bits of the product without a cohesive brand to back up your decisions.
- Design is what clients want to see to sign off on development. This one’s tough, but the design is the last step in a thing’s visual development lifecycle. This means two things: your team should be dividing your development and design efforts into parallel tracks (no amount of design should harshly dictate what development efforts do), and the design you produce should be informed by many assets created along that way that manages you clients expectations. More on that in a bit.
- We are an agile / slim / anorexic team, we don’t need all this preparatory firepower. Maybe you don’t, but your client does. The steps you take to educate your client means they will convert from a force to battle with to a true zealot that is fiercely loyal to the decisions you helped them make. Trust me, they will be happier when you hold their hand and will be more confident in the process when they come back to build another thing that does a thing.
Do It Better By Doing It In Steps.
There is no right way to tackle the lifecycle of a thing being made in the digital era, but there are a few basic assets we can create to prepare in its discovery phase that can really help make an impactful thing among other things… all while forging better business practices and better business relationships. When you take the time to address any or all of the following with the client (aside from your normal creative brief and tech doc processes), you will end up getting more valuable information from them before you touch one line of code or draw one bezier curve.
For the Visual Development Lifecycle, consider the following:
- The Association Game — Get you client’s stakeholders together. Present a deck of blank white cards to each one. Then ask questions like “If you product was a car, what car would it be?”. Make columns and have them stick their answers up on a wall for everyone else to see. Discuss. You will find that each person has a different opinion about the product you or they didn’t expect. Why did Scott over there choose a red Ferarri, but Annie chose a silver Volvo? Maybe Scott wants the product to be viewed as responsive and robust, but Annie is concerned about the trustworthiness and security of the product. Figure it out now so everyone has the same expectations going forward.
- Moodboards — These are aiming to not only whet the client’s palette a little bit, but also serve as a way to choose a look really early on while getting the designers juices flowing. I would aim to provide just two looks, since providing more options only makes your client’s choices harder. Your team should guard against the Frankenstein request by distinguishing the looks enough that they can’t mix them. I also provide a code name to each look with a short description of the looks’ intent (eg: “Metro”: Bright, clean, cheerful, minimal) so as to be memorable and referential.
- Photoboards — These act like mood boards, but are specifically made for photos only. Photography, especially faces, are one of the most subjective pieces of creative to get right, so spend a lot of time putting together sets of photos that would work, and then have a discussion about them. If you don’t know the client’s feelings on two dudes standing next to each other or a particular cityscape, you will have a harder time backing your choices out when they get incorporated into a full
- Wireframes — Forget the color scheme and photography. Get a UX/UI team together and think about the product from a purley structural standpoint. This doesn’t include just a deck of sketches, though; this involves interview sessions with the clients about specific business needs and how they want to approach them. What competitor does a search box really well and why? Does it work for your product? Let’s try this structure to see how intuitive that is. Wireframes are the ideas of layout and interaction patterns, not just gray boxes that can be presented and moved around. When you think about it from this perspective you save your design and development teams a lot of time and energy guessing what something should structurally look like and act like.
- Style Prototypes — Let the developers and designers craft small pieces of the site’s look in real code as experiments. This way you can easily run client interviews to see whether a particular feature could work like you wanted or not. This isn’t completely necessary for products using out-of-the-box paradigms, but if you run a larger shop having your team build small lego-like components gives them a toolbox to work with later and a reference to how things work without ever building a huge product.
For the Business Development Lifecycle, consider the following:
- User Personas — How many user types does the product have? What are their goals? What do they care about the most? Being able to interview the client and come up with several personas to design and build against is an excellent way to ask down the road if a feature is worth it based on user benefit. This will also help the client identify their audiences better, which then helps to serve as a reminder for your team that it’s not the client your building for, it’s the personas.
- User Stories — At the heart of it, these are basically questions about what a user can do, answered in a concrete sentence with three important pieces of information. For example: “An admin user can edit a blog post in order to maintain or update the product’s content.” answers what type of user is being affected, what user function is being defined, and why it it is needed. By asking the client these questions, you gain a targeted perspective on what is important to a products’ user base, and if you can’t answer all three parts, you and the client can have a discussion about whether it really is needed in the first place.
- Priority Guides — What exactly does the client want to achieve? Honestly drill down into the heart of what the product is about and make that the central focus for the project. Especially across devices, many features of a product need to be ranked into more or less important buckets so that the business goals can be effectively met. Does that CTA really need to show up in the middle of your mobile device? Does the cool slide-out menu really need to be available on a 30" retina display? How important is logging in versus reading content? How can users most easily purchase what they want?
- Content Models — These guys are short descriptions of each piece of differentiated content in the product. What does a video entail? Just a title or does it have descriptions, related links, and shareable assets? How about a profile? Mapping out what content has what attributes prepare teams from not just a technical stand point, but also informs the creative team to expect a certain set of attributes and think about cases where those content models are fully loaded or sparsely represented. This is easiest to do with a tech lead, a creative lead, and a client stakeholder who is knowledgable about the product(s) being represented. Avoid drawing in top level stakeholders unless they really understand the importance of focusing on the user’s needs (this will lead to less social crap bolted on to a content model).
What have we learned? No really, what have we learned? You can’t hit the mark 100% of the time with your clients by leaning into design and expecting it to figure your project out. It takes time to craft something wondrous, and it takes as much planning in the digital arena as it does in the real world. Plan, create a set of tools to work with, and listen to everything and everyone along the way.
And, if you are feeling like your team is ill-representing a product’s development by not giving it enough discovery time or feels like its taking forever, just start talking to the client and ask questions. You will certainly gain insights you didn’t have before, and with the right tools generated from those answers you will be more prepared to design and develop the thing that does the thing in an impactful way.