Tags: process

322

sparkline

Wednesday, April 10th, 2019

The Technical Debt Myth

In some cases, it’s entirely valid to explore new products and technologies, but in others, our striving for novelty becomes the driving factor for abandoning perfectly suitable solutions under the umbrella of technical debt.

Just because a technology is a few years old and possibly frustrating in some cases doesn’t mean you’re in technical debt. We need to stop projecting our annoyances as pitfalls of technological or design choices.

Monday, April 8th, 2019

Methods - 18F Methods

A very handy collection of design exercises as used by 18F. There’s a lot of crossover here with the Clearleft toolbox.

A collection of tools to bring human-centered design into your project.

These methods are categorised by:

  1. Discover
  2. Decide
  3. Make
  4. Validate
  5. Fundamentals

Saturday, March 9th, 2019

Performance Budgets That Stick - TimKadlec.com

I like Tim’s definition here:

A performance budget is a clearly defined limit on one or more performance metrics that the team agrees not to exceed, and that is used to guide design and development.

And I agree about the four attributes required for a performance budget to succeed. It must be:

  1. Concrete
  2. Meaningful
  3. Integrated
  4. Enforceable

The point is not to let the performance budget try to stand on its own, somewhere hidden in company documentation collecting dust. You need to be proactive about making the budget become a part of your everyday work.

Thursday, March 7th, 2019

How to Predict the Next Big Thing and Ride the Wave of Innovation - Boagworld Show

Well, that’s a grandiose title for what turns out to be just a chat between myself, Paul, and Marcus. It was good fun.

I’ve huffduffed this.

Wednesday, March 6th, 2019

The “Backendification” of Frontend Development – Hacker Noon

Are many of the modern frontend tools and practices just technical debt in disguise?

Ooh, good question!

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.

Design thinking

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:

  1. Empathise — develop a deep understanding of the challenge
  2. Define — clearly articulate the problem.
  3. Ideate — brainstorm potential solutions.
  4. Prototype — design a protoype to
  5. 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:

  1. Frame a question
  2. Gather inspiration
  3. Generate ideas
  4. Make ideas tangible
  5. Test to learn
  6. 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.

1. Empathise

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.

2: Define

The problem statement should be:

  • Human-centred,
  • 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.

3. Ideate

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.

Oh dear. Jam. Jam. Jam. Jam. Jam. Yes, Una is using the paradox-of-choice jam example …the study who’s findings could not be reproduced.

4. Prototype

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.

5. Test

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

You can use design thinking in your everyday life. Maybe you want to learn JavaScript, or write blog posts, or get more fit. Una used design thinking brainstorming to break down her goals, categorise and organise them.

“Get better at JavaScript” is a goal that Una has every year.

Empathise. In this situation, the user is you. You can still create a persona of yourself. Define. Why do you want to get better at JavaScript? Is it about making better use of your time? Ideate. There are so many different ways to learn. There are books and video courses. Or you could have a project to focus on. Break. It. Down! Create actionable steps and define how you will measure progress. Match the list of things you want to learn with the list of possible side projects. Prototype. Don’t take it literally. Just build something. Test. You’re testing on yourself in this case. Review. Una does an annual review. It’s a nice therapeutic exercise and helps her move forward into the next year with actionable goals.

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?

“Get Fit.”

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, February 26th, 2019

Systems Thinking, Unlocked – Airbnb Design

Some useful lessons here for strengthening a culture of sustained work on a design system.

Creating and maintaining a design system is like planting a tree—it has to be nurtured and cared for to reap the benefits. The seed of our design system has been planted, and now our teams are working together to maintain and grow it. Our new way of working supports gives people recognition, facilitates trust, and creates strong partnerships.

Thursday, February 21st, 2019

Design sprint?

Our hack week at CERN to reproduce the WorldWideWeb browser was five days long. That’s also the length of a design sprint. So …was what we did a design sprint?

I’m going to say no.

On the surface, our project has all the hallmarks of a design sprint. A group of people who don’t normally work together were thrown into an instense week of problem-solving and building, culminating in a tangible testable output. But when you look closer, the journey itself was quite different. A design sprint is typical broken into five phases, each one mapped on to a day of work:

  1. Understand and Map
  2. Demos and Sketch
  3. Decide and Storyboard
  4. Prototype
  5. Test

