It takes a village to make a great digital product. Here’s how we do it at Arcweb Technologies.
You’ve all heard the phrase “Software is eating the world,” right? I find that a weird way to look at things, but it’s still an interesting point. Everywhere you look, there’s a new previously dumb device adding software to stay competitive. There’s even a connected egg tray that sits in your fridge now and tells your smartphone when your eggs might go bad. What a time to be alive, right?
But the one thing you’ll notice, is that if software is in fact eating the world, design is leading the way.
You can’t pick up a business mag these days without finding a feature article on design. The richest company in the world right now got there largely because of design. And, I have personally dealt with several large engineering-driven product companies that are working to become more design-driven, because that’s where the market is headed. Huge, well-funded companies are realizing that without design, they’re dead.
Well, I’m a designer by trade, and to me, and all the other designers in the room, I bet that sounds great, right? Right?
Not so fast.
I want to let you all in on a little secret
Don’t tell anyone I told you this, ok? Here it is:
Design is too important to be left to designers.
Design is too important to be left to designers
Ok, now I have the attention of all the designers in the room, because they’re mad. And rightfully so, because it sounds like I just said your job is too much for you. Hold up. What does that mean?
Today’s digital products are just so complex. Really, to land with any sort of traction in the marketplace, you probably have to launch on iOS, on Android, and on the web, for starters. Which means there’s a cloud component. You have to know what’s out there in the market. You need to have someone calling the shots from a product perspective. There’s a lot that goes into what we call user experience design these days… and that’s before we even get to the actual users!
So, really, we’re actually talking about something that’s a little different than what those who attended art school would call “design.”
We, as user experience designers, have to adjust the way we think about out roles. Sure, there’s a lot of “designing” that still has to happen. But today’s UX or product designer spends a lot less time pixel pushing and more time as the steward of the design process.
UX design as stewardship
A UX designer’s role, today and going forward, whether you know it or not, is to create the best possible experience for your users. Full stop. Doesn’t matter where it comes from. Doesn’t matter how you get there, really. You’re not a ninja or rockstar, who comes down from on high and blesses the masses with your talents. You’re a steward, and you’re a part of a team.
So, how do you pivot from being a pixel pusher to a design steward? Here’s how we do it at Arcweb Technologies.
The Arcweb Technologies Design Studio
We do Design Studio. Design Studio isn’t a place; it’s a methodology. It’s not a proprietary thing, or even a new idea. You can start doing this tomorrow if you like. Hey, we’ll be happy to conduct a workshop with your company or startup to show you how (hint hint). So what is it?
Design Studio is a methodology we use to create digital products people love. There are three core ideas behind it:
- It’s collaborative. We get as many people as possible involved as early as possible.
- It’s cross-disciplinary. Design Studio participants are not just designers. I know, right? But that’s the point. To create truly great digital products, we need everyone’s input. That means product managers, engineers, architects, QA folks, product owners, marketing, whoever. Everyone’s got a valid opinion to bring, and we want to collect them all.
- It’s participatory. We don’t only talk about design. We do design in design studio. And how do we do that?
We sketch. Relentlessly. Sketches are the coin of the realm in design studio. Without a sketch, an idea is just words. It’s not concrete. It’s ephemeral. It’s much harder to react to. I can’t circle the part of your voice that isn’t working, or highlight the part that is, right? Plus, sketching isn’t Photoshop. It isn’t Sublime Text. It isn’t Powerpoint. No one’s in their comfort zone, using their preferred tool. We’re all on equal footing.
Before we go much further, I can hear what some of you are thinking…
“But I can’t draw!”
I want to let you in on another little secret: I can’t draw, either. Seriously. It’s really bad. I didn’t go to art school. But I’ll tell you what I sure as hell can do: I can sketch well enough to communicate a design idea, pitch it to someone and get their buy-in. That’s all we’re trying to do here. Sketching isn’t drawing. There’s no aesthetic goal for sketching.
Let me repeat that: Sketching isn’t drawing. Here, look:
These are the kinds of sketches we’re looking for. Juuuuuuust enough detail to convey your idea. That’s a login page, there’s kind of a landing page, and that’s a modal overlay. That took me maybe 20 seconds. That’s all you need.
This is what we mean when we say Design Studio is participatory. Everyone in the room picks up a sharpie and sketches. If you’re not sketching, you’re not in the room. We’re all in this together, people. Besides, if you’ve been invited to our design studio, it’s not necessarily because I like you or want to hang out or whatever, it’s because I need your ideas. So everyone participates. This is non-negotiable.
How to Design Studio
So, how do you “do” design studio? It’s a four step process.
Defining the problem you hope your Design Studio will solve is the first, often overlooked and maybe most important step. Of course, it’s good to know what you’re trying to accomplish with a given design, but it’s great to know this cold up-front, because by defining the problem up front, you have a framework for evaluating a design’s effectiveness later, so you don’t have to resort to “I like it, just because.” (More on feedback in a minute.) It’s also helpful to have your personas in place. These are mini-dossiers about your users, and what they’re trying to accomplish by using your software.
Now, we create. But we do this in a very prescribed, constrained manner. We take grid paper and Sharpies and everyone in the room sketches 6-8 ways to solve the problem for the given persona in 5 minutes.
That’s a lot to unpack, and there’s a reason for each of these constraints.
Why graph paper? Because there’s enough uncertainty and uncomfortableness around this process, that we want to give people some framework to feel comfortable it. Most software is made of straight lines, and the graph paper helps us remember this.
Why Sharpies? Sharpies are fat and indelible. You can’t spend too much time on detail with a sharpie, and you can’t go back and erase.
Why 6-8 sketches? Because that’s a lot, and we want to keep your hand moving, not thinking. We want you to silence your internal critic and help you focus on getting the idea on paper.
Why 5 minutes? Because you can accomplish a lot more than you think in 5 minutes.
So once we’re done the five minute sketch session, we pitch our sketches to each other. Pitching is where the magic happens. Everyone grabs some painters tape and tapes their sketches up onto the wall. Then, you get a minute to pitch. What were you hoping to accomplish with your sketches? Why did you go this route? What assumptions did you make?
Once everyone has pitched, we enter the critiquing stage of design studio. This is where the definition of the problem I discussed earlier become so important. That gives you an agreed-upon framework for discussing ideas. It allows you to say “This works for our target user because… “ rather than “I like this.” Such a simple turn of a phrase, but so powerful. Once we take our feelings out of the equation, it becomes so much easier to give and receive honest, helpful feedback.
After the pitch and critique, everyone gets three glue dots to tag the sketches they think are most effectively solving the problem. They can put all three on one sketch if they really love it. They can tag their own. The only rule is, three dots per person. The sketch with the most dots gives the group direction on where to go next.
Lather, rinse, repeat
So, once you’ve gone through one iteration, you can pick a new feature, define it, sketch it, pitch it, and critique it. Or, you can pick a direction that your team seemed to favor in the first round and dive deeper into it. It’s up to you and your team.
Why Design Studio?
So, now that we’ve discussed what Design Studio is and isn’t, why do we like it so much?
It’s great for requirements gathering: in the Define stage, we can learn everyone’s opinions on what “needs” to be in the product for a 1.0 version.
By seeing where everyone leans in the sketching phase, we can get a real sense of where things fall on the must have/nice to have/someday spectrum.
There is no better way to generate lots of different ideas than a Design Studio. None. This makes Design Studio great for any stage in the product development lifecycle: when you’re starting out on a project, or even when you’re stuck on a particular feature, or any time in between.
One of my favorite outcomes of a good design studio is consensus building. Because you have all the stakeholders in the room, and everyone was a part of the ideation and pitching and critiquing, people feel more involved. They feel like they’ve been heard. Plus, you walk out of a design studio with pre-vetted ideas. Everyone participated in coming up with them. They belong to the group. You don’t have designers saying “I wish I had been invited to an earlier meeting” or engineers saying “There’s no way we can do that” or product owners saying “Why am I seeing this for the first time?”
I’ve seen and anecdotally heard about teams that implement some kind of Design Studio shaving weeks, even months off of a project’s timeline. It eliminates the back-and-forth nature of a lot of product engagements.
But here’s the real kicker. After going through a design studio with a team, you can’t help but respect and empathize with your team more.
A Design Studio can honestly be a bit of a stressful situation. No one’s totally comfortable, and everyone’s on the line to pitch and defend their ideas. That builds a team sometimes. Hearing people explain their ideas and defend them in a controlled environment helps you gain insight into them. Your engineers start to understand that designers don’t just suggest things to make their lives difficult. Designers understand that engineers don’t say no “just because.”
This benefit carries through long after the Design Studio session is complete. And, while we’ve seen better products come out of our sessions, the real deliverable of a good Design Studio is better teams.
I have a homework assignment for you. Take your next feature and run it through a Design Studio. Doesn’t matter how small. You can do it in as little as 90 minutes if that’s all you have, but any time you spend will be well worth it. And if you’d like me to come discuss how to do this in more detail, here’s how to get in touch.
Thank you all so much, and happy sketching!
They might not work for you, though, and that’s okay!
Sketching remains a vital part of the design process here at Arcweb Technologies, and has been incredibly transformative for me, personally:
I can honestly say that buying into a process that includes both sketching and prototyping has exponentially leveled up my game this year.— Len Damico (@lendamico) December 11, 2014
Any old writing instrument and paper can work for sketching. It’s an incredibly open-ended discipline, and that’s part of the beauty of it! But as I’ve sketched more and more, these three simple things have made my the time I spend on it much more productive.
Dots, Not Grids
Graph paper can help make your layouts feel more like precision documents than rough doodles, but not all graph paper is created equal. Some variants have lines so dark that you struggle to see your sketches on it.
The secret: find dotted graph paper rather than lined. The dots allow for some precision and alignment, but don’t compete with your sketches. (I personally love these hard-backed notebooks from Baron Fig, which are available with dotted pages.)
Commit to the Pen
Typically, sketching happens with a pencil. In fact, every designer gets a beautiful Alvin mechanical pencil when they start at Arcweb Technologies. But while pencil has its place, consider giving pen a shot for your next sketch session. In my experience, the fact that pencil sketches are erasable becomes more bug than feature. A pen forces me to always keep moving, not stopping to erase mistakes. Plus, a pen’s indelibility makes for a good reminder to move forward and save all ideas, instead of erasing as you go.
Invest in a Date Stamp
As I look back through my sketching journal, the days often run together. I’ve tried dating pages by hand, but those hand-written dates tended to blend with the actual sketches on the page. The solution, borrowed from Philadelphia artist Mike Jackson, was to invest in a tiny date stamper. The stamps feel official and important but its true value is that it stand out from everything else on the page. Plus, there’s a certain Zen-like quality to the process of stamping today’s date at the top of a blank page.
To Each Their Own
These hacks came from spending lots of time sketching, finding out where my own friction points were, and removing them as simply as I could. They may or may not work for you, and that’s okay! If you’ve got your own sketching tricks, tweet them at me and I’ll share them around. Good luck, and happy sketching!Read on arcweb.co
Good error messaging puts a user back in control when things go wrong. It aligns expectations and calms the user by giving them a sense of context around what happened. Good error messaging is informative and jargon-free. It is not engineer-speak. It empowers the user by either telling them how to fix the problem or what they can expect to happen next.
I’m about halfway through Jony Ive: The Genius Behind Apple’s Greatest Products. So far, it’s a good read. It portrays Ive as someone with exquisite taste who was in the right place at the right time, willing to work harder and care more than his competitors. It never descends into hagiography (in spite of the sub-title), as many tech bios tend to do.
Author Leander Kahney goes to great lengths throughout to express Jony’s distaste for “skinning” a product (applying surface-level design to something engineering had already created). In Ive’s design-centric mind, the “inside-out” method lead to compromised products.
But let’s square that with this tale from the design of the original Mac Mini:
The decision about the size of the case might seem trivial, but it would influence what kind of hard drive the Mini could contain. If the case were large enough, the computer could be given a 3.5-inch drive, commonly used in desktop machines and relatively inexpensive. If Jony chose a small case, it would have to use a much more expensive 2.5-inch laptop drive. </br> </br> Jony and the VPs selected an enclosure that was just 2 mm too small to use a less expensive 3.5-inch drive. “They picked it based on what it looks like, not on the hard drive, which will save money,” [former Apple product design engineer Gautam] Baksi said. He said Jony didn’t even bring up the issue of the hard drive; it wouldn’t have made a difference. “Even if we provided that feedback, it’s rare they would change the original intent,” he said. “They went with a purely aesthetic form of what it should look like and how big it should be.”
This is… well, it’s not design.
Design is solving problems within constraints. The characteristics of components, including price, are constraints. Without having a damn good reason to make the case 2 mm too small to fit a much less expensive 3.5-inch hard drive, you’re just decorating and playing artist, not designer. This is even more surprising, given that Ive is notorious for knowing and waxing rhapsodic about every last detail of his materials.
Outside-in product development is just as problematic as the inside-out approach that Ive despised. In this case, it may have led to a product that was more expensive (or less profitable) than it needed to be. Given that one of the Mac Mini’s core benefits as an entry-level Mac was its low cost, this is baffling.
Great product development is a true partnership between engineering and design.
Yes, I know. Jony Ive is perhaps the most celebrated industrial designer in the history of the field, and rightly so. And Apple has a track record of ignoring practical decisions in the pursuit of a product's true essence. That doesn't mean we can't examine a particular design challenge they faced and learn from it.
Here at Arcweb, we’ve been spending more time using analog methods of exploring and communicating our ideas and we’ve augmented our UI design process with Sketch.app. The next piece of the Arcweb design process that we’ll explore is prototyping.
What is Prototyping?
In our context, prototyping is the process of efficiently creating a representation of a digital product that reflects our current vision of it. Prototypes are meant for learning and communicating, not perfection. They can vary in fidelity from simple, ad-hoc paper prototypes to complex, clickable versions that are almost indistinguishable from real, working software. Efficiency is key here; we create the prototype to learn more about our assumptions and how a piece of software might work before actually building the software.
Prototyping helps us build customer value from the day we begin the Discovery process on a project. More specifically, it facilitates three types of communication that contribute to building the right product for the problem at hand:
- The Designer’s Inner Monologue
- Designer-Developer Collaboration
- Customer Dialogue
The Designer’s Inner Monologue
The closer something is to “real,” the easier it is to evaluate. Consequently, that’s not the case for what’s in a designer’s head. What’s in a designer’s head is, in fact, the furthest thing from “real” there is. But a prototype changes all that. By prototyping, we are able to iterate quickly through ideas that won’t work without sending other departments (like development) on missions built to fail. Said differently, rapid, iterative prototyping allows the design team to fail fast which in turn will bolster confidence because everything’s been considered.
Prototyping also facilitates more effective designer-developer collaboration. With prototypes, the design team is able to show the development team what’s to be built rather than simply telling them. (This is valuable for both practical and interpersonal reasons.) Some prototyping tools even allow developers to pull snippets of code that they can use to get started or in production.
By prototyping, we reduce the frustration and ambiguity that can occur when designer and dev terms don’t make sense to the other. For example, when the design team prototypes, devs don’t have to guess at what a phrase like “the sidebar dances in” means. Instead they see it. (By now it should be abundantly obvious that prototyping minimizes engineer grumpiness.) And when they see it, developers can provide rich, insightful feedback, assess technical feasibility and system design and cut excess scope earlier in the process.
If a picture is worth a thousand words, a prototype is worth a thousand meetings. Prototyping allows us to build consensus with our customers earlier in the life of a project. As much as a customer can say they “get it” from reviewing flat comps, prototypes that look and feel like real software allow for deeper, richer understanding. Throughout the life of a project, that means fewer surprises and the less-than-comfortable conversations you have to have when they spring up.
Finally, customers tend to be more vocal when it comes to raising issues when they’re looking at a prototype versus live software. And this makes sense: no matter if it’s a small modification or a complete pivot, change requests after multiple dev sprints are expensive. They are far less so in the prototyping stage. (Think hours instead of weeks or months.)
So that’s why we prototype. It improves how designers communicate their visions. It aligns designer-developer relationships and workflows. And it helps customers better understand what will be built before it’s built.Read on arcweb.co
Fewer flat comps, more iterative design in the browser. Fewer fixed canvases, more room for elasticity. You ultimately realize that the harder you squeeze and hold on to old workflows, the quicker things slip through your fingers. And yet, an ugly solution that “works” on all devices is no better than a beautiful one that doesn’t.
Here’s what I wrote to introduce the new, responsive essentiacreative.com website, which I led development on. (They’ve since rebranded as Shiny.)