The Secret History of the Apple Watch

Great article about the perspectives and thoughts about the Apple Watch evolution. I am a design nerd so I always love reading articles that have the actual teams and people involved in the process. I think deeply about the projects that I work on if you are working in the Technology field and building out products as I am this one is worth a read.

Inspiration is the feeling you should get after watching this video. Apple always has a special way of inspiring me to want to push the limits in what I do on a daily basis. They continue to prove why the products they make have a purpose in our daily lives. The simple message that other companies just cannot seem to deliver.

Over the past three years, iPad has helped people transform business, education, entertainment, health, and many other fields. We wanted to document those changes. During three weeks in September and October of 2013, we traveled the world to see how people are using iPad. Here are some of the examples we found. Source

Resource: Good Kickoff Meetings

http://goodkickoffmeetings.com/

Resources from my SXSW 2011 presentation, Your Meetings Suck and It’s Your Fault.

These resources are identical if you attended my workshop at UX London, UX Week, or UI16.

If you work at a design agency, government agency, university, for-profit, not for-profit, or even a wish-I-had-profit, you break your work down into projects. Every project has to start somewhere. Traditionally we call those first meetings “kickoff meetings.”

The metaphor of a football kickoff for a meeting implies a time in the project where the game is just beginning, but that implied simplicity is deceptive. The reality of a kickoff in football is that a lot of analysis and preparation happened off of the field before the ball is kicked. Unfortunately that amount of thought and effort doesn’t traditionally go into project kickoffs.

I decided to undertake a different approach to kickoff meetings, applying design thinking, constraints, and interactive exercises to develop a kickoff framework that was more similar to a playbook of activities I could pull from to begin to define and begin to solve problems for clients. I am in the business of creating experiences for the web, and although these exercises are designed to support that type of process, you might find them useful in putting together kickoffs for other kinds of projects as well.

Whether you get one useful idea from this site, or it helps you plan a multi-day, 60 plus person kickoff meeting, I hope you find this site helpful in building trust, energy, and positive culture around a successful project beginning.

Two that stuck out to me:

Design Studio/Prototyping Exercise
http://goodkickoffmeetings.com/2010/04/design-studioprototyping-exercise/

The 20 Second “Gut” Test
http://goodkickoffmeetings.com/2010/04/the-20-second-gut-test/

A responsive process. Brad Frost for TechCrunch

I got shot out of a cannon at the beginning of 2013. I had been contemplatinggoing out on my own for a while, so I decided to reach out to the great Josh Clark for career advice. In addition to providing me a ton of great advice, he asked if I’d be interested in working on a potential project that was in the midst of coming together. Of course my answer was yes, and for the next few months began working on a redesign of TechCrunch.

The Team

I had the honor of working alongside some of the smartest and nicest people I’ve ever met on this project (and thankfully most of us ended up working onEntertainment Weekly right afterwards). Here was our crew:

• Josh Clark steered the ship. He got the team together, led the design process, constantly managed the client relationship, and gave off positive vibes that carried us through a lot of long nights.
• Jennifer Brook is an absolute beast. Never before have I seen someone conquer content and information architecture so adeptly.
• Dan Mall led visual design on the project. Dan constantly amazed me at how thoughtful, utilitarian, and gorgeous his designs were. It was an honor to work with him.
• Jonathan Stark slung some serious JavaScript. It was my first time working with a bonafide JS expert, so I did my best to learn all I could from him. He also helped me with my abysmal Git/Github skills, and for that I’m eternally thankful.
• Kristina Frantz brought to the table some serious project management chops, which were essential in managing our entirely remote team.
• And as for me, I coded the HTML and CSS for the site. As it turns out, there was a lot to create, so thankfully Pon Kattera and Greg Sarault stepped in and helped me prototype a ton of stuff. I most certainly couldn’t have done it without them!

We all worked remotely, and since the majority of the team were also frequent speakers we found ourselves collaborating on this project while criss-crossing the globe. Our calls would start with “Greetings from Stockholm!” “Greetings from Chicago!” “Greetings from Sydney!” It was pretty wild, but hey, we got the job done.

The Process

Our merry group of makers had the opportunity to revisit what the modern Web design process looks like, and this post is going to step through how we did things.

Set expectations

A lot of the failure to move into the Post-PSD Era has been a problem ofsetting the right expectations with clients and colleagues at the beginning of the project.

We did our best to help the client understand the reality of the Web landscape, and that because our website was going to be fluid, our process needed to match.

