Reading, especially fiction, is often referred to as an escape, but I’ve never believed that. It’s true that a great story transports you somewhere else, that returning to your life afterwards can feel like an abrupt reentry. But I think that’s less because you escaped the real world, however briefly, and more that you got a clearer look at it. A great book rearranges time: it brings both history and speculative futures into the present, into a now you can occupy and taste and feel.
Sunday, September 27th, 2020
Friday, August 28th, 2020
Before the hagiographical praise for working with an iPad Pro, Robin nails the fundamental shape of the design process:
I had forgotten that there are two modes of design, just as there is in writing.
The first mode is understanding the problem, getting a ten-thousand foot view of the land. It’s getting people to acknowledge that this really is the problem we need to agree upon. This work needs to happen in a sketchbook in the form of messy, back-of-the-napkin drawings or in writing. All this helps you to form a proper argument and focus your thoughts.
The second mode of design is taking that ten-thousand foot view and zooming all the way in to the hairs on the back of the rabbit; figuring out the precise UI and components, the copywriting, the animations, the everything else. This should be done in a design tool like Figma or Sketch. And this is when we should be talking about color palettes, icons, design systems, and consistency.
The problem with almost all design work is that first phase never really happens. People don’t take that ten thousand foot view of the problem and are focusing instead on the pixels; they’re trapped by the system they know too well.
Yes, yes, yes! Spot on:
I think people get stuck in that second mode because productivity in design is often tied to “how many pages or frames did I design today?” when productivity should instead be thought of as “how did my understanding of the problem change?
The removal of all friction should’t be a goal. Making things easy and making things hard should be a design tool, employed to aid the end user towards their loftiest goals.
Wednesday, February 26th, 2020
This looks like an interesting hypertexty tool.
Friday, February 21st, 2020
- Is this really a problem?
- Does the problem need to be solved?
- Does the problem need to be solved now?
- Does the problem need to be solved by me?
- Is there a simpler problem I can solve instead?
Saturday, September 21st, 2019
There seems to be a tendency to repurpose existing solutions to other people’s problems. I propose that this is the main cause of the design sameness that we encounter on the web (and in apps) today. In our (un)conscious attempts to reduce the effort needed to do our work, we’ve become experts in choosing rather than in thinking.
A very thoughtful piece from Stephen.
When we use existing solutions or patterns, we use a different kind of thinking. Our focus is on finding which pattern will work for us. Too quickly, we turn our attention away from closely examining the problem.
Tuesday, March 5th, 2019
From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
The unstoppable engine of An Event Apart in Seattle rolls onward. The second talk of the second day is from the indominatable Una Kravets. Her talk is called From Ideation to Iteration: Design Thinking for Work and for Life. Here’s the description:
Have you ever had a looming deadline and no idea where to start? Do you have a big task to face but are having trouble figuring out how to get there? Have you ever wanted to learn a technology, or build a side project but didn’t know what to build? In this talk, Una will go over an actionable approach and several techniques for applying design thinking to our work and every aspect of our lives. This includes ideating product features, blog post ideas, or even what general direction we want to move toward in our businesses. We’ll go over traditional approaches and breakout techniques that will leave you feeling more in control and ready to reach your goals.
Let’s see if I can keep up with this…
Una’s going to talk about design thinking. Una does a variety of different work outside her day job—a podcast, dev doodles, etc. Sometimes at work she’s given big, big tasks like “build a design system.” Her reaction is “whut?” How do you even start with a task like that.
Also, we make big goals sometimes. Who makes new year’s resolutions? But what does “get more fit” or “earn more income” even mean?
In this talk, Una will break things down and show how design thinking can be applied to anything.
A stategic, solution-based approach to solving problems.
It’s a process. It’s iterative. It’s used by IBM, Apple, GE, and it’s taught to students at a lot of different universities.
Tim Brown of Ideo points out that there’s a Venn diagram of feasability, desirability, and viability. In the middle is the point of innovation.
The steps are:
- Empathise — develop a deep understanding of the challenge
- Define — clearly articulate the problem.
- Ideate — brainstorm potential solutions.
- Prototype — design a protoype to
- Test — and iterate.
Una feels that the feedback part is potentially missing there. IBM uses a loop diagram to include feedback. Ideo uses these steps:
- Frame a question
- Gather inspiration
- Generate ideas
- Make ideas tangible
- Test to learn
- Share the story
Another way to think about this is how the teams interact. There’s divergence and convergence throughout. Then there’s the double diamond: design, deliver, discover.
Ideo wrote a book called Design Thinking for Libraries. It has some useful tools and diagrams. Una found this fascinating because it wasn’t specifically about products. In healthcare, GE Health used design thinking for their Adventure Series MRI scanners—it resulted in 80% less need to use sedatives. The solution might seem obvious to us in hindsight, but it wouldn’t have been obvious to medical professionals in their everyday busy lives.
Design thinking is bullshit, says Natasha Jen. She describes how it’s become an over-used term that has lost its value. Una can relate—she gets annoyed when there’s too much talking and not enough doing. Design thinking is not diagrams and sticky notes. It’s a process. It’s very much about doing something to shift perspective. It’s another tool in our toolkit, even if it has become an overused term like “synergy.”
Back in 2014, when Una was working at IBM, she thought design thinking was stupid. It seemed to be all talk, talk, talk. It felt tedious. It was 75% talking and 25% development. The balance wasn’t right.
But it’s also true that solutioning too early leads to cruft. If you end up going back to the drawing board, maybe the time could’ve been better spent doing some design thinking up front. Focus on the problem, not the solution.
Now some developers might be thinking that this is outside their area. But it can really help you in your career. It can help you choose technologies. Also, everyone on the team, regardless of role, is responsible for the product.
Understand your users and the challenge. This could be a task that a user is trying to accomplish, or it could be you trying to get a raise.
Sometimes we forget who our user is. The techniques in this first step helps us solve their needs, not our needs.
You might have many users that you’re trying to help, but try focusing in on a few. You can create personas. When Una was working at Digital Ocean, the users were developers. The personas reflected this. Do the research to get to know your users.
Next, you can create an empathy map for your users. What are their goals? What are their hopes? What will they gain from your product?
Connect the empathy map to a specific context—a goal and or a scenario that the user is going through.
Bear in mind that there are many layers to your user. There are conscious rational thoughts, but also subconscious emotional thoughts. Empathy mapping helps you understand how to best communicate with your user.
Una shares a real-life scenario of hers: create a new shop-able product that increases time on site. That’s a pretty big goal. She creates a persona for a college-educated woman working in the medical field who commutes on the subway, keeps a skin-caring routing, and is getting into cake-making. Next, Una creates an empathy map for this persona. What she says, thinks, feels, and does. All of this is within the context of browsing your fashion media website casually at work.
The problem statement should be:
- Specific, but not too technical (don’t solutionise too soon),
- Narrow in scope.
How can we best create a product-highlighting web experience that Rosalyn will enjoy to increase her time on site?
You can use a tool with two columns: As-Is and to-Be. The first column is what users currently do. The second column is what you want to achieve.
This is the fun part. Good old-fashioned brainstorming is good here. Go for quantity here. Get loads of ideas out.
There’s also a “worst possible ideas” game you can play at this stage. It can be a good ice-breaker.
Have a second round of brainstorming where you play the “yes, and…” game to build on the first round.
When Una was working on The Zoe Report, she found that moodboards were really useful. The iteration cycle was very fast. A moodboard allowed them to skip a lot of the back and forth between design and development. They built the website without any visual design mock-ups. They prototyped quickly, tested quickly, and shipped quickly.
Journey-mapping is the next tool you can use in this ideation phase. Map out the steps between the start and end of a user journey. Keep it simple. This is a great time to refine your product and reduce complexity.
Next, start sketching out ideas. Again, this is a great time to uncover issues and solve problems before things get too defined. But remember, when you’re showcasing your ideas in sketches, too many ideas can lead to analyis paralysis.
Go forth and build. A prototype can exist on a number of different axes:
- Representation—the form it takes.
- Precision—the detail it contains.
- Interactivity—the extent a user can interact with it.
- Evolution—the life stage it is at.
There are lot of prototyping tools out there. Prototypr.io helps you find the right tool for you. It breaks things down by fidelity and life cycle.
But not all prototyping has to be digital. Paper prototyping only needs pen, paper, and scissors. Some tips:
- Use a transparency sheet for forms.
- Use well-visible and mid-tip pens.
- Draw up your prototype in black and white—people can get caught up in colour.
But on the web, Una recommends getting to digital as quickly as possible because interaction is such a big part of the experience. That’s why Una likes to prototype in code. But this is still a rapid prototyping phase so don’t get too caught up in the details.
Testing with internal teams is fine during the ideation phase, but to understand how users will relate to your product, you need to test with representative people. We are not our users.
As well as the user, have a facilitator, a computer, and a scriber. As a facilitator, it’s a good idea to reduce the amount of input you give a user. Don’t hand-hold too much or you will give away your pre-existing knowledge. Encourage your user to be verbal.
Sessioncam is a tool for creating a heatmap of where people are interacting. There are also tools for tracking clicks or mouse hovers. These all feel so utterly icky to me.
The metrics you might be looking to gather could be click-through rate, time-on-site, etc. But, Una cautions, be very wary of adding all these third-party scripts to your site and slowing it down. Who’s testing the A/B tests?
On Bustle, Una wanted to measure interactions on mobile. They tested different UI elements for interactions. They ended up updating the product with a horizontal swiping component. They were able to improve the product and ship a more refined experience.
6. Review and iterate
Una feels that this step is the most important. Analyse your successes and failures, and plan to improve.
Technology changes over time so what’s feasible and viable also changes.
Design thinking on the daily
Another goal might be “Write a blog post.”
Empathise. Your users are your potential readers. Who do you have in mind? Make personas. Define. What’s the topic? Ideate. If you don’t know what to write about, brainstorm. What are you working on at work that you’re learning from? Select one to try. Prototype. Write. Test. Maybe show it to co-workers. Review. How did it go? Good? Bad? Refine your process for the next blog post.
Here’s a goal: “Buy a gift for someone.”
Empathise. What does this person like? What have they enjoyed receiving in the past? Define. Is the gift something they’ll enjoy for a long time? Something they can share? Ideate. Bounce ideas off friends and relatives. Prototype. In this case, this means getting the gift. Review. Did they like it?
In this case, the review part is probably the most important part.
Marie Kondo asks “Does this spark joy?” Ask the same question of your goals.
Remember, design thinking is not just about talking, and sticky notes. It’s about getting in the right headspace for your users.
Design thinking matters—because everything we do, we do for people. Having the tools to see through the lens of those people will help you be a more well-rounded person.
Tuesday, April 3rd, 2018
Our insular discourse, the way we’ve jealously protected the language and tools of design, the way we’ve focused so much on the “genius designer”… these behaviors have all worked against our own interests.
Khoi on design thinking and the democratisation of design.
Any embrace of design by non-designers is a good thing, and design thinking qualifies here. The reason for this is that when that happens, it means our language, the vocabulary of design, is broadening to the rest of the world.
Wednesday, March 21st, 2018
Such a great piece of advice from Mark:
Whenever someone asks me to do something that I think seems ill-conceived in some way, I ask them to write it down. That’s it. Because writing is high effort. Making sentences is the easy bit, it’s the thinking I want them to do. By considering their request it slows them down. Maybe 30% of the time or something, they come back and say ‘oh, that thing I asked you to do, I’ve had a think and it’s fine, we don’t need to do it’.
Like Mark, I think I enjoy being on the receiving end of this too:
These days, I welcome being asked to ‘write it down’. It gives me permission to take a breath. To pause and reflect on what I’m asking. I’m convinced my heart rate drops a little. You see, in some environments this would be called ‘process’, or ‘red tape’. ‘Being asked to write something down is a blocker to my flow’. Those kinds of responses miss the mark. When being asked to ‘write something down’ it’s really shorthand for ‘take some time and think about what you’re asking’.
Writing is thinking.
Sunday, January 29th, 2017
A proposed syllabus for critical thinking: Calling Bullshit in the Age of Big Data.
Our aim in this course is to teach you how to think critically about the data and models that constitute evidence in the social and natural sciences.
Sunday, June 12th, 2016
Jon introduces a new tool with a very interesting observation: up until now, all our graphic design tools have been imperative rather than declarative…
With our current tools we’re telling the computer how to design the vision we have in our head (by tapping on our input devices for every element on the screen); in our future tools we will tell our computers what we want to see, and let them figure out how to move elements around to get there.
Friday, December 11th, 2015
Where to start?
A lot of the talks at this year’s Chrome Dev Summit were about progressive web apps. This makes me happy. But I think the focus is perhaps a bit too much on the “app” part on not enough on “progressive”.
What I mean is that there’s an inevitable tendency to focus on technologies—Service Workers, HTTPS, manifest files—and not so much on the approach. That’s understandable. The technologies are concrete, demonstrable things, whereas approaches, mindsets, and processes are far more nebulous in comparison.
Still, I think that the most important facet of building a robust, resilient website is how you approach building it rather than what you build it with.
Many of the progressive app demos use server-side and client-side rendering, which is great …but that aspect tends to get glossed over:
Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering, but this is only one of many options.
I think it’s vital to not think in terms of older browsers “falling back” but to think in terms of newer browsers getting a turbo-boost. That may sound like a nit-picky semantic subtlety, but it’s actually a radical difference in mindset.
Many of the arguments I’ve heard against progressive enhancement—like Tom’s presentation at Responsive Field Day—talk about the burdensome overhead of having to bolt on functionality for older or less-capable browsers (even Jake has done this). But the whole point of progressive enhancement is that you start with the simplest possible functionality for the greatest number of users. If anything gets bolted on, it’s the more advanced functionality for the newer or more capable browsers.
So if your conception of progressive enhancement is that it’s an added extra, I think you really need to turn that thinking around. And that’s hard. It’s hard because you need to rewire some well-engrained pathways.
There is some precedence for this though. It was really, really hard to convince people to stop using tables for layout and starting using CSS instead. That was a tall order—completely change the way you approach building on the web. But eventually we got there.
When Ethan came out with Responsive Web Design, it was an equally difficult pill to swallow, not because of the technologies involved—media queries, percentages, etc.—but because of the change in thinking that was required. But eventually we got there.
These kinds of fundamental changes are inevitably painful …at first. After years of building websites using tables for layout, creating your first CSS-based layout was demoralisingly difficult. But the second time was a bit easier. And the third time, easier still. Until eventually it just became normal.
Likewise with responsive design. After years of building fixed-width websites, trying to build in a fluid, flexible way was frustratingly hard. But the second time wasn’t quite as hard. And the third time …well, eventually it just became normal.
So if you’re used to thinking of the all-singing, all-dancing version of your site as the starting point, it’s going to be really, really hard to instead start by building the most basic, accessible version first and then work up to the all-singing, all-dancing version …at first. But eventually it will just become normal.
For now, though, it’s going to take work.
The recent redesign of Google+ is true case study in building a performant, responsive, progressive site:
This took work. Had they chosen to rely on client-side rendering alone, they could have built something quicker. But I think it was worth laying that solid foundation. And the next time they need to build something this way, it’s going to be less work. Eventually it just becomes normal.
But it all starts with thinking of the server-side rendering as the default. Server-side rendering is not a fallback; client-side rendering is an enhancement.
That’s exactly the kind of mindset that enables Jack Franklin to build robust, resilient websites:
I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. Server-side rendering was the default; client-side rendering was added later.
The key to building modern, resilient, progressive sites doesn’t lie in browser technologies or frameworks; it lies in how we think about the task at hand; how we approach building from the ground up rather than the top down. Changing the way we fundamentally think about building for the web is inevitably going to be challenging …at first. But it will also be immensely rewarding.
Wednesday, August 12th, 2015
The web – by its very nature – foregrounds the connections between different clusters of knowledge. Links link. One article leads to another. As you make the journey from destination to destination, all inevitably connected by that trail of links, you begin to tease out understanding.
It’s this drawing together, this weaving together of knowledge, that is the important part. Your journey is unique. The chances of another pursuing the same path, link by link (or book by book), is – statistically – impossible. Your journey leads you to discovery and, through reflection, comprehension. You see the connections others haven’t, because your journey is your own.
Wednesday, December 31st, 2014
Yet another brilliant far-ranging talk from Bret Victor.
I’ve tried to get him to come and speak at dConstruct for the past few years, but alas, with no success.
Saturday, April 12th, 2014
This is a wonderful piece of writing and thinking from Frank. A wonderful piece of design, then.
A personal view on generalists and trans-media design
Wednesday, July 1st, 2009
The latest project from Jonathan Harris is a not-for-profit educational organization dedicated to the study of contemporary culture: "We fulfill this mission by documenting, archiving, and disseminating ideas that are shaping modern thought by interviewing leading thinkers in the arts, sciences and technology from around the world."
Sunday, February 22nd, 2009
An even more speculative version of The Long Bet. Given a supposition (e.g. "What will the world be like when custom satellites are as easy to design and launch as your own website is today?"), you can add to a list of positive and negative outcomes.
Thursday, December 8th, 2005
A list of articles discussing the impact of a reliance on PowerPoint® and bullet-point based communication.