Gathered at CERN, hunched over laptops.

There was certainly plenty of understanding, sketching, and prototyping involved in our hack week at CERN, but we knew going in what the output would be at the end of the week. That’s not the case with most design sprints: figuring out what you’re going to make is half the work. In our case, we knew what needed to be produced; we just had to figure out how. Our process looked more like this:

  1. Understand and Map
  2. Research and Sketch
  3. Build
  4. Build
  5. Build

Now you could say that it’s a kind of design sprint, but I think there’s value in reserving the term “design sprint” for the specific five-day process. As it is, there’s enough confusion between the term “sprint” in its agile sense and “design sprint”.

Thursday, January 31st, 2019

Openness and Longevity

A really terrific piece from Garrett on the nature of the web:

Markup written almost 30 years ago runs exactly the same today as it did then without a single modification. At the same time, the platform has expanded to accommodate countless enhancements. And you don’t need a degree in computer science to understand or use the vast majority of it. Moreover, a well-constructed web page today would still be accessible on any browser ever made. Much of the newer functionality wouldn’t be supported, but the content would be accessible.

I share his concerns about the maintainability overhead introduced by new tools and frameworks:

I’d argue that for every hour these new technologies have saved me, they’ve cost me another in troubleshooting or upgrading the tool due to a web of invisible dependencies.

194028 – Add limits to the amount of JavaScript that can be loaded by a website

Now this is a feature request I can get behind!

A user must provide permission to enable geolocation, or notifications, or camera access, so why not also require permission for megabytes of JavaScript that will block the main thread?

Without limits, there is no incentive for a JavaScript developer to keep their codebase small and dependencies minimal. It’s easy to add another framework, and that framework adds another framework, and the next thing you know you’re loading tens of megabytes of data just to display a couple hundred kilobytes of content.

I’m serious about this. It’s is an excellent proposal for WebKit, similar to the never-slow mode proposed by Alex for Chromium.

Monday, January 7th, 2019

Angular, Autoprefixer, IE11, and CSS Grid Walk into a Bar… - daverupert.com

Dave on the opaqueness of toolchains:

As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming. When there’s a problem, it’s increasingly difficult to hop into the assembly line and diagnose the issue.

There’s a connection here to one of the biggest issues with what’s currently being labelled “AI”:

In the same way AI needs some design to show its work in how it came to its final answer, I feel that our automated build tools could use some help as well.

I really like this suggestion for making the invisble visible:

I sometimes wonder if Webpack or Gulp or [Insert Your Build Tool Here] could benefit from a Scratch-like interface for buildchains.

Friday, December 7th, 2018

Design process for the messy in-between » cog & sprocket

Designing your design process:

  1. Know your strengths and focus resources on your weaknesses.
  2. Learn to identify the immovable objects.
  3. What has to be perfect now and what can be fixed later?

Monday, December 3rd, 2018

Reluctant Gatekeeping: The Problem With Full Stack | HeydonWorks

The value you want form a CSS expert is their CSS, not their JavaScript, so it’s absurd to make JavaScript a requirement.

Absolutely spot on! And it cuts both ways:

Put CSS in JS and anyone who wishes to write CSS now has to know JavaScript. Not just JavaScript, but —most likely—the specific ‘flavor’ of JavaScript called React. That’s gatekeeping, first of all, but the worst part is the JavaScript aficionado didn’t want CSS on their plate in the first place.

Tuesday, November 27th, 2018

Front-end development is not a problem to be solved | CSS-Tricks

The sentiment is that front-end development is a problem to be solved: “if we just have the right tools and frameworks, then we might never have to write another line of HTML or CSS ever again!” And oh boy what a dream that would be, right?

Well, no, actually. I certainly don’t think that front-end development is a problem at all.

What Robin said.

I reckon HTML and CSS deserve better than to be processed, compiled, and spat out into the browser, whether that’s through some build process, app export, or gigantic framework library of stuff that we half understand. HTML and CSS are two languages that deserve our care and attention to detail. Writing them is a skill.

Saturday, November 10th, 2018

CSS Frameworks Or CSS Grid: What Should I Use For My Project? — Smashing Magazine

Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?