We helped everyone understand that development is an essential part of the design process. A few months before starting the TechCrunch project, I was deep in my thoughts working out what would ultimately become atomic design. I had even begun work on a tool that would allow me to establish a robust pattern library and stitch together interface patterns to form pages. That tool would eventually evolve into Pattern Lab. I introduced everyone to atomic design and demoed Pattern Lab for them. We talked about the benefits of creating a robust design system versus an ad hoc collection of page templates. Everyone seemed to get it without any wailing or gnashing of teeth.

Kickoff and Planning

We kicked the project off at TechCrunch’s office, where we conducted stakeholder interviews, did a 20-second gut test, and design studio exercises to get everybody aligned. You can read more about the exercises because we repeated these effective exercises for Entertainment Weekly, and I used them for my current redesign of the Pittsburgh Food Bank website.

Sketching

Armed with insights from the kickoff meeting, we retreated back to New York to comb through the site, establish content types, talk information architecture and brainstorm interaction design together. After that Jennifer rolled up her sleeves and got to work organizing the mountains of Post-its and sketches the group had generated.

establishing site-wide patterns

Jennifer did a hell of a job setting up some global patterns for the sites, establishing what she referred to as “rivers” and “islands”. Rivers are lists of objects like news stories, while islands were featured content areas.

The great thing about establishing these site-wide patterns was that I was able to immediately represent these patterns as organisms in Pattern Lab. Because of the blocky, gray-scale nature of Jennifer’s sketches, I was able to quickly recreate all the sketches in HTML using a simple .fpo class. Once established, creating and modifying wireframes was as easy as copying and pasting an include.

In addition to translating Jennifer’s sketches into FPO blocks in Pattern Lab, I was able to get to work right away on a whole slew of molecules and organisms. Just by looking at TechCrunch’s existing site I knew I could roll up my sleeves and start marking up a whole host of things: text elements (bold, emphasis, blockquote, pullquote, etc), image types (logo, post image, avatar, etc), forms (search, newsletter, submit a story, contact, etc), ads, and a whole lot more.

We knew that ads throw in a monkey wrench into a responsive sites, so I created FPO ad unit atoms and chucked all the ad requirements into the HTML wireframes right out of the gate.

establishing visual direction

While Jennifer was working on information architecture and I was setting up molecules and organisms in Pattern Lab, Dan was hard at work establishing visual direction.

Because TechCrunch is a destination for people to read, Dan thought a logical place to start exploring would be type. So using Typecast, he created some type combinations to facilitate conversation with the client.

The client was able to comment on type (“That’s too blocky” or “Number 3 is a little too thin”) by looking at real type displayed in the browser, the same place where their users will ultimately be experiencing the site.

Rolling Up Our Sleeves

Once we had a solid sense of information architecture, visual direction, and HTML scaffolding, we were able to really get into the weeds to start designing things.

html wireframes

Jennifer blocked out all of the different page templates, accounting for variants of a template (such as how the homepage looks during a live event versus a normal news day).

And I was right there behind her creating each page template, which consisted of the appropriate molecules and organisms. Slowly but surely, I started replacing those FPO divs with marked-up molecules and organisms.

Now, these HTML wireframes looked absolutely hideous. But that’s alright because at this stage in the game I was just getting everything wired up. Layout, color, and other visual design-related stuff would come later.

element collages

Armed with insights from type and branding explorations, Dan went to work creating element collages of the interface. Element collages are a bit more tangible than a style tile, but still not a full-on comp. Here’s one that demonstrated how things might adapt across multiple screen sizes:

The great thing about this is that he didn’t have to worry about what the footer or featured post area was going to look like in order to get the client’s feedback. By honing in on one organism rather than a whole page, the client was able to focus on getting the header right rather than getting distracted by what FPO image Dan might have decided to use on a homepage comp. Element collages allowed us to have the right conversations at the right time.

Once the client was comfortable with the header direction, I would take that direction and start styling it up. I started with the global header and footer:

Now this is where things start getting weird, because what began their lives as HTML wireframes were slowly transforming into the final designs. I thought this would be awkward from a client relations standpoint (we certainly had a lot of internal conversations about how to address this), but ultimately because they were involved in the process the entire way they understood what was going on. Because they had a better perspective on where the design was coming from, we were able to get feedback on certain components despite the fact that the rest of the site guts still looked like grayscale throw-up.

comps

Believe it or not, we did indeed create a few full comps. Gasp! Horror!

But the difference between this and all the other projects I’ve ever worked on is that we didn’t lead with the comps. By the time Dan made some comps (for the homepage and featured article page), we had established many of our key molecules and organisms, and had an understanding of the systematic nature of our design.

