I think these are great habit-forming ideas for any web designer or developer: a day without using your mouse; a day with your display set to grayscale; a day spent using a different web browser; a day with your internet connection throttled. I’m going to try these!
Sunday, November 17th, 2019
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.
Thursday, April 5th, 2018
This is absolutely brilliant!
Forgive my excitement, but this transcript of Charlie’s talk is so, so good—an equal mix of history and practical advice. Once you’ve read it, share it. I want everyone to have the pleasure of reading this inspiring piece!
It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.
Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.
Just how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.
Saturday, February 10th, 2018
Maybe being able to speak a foreign language is more fun than using a translation software.
Whenever we are about to substitute a laborious activity such as learning a language, cooking a meal, or tending to plants with a — deceptively — simple solution, we might always ask ourselves: Should the technology grow — or the person using it?
See, this is what I’m talking about—seamlessness is not, in my opinion, a desirable goal for its own sake. Every augmentation is also an amputation.
Some questions for us to ask ourselves as we design and build:
- Empowerment: Who’s having the fun?
- Resilience: Does it make us more vulnerable?
- Empathy: What is the impact of simplification on others?
Monday, July 17th, 2017
A series of small suggestions that anyone can try so that they can better empathise with people who experience digital products differently.
These prompts are intended to help build empathy, not describe any one person’s experience. These prompts are not intended to tokenize the experience of the individuals experiencing these conditions.
Tuesday, August 2nd, 2016
Over the years I’ve come to realize that most difficult part of making websites isn’t the code, it’s the “hidden expectations”, the unseen aspects I didn’t know were my responsibility when I started: Accessibility, Security, Performance, and Empathy.
Thursday, May 26th, 2016
A heartfelt call to web developers to consider the needs of the many and varied people trying to use what we build.
It is about making products that serve all users equally. It is about putting ourselves in others’ shoes. It is about trying to imagine the frustration and difficulty of using our products when the conditions aren’t what we’re used to. It is about being human.
Tuesday, August 13th, 2013
Trent proposes a way to avoid implementing dark patterns: take a leaf from the progressive enhancement playbook and assume the worst conditions for your user’s context.
Thursday, August 8th, 2013
Empathy is for everyone:
No matter how many times I go through this journey, it never stops surprising me how easy it is to lose perspective in the heat of a project and forget that there is no difference between a user, a client and a designer. It shouldn’t be so hard to remember that no matter the title, we’re all just people trying to get things done.
A nice reminder from Viv.
Friday, October 19th, 2012
CAPTHCAs are a terrible, terrible solution to a technological problem. But at least these CAPTCHAs acknowledge that the person typing is not only not-a-bot, but a human being.
Saturday, February 13th, 2010
Before we point the finger and laugh at the Facebook users leaving confused comments on Read Write Web, we should look to our own experiences with Google Buzz.
Wednesday, March 25th, 2009
An excellent rumination on the meaning of accessibility, prompted by real world experiences.
Saturday, April 28th, 2007
Now this is what I call a captcha. You want to know about my mother? I'll tell you about my mother.