It turns out there are plenty of reasons that people give for using frameworks—whether it’s CSS or JavaScript—but Rachel shares some of my misgivings on this:

In our race to get our site built quickly, our desire to make things as good as possible for ourselves as the designers and developers of the site, do we forget who we are doing this for? Do the decisions made by the framework developer match up with the needs of the users of the site you are building?

Not for the first time, I’m reminded of Rachel’s excellent post from a few years ago: Stop solving problems you don’t yet have.

Sunday, November 4th, 2018

When your design system fails — HeyDesigner

You could create components that strike the perfect balance between reuse and context sensitivity. But defining the components of your design system is just the first step. It has to make its way into the product. If it doesn’t, a design system is like a language with no extant literature or seminal texts.

Marissa Christy outlines the reasons why your design system might struggle:

  1. The redesign isn’t prioritized
  2. The tech stack is changing
  3. Maintenance takes discipline

But she also offers advice for counteracting these forces:

  1. Get buy-in from the whole team
  2. Prioritize a lightweight re-skin on older parts of the product
  3. Treat a design system like any other product project: start small
  4. Don’t wait for others. Lead by example.
  5. Finally, don’t compare yourself to others on the internet

Friday, October 26th, 2018

Service workers and browser extensions

I quite enjoy a good bug hunt. Just yesterday, myself and Cassie were doing some bugfixing together. As always, the first step was to try to reproduce the problem and then isolate it. Which reminds me…

There’ve been a few occasions when I’ve been trying to debug service worker issues. The problem is rarely in reproducing the issue—it’s isolating the cause that can be frustrating. I try changing a bit of code here, and a bit of code there, in an attempt to zero in on the problem, butwith no luck. Before long, I’m tearing my hair out staring at code that appears to have nothing wrong with it.

And that’s when I remember: browser extensions.

I’m currently using Firefox as my browser, and I have extensions installed to stop tracking and surveillance (these technologies are usually referred to as “ad blockers”, but that’s a bit of a misnomer—the issue isn’t with the ads; it’s with the invasive tracking).

If you think about how a service worker does its magic, it’s as if it’s sitting in the browser, waiting to intercept any requests to a particular domain. It’s like the service worker is the first port of call for any requests the browser makes. But then you add a browser extension. The browser extension is also waiting to intercept certain network requests. Now the extension is the first port of call, and the service worker is relegated to be next in line.

This, apparently, can cause issues (presumably depending on how the browser extension has been coded). In some situations, network requests that should work just fine start to fail, executing the catch clauses of fetch statements in your service worker.

So if you’ve been trying to debug a service worker issue, and you can’t seem to figure out what the problem might be, it’s not necessarily an issue with your code, or even an issue with the browser.

From now on when I’m troubleshooting service worker quirks, I’m going to introduce a step zero, before I even start reproducing or isolating the bug. I’m going to ask myself, “Are there any browser extensions installed?”

I realise that sounds as basic as asking “Are you sure the computer is switched on?” but there’s nothing wrong with having a checklist of basic questions to ask before moving on to the more complicated task of debugging.

I’m going to make a checklist. Then I’m going to use it …every time.

Monday, October 8th, 2018

Workplace topology | Clearleft

The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.

This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:

Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

That last part dovetails nicely with Jerlyn’s equally great piece.

Notes on prototyping – Ben Frain

Good tips on prototyping using the very materials that the final product will be built in—HTML, CSS, and JavaScript.

The only thing I would add is that, in my experience, it’s vital that the prototype does not morph into the final product …no matter how tempting it sometimes seems.

Prototypes are made to be discarded (having validated or invalidated an idea). Making a prototype and making something for production require very different mindsets: with prototyping it’s all about speed of creation; with production work, it’s all about quality of execution.

Friday, October 5th, 2018

Designing design systems | Clearleft

I know I’m biased because I work with Jerlyn, but I think this in-depth piece by her is really something! She suveys the design system landscape and proposes some lo-fi governance ideas based around good old-fashioned dialogue.

Developing a design system takes collaboration between the makers of the design systems and the different users of the system. It’s a continual process that doesn’t have to require a huge investment in new departments or massive restructuring.

It can start small.