We presented the comps to the client, and they’d come back with some (usually) minor change requests. I’d then take the comps and their feedback and make the requested changes in the browser, so that we weren’t dwelling in Photoshop any more than we had to. Dan and I would Skype and chat through the issues to ensure the initial vision remained intact.

behind the scenes photoshop

And so it went. We’d create visual styles for particular organisms, and design full comps if absolutely necessary. I would style each organism appropriately, and slowly but surely replace the remaining grayscale blocks with detailed styles.

Sometimes things just weren’t looking right in the browser. Maybe a few components didn’t not look quite right sitting next to each other. In these instances, I’d bring them to Dan’s attention, who would screenshot the working code and shift things around to solve the design problem. We’d talk about it and I’d get back to work implementing his suggestion.

After a while, we realized that a whole lot of the Photoshop documents being created weren’t ever intended for the client to see. Instead, these little Photoshop hotfixes were created to help me style things better in the browser. Strange days indeed.

The Final Push

We worked hard styling each of the templates, and addressing every variation in a template. What does an article look like when there’s zero comments? What about when there’s 60? What does a topic page look like for a product versus a company versus a person? What does an event page look like before, during, and after an event? We created a new page for each template variation. Here’s what the final page list looked like in the Pattern Lab menu:

That’s a lot of pages.

Once the templates were complete, we cross-browser, cross-device tested everything (we had been testing on different browsers and devices throughout, but only on a subset during core development). From the design end of things, Dan went through and created an incredibly detailed list of minor design tweaks that tightened things up and got things ready for final delivery to be implemented into their WordPress backend by the fine folks at10up (who by the way were involved throughout the course of this process). What was great is that we weren’t just handing over a bunch of templates, but rather an intentional, robust design system that can be built upon and evolved.

After some time the site went live. It was a long few months, but I think our hard work paid off.

Lessons Learned

So that’s that. Here’s some things I took away from the project:

• It’s not Agile–So we didn’t do the traditional waterfall approach. So we must have been Agile right? I don’t really think so. I think there’s a false dichotomy between waterfall and Agile, but at the end of the day I don’t know what I’d call our process. All I know is that we communicated a lot, collaborated like I’ve never collaborated before (keep in mind that we were all remote throughout the entire process), and we were honest with ourselves and the client.
• Work in parallel–There’s so much work that can be done in parallel.

  

  From day one, information architects and content strategists can begin organizing information, visual designers can start exploring type, color, and texture, and developers can set up tools, patterns, and components. As some point in the process, a discipline might serve more as consultant for the other disciplines, while other times they’re burning hot creating things. As time goes on, the creating/consulting role shifts, but no one is ever fully out of the picture.

• Slowly build fidelity–This process reminds me a lot of subtractive sculpture.

  

  You start out with a big slab of rock, and slowly chip away to get the rough shape of the form you’re creating. You take another pass at it to get a better sense of the object you’re trying to extract from the stone. You take another pass to start getting a bit more detailed. Eventually, you start honing in on a particular aspect of the form: a face, the arms, or the torso. Slowly but surely you detail each section of the sculpture until you’ve arrived at the final form.

  Only unlike stone sculpture, we have Cmd+Z.

There’s a lot more to be said about this project, and hopefully I’ll get the opportunity to explore them further. In the meantime, check out the site, and look out for more posts from the rest of the team.

The Iceberg of Jobs-to-be-Done

When you’re starting to design a new product, or redesigning an existing one, the most important thing you can do is validate that the problem you are trying to solve is meaningful, important, and shared by a large enough group of people that a solution is likely to succeed in the market.

However, there are two significant challenges to overcome. First, it is difficult to find the right tools to truly understand these complex problems. Second, we have a strong human desire to conceive a highly-rationalized approach to deal with our insecurity in the face of many unknowns and perceived risks – especially when the stakes are high. These two forces often work against each other and lead to bad solutions that don’t solve real problems.

So where can we look for insights to guide us? It’s tempting to look at consumer market research segmented by demographics, psychographics, or technographics for data points that confirm or refute our hunches. There’s plenty of this out there, and it has been gathered and analyzed by smart people working at reputable companies.

It’s also tempting to look at competitors in a market and try to reverse-engineer their success, or classify them on some spectrum of qualities that help us identify arbitrary attributes that could differentiate us (“We’re like the Tumblr for the knitting community!”).

In the case of an existing product, you could also look at your analytics and hope the data will point you in the direction of the next big thing you should do. Finally, it’s easy to come up with a list of ideas, features, and requests from existing or prospective customers (see: The Homer) that seem worthy of building.

This type of data can make us feel more confident about our decisions and steer us down a path toward building a solution that is clearer in our minds. But how do you make sense of it all and ensure you’re laser-focused on solving the underlying problems people have in their lives instead of just the thing that came to mind today? And how might we identify unmet needs (non-consumption or hacks) from this data? We can’t.

The problem is that this data is almost always a lagging indicator of behaviour. Even when we aggregate it all together and look for trends, we are reporting something that has already happened, but that doesn’t mean we understand why it happened. Yet the why is the single most important thing to identify in product design. “Why does this exist?” “Why might someone actually change their behaviour and use this?”

The Iceberg

It is said that 90% of an iceberg is underwater. I believe the same analogy applies to the insights we use to focus our creative energy when designing a product. It’s easy to find the lagging indicators – the 10% that is above water – but much harder to find the leading indicators of potential customer behaviour. And focusing only on lagging indicators is a dangerous blindness to have when you’re trying to find product-market fit and persuade people to switch to your product.

At Teehan+Lax, we believe that single most important thing you can identify when creating a product is the jobs-to-be-done that your existing or potential customers have in their lives. Jobs-to-be-done are what cause a customer to hire or fire a product. Finding a poorly-served job that many people critically share is the most important factor in identifying new opportunities and building disruptive solutions. These are the leading indicators of customer behaviour that help you stay focused on building the things that matter and ignoring the things that don’t.

This would suggest that most successful products are created by one of four types of people:

1. Geniuses who have a strong internalized sense of important jobs-to-be-done. These people are few-and-far between. They are the Steve Jobs of the world. Through an incredibly prescient vision, drive, and experience, these individuals are wired to identify and build things that solve important jobs-to-be-done.
2. People who have identified a problem they have, and decide to create a better solution first-and-foremost for themselves. By focusing on their own problems, they remain focused on what matters and have an easier time identifying other people who might share this problem and hire their solution.
3. People who create a product and, somewhat by chance, stumble upon a compelling job-to-be-done that propels them to success. This is dangerous – especially with complex digital products. It becomes easy to misunderstand the reasons people have hired you and to blindly push your product in a direction that actually moves away from solving the most important jobs-to-be-done. Over time, these products can begin to poorly serve the market, leaving the door open to competitive threats.
4. People who understand the importance of creating products that solve real customer problems, and have a set of tools and frameworks like jobs-to-be-done that they use to identify and validate the real human problems they’re trying to solve in the market.

At Teehan+Lax, we push ourselves and our clients to be in the fourth category. The third category is too hit-and-miss (although you can get there more reliably by building stuff quickly and validating in market), and the first and second categories are too rare.

How We Do This

The idea behind jobs-to-be-done is relatively straightforward. We’re all trying to make some kind of progress in our lives with regards to problems or jobs that we have, and we hire various solutions to solve them for us. We continue to use a solution so long as it continues to adequately address the jobs we have (whether we’re conscious of it or not).

But identifying these jobs is the tricky part. Here’s a simplified form of the methodology we use:

1. Find people who have recently hired or fired a relevant product.
2. Interview them to investigate what forces and factors have led to this event. Don’t spend any time talking about what they like or didn’t like about the product, what features they want to see in the future, etc. These are traps.
3. Analyze these forces and factors to pull out and prioritize the jobs-to-be-done.

This process looks more like detective work than conventional marketing research — in large part because most of us have low self-awareness of why we ‘hire’ things. We have found it greatly outperformsconventional research approaches because it avoids the trap of looking for esoteric or abstract ‘insights,’ and instead focuses relentlessly on answering very plain questions that get to the crux of why we do what we do.

At this point, you should have a set of jobs-to-be-done that, if employed correctly, will serve as a lens through which most product decision-making can exist. If an idea or feature doesn’t clearly resolve the job in some way, it doesn’t deserve to exist or should be de-prioritized.

We believe these are the most important leading indicators, because the day you stop adequately serving these jobs, or a competitor serves them better, is the day you start losing customers.

Designing Facebook Home. On May 8th, the designers behind Facebook Home (Justin Stahl, Francis Luu, Joey Flynn and Mac Tyler) presented a behind-the-scenes look at their work at the Bluxome Street Winery for a small crowd. Source

“The creative process is just that: a process. Recognizing value that others have missed doesn’t require preternatural clairvoyance. A well-honed creative process enables us to intuitively recognize patterns and use those insights to make inductive predictions about divergent ideas, both vertically within categories, and horizontally across categories. By understanding the genealogy of innovation within a given category, we can imagine what might come next.”

—

Source

Rubber Duck [UX] Debugging

The basic premis is that you debug your code by explaining it to a rubber duck, line by line, and hopefully realise where the bug lies in the process.

If you’re going to be spending $75 per person on user testing, then you’ll want to make sure you’ve spotted as many “buggy” interactions as possible before anything gets built.

As this is intended to be a practical guide, I’ve created a fictional mobile app to use as an example (so just squint and pretend it’s your own app).

Step 1: Define your flows with User Stories

Be clear about what your app does. For my example app, I wrote:

{name of app} is a point of sale app for iPhone that enables waiters to take a drink and food order at the table and charge customers directly.

Then, you’ll need to have at least one user story like:

As a waiter, I want to take an order of 3 green teas, 1 water and 1 sandwich so that I can charge the customer.

These user stories define the flows through the app that we’re going to be testing. If you want more information on storytelling in design, check out Braden Kowitz’s post.

Step 2: Wireframe your flows

I’d normally start this process in Omnigraffle. Maybe you prefer pen and paper or some other app like Sketch. (If you use something else, leave a comment about it here).

Taking the order of 3 green teas, I work out all the pages I’ll need to complete the transaction. I also loosely work out how they will connect to each other i.e. what order the appear in (the flow).

This gives me a todo list of pages I need to create wireframes for.

You could (and probably should) use this fidelity of wireframe to start testing, but I’m going straight for the final, eye candy version with a “here’s one I made earlier” approach.

Step 3: Prepare your fake screens

So I know which screens I’ll need and I know what data goes on each screen. Next I’ll take those wireframes and start the glossy design with shape, contrast, spacing and type (far left) before moving on to applying brand and colour. I use Silkscreen for previewing on devices as I go. Final design:

For each page, I’ll use Photoshop Layer Comps to show variations e.g. a receipt page and the same page with a “paying” popup over the top.

Step 4: Fake it ‘til you make it

Next up you’ll need Keynote and Liveview (for mac and ios).

This is the Rubber Duck Debugging part. It’s important to note that it’s not the final output that’s important here, it’s the building of fake app that will highlight interaction bugs as you go.

So let’s build that fake green tea order:

1. In Keynote, create a new presentation.
2. Open the Inspector.
3. Resize your presentation to match your phone. 640x1136 for iPhone 5 for example.

Now you’re ready to cut/paste from Photoshop to Keynote. Switching through your Layer Comps, follow the user stories and flow you defined earlier to get a list of sequential slides in your presentation.

You’ll end up with something like this. To test my “3 green teas” order, I ended up with about 15 slides. Some were almost identical with just a different total price showing so it’s not as much work as you think.

Most of the time your fake app will be linear flow. If you want to double-back through the app (re-visiting the start page for example) you can do this by using a transparent shape enabled as a hyperlink to another slide:

At this point, if you play the slideshow, you should be able to click through the app and fake taking a real order.

Congratulations! You just rubber duck debugged your flow.Hopefully by forcing yourself to mimic a real flow, you will have spotted some early UX problems. The kind of stuff you want to find before a developer spends a week putting a basic feature together.

Step 5: Take the red pill (optional)

As nice as it is to have a flow running on your screen, wouldn’t it be even nicer to actually test it on a device? As I work remotely I also film using the app to share with stakeholders so that they can view the functionality first hand.

You’ll need to modify Keynote preferences and “Allow Exposé, Dashboard and others to use screen”. This will enable you to move the LiveView capture area.

Launch LiveView both on your mac and your iPhone, set it to “High Quality” and Interactive:

Your Keynote should now be being broadcast live to your phone and it should feel as though you’re actually using the app (bonus points if you used Keynote animations to make it more iPhone-y).

As I mentioned, I also film using the app to send to my team so they can comment on functionality. My setup looks something like this:

Unfortunately, I don’t seem to be able to embed video, but you can visit this Vimeo page to see the kind of results you should expect.

---

To give you an idea of the kinds of bugs you might find using this method, here’s what I found when making the above point of sale app. I noticed a problem where every time I selected an item, say a tea, a coffee or sandwich I aways went back to the top level menu (rather than staying on the drinks menu for example). This is logical because you can’t infur what the next item would be.

However, this gets annoying if you want to select 3 coffees. I only noticed this when I went to add 3 green teas in a row. Once I found this UX bug, it was easy to fix, but I wouldn’t have thought this problem until much later on in the dev cycle, rather than at this early design stage.

Source