This week’s sponsor: Proposify

Source: A List Apart

Save time writing and designing your next proposal with help from our sponsor, Proposify.

Read the full article


Rachel Andrew on the Business of Web Dev: Creating Process to Free up Time for Creativity

Source: A List Apart

In The E-Myth Revisited, Michael Gerber encourages entrepreneurs to develop business systems, going as far as to suggest we should build our businesses as if we intended to create franchise operations. This idea of process and systems is a popular one—taken to an extreme by people such as Tim Ferris in The Four Hour Workweek. This complete systemization of business activities is rightly pushed back against by many people working in creative fields. The act of creating something new can’t be written out as a series of steps. The individual creator, the artist, is important. That role can’t be just anyone who is able to follow the instructions.

On a recent Startups for the Rest of Us podcast, the discussion was about people versus process. This suggested that you can either value people and their creativity, or you can develop a very process-driven business, where you can slot in any person to step through the tasks. I think there is a middle ground. Documenting procedures for tasks that benefit from a structured approach can leave more flexibility when tackling creative work.

What do we mean by process?

When we turn a task into a process or system, we identify all of the steps we go through to perform that task and make that a checklist. My process for reconciling transactions in Xero is:

  1. Look at the incoming bank transaction.
  2. Find the receipt or invoice for this transaction.
  3. Add the details from the receipt into Xero.
  4. Check that, if tax has been applied, I have entered the correct rate, and that it is detailed on the receipt.
  5. Upload a PDF version of the receipt to Xero and also store it in Dropbox named with a reference for the account name it came out of.
  6. Mark the transaction as reconciled.

This is not creative work, it’s a rote task. Following this practice around bank reconciliations has benefits:

  • I know that any reconciled transaction will have an associated invoice or receipt. If I need to produce that proof, I know where they are stored, as the process prevents mistakes caused by me forgetting what to do here.
  • It removes friction. I don’t need to expend any energy remembering what to do.
  • It makes it easy for me to outsource this task. If I’m bringing on board a new bookkeeper, I can explain this process and be able to see that it is being followed.

By creating a process, I can get this task out of my head. Reconciling accounts isn’t my favorite job, but when I need to do it I can grab a coffee and step through each item on the checklist without spending any time thinking through it. I add these boring but important tasks to a special Context in OmniFocus that contains tasks to work through on those days where I’m having a hard job focusing for some reason.

This is a fairly simple example, but the same method can be applied to more complex tasks in your business. For example, which steps need to be followed when you take on a project with a brand new client? You might include:

  • Creating a file (from a template) for their basic information, such as who to invoice, agreed terms and so on.
  • Sending them a contract to sign.
  • Saving the signed contract.
  • Sending an initial invoice.
  • Ensuring that payment terms have been agreed.
  • Setting them up on a collaboration tool, such as Basecamp or Slack.
  • Safely storing any login details you need for their hosting.

Again, this is not creative work. How you go about it might differ from client to client. You might go through this list in person with one client and via email with another. Either way, the checklist ensures that you have agreed payment terms. It ensures you have a contract, and that you have received any assets they need to provide you up front (which could well save you time when you need something and the client is out of the office).

Checklists and process can also help make jobs you find difficult far easier. Perhaps you dislike talking about money with new clients. Sending that email containing the estimate for a job can become an all-day procrastination affair! The checklist can take your mind off the potential result of the interaction and help you focus on performing the steps to get to that point.

Leaving your brain free for creativity

The power of process is that it can free up time and energy to do things that can never be reduced to a checklist. To-do lists stop your brain endlessly having to remember what you need to do today, and process documentation can work in the same way. You no longer need to remember what must happen to complete a certain task. Though often seen as a way to outsource parts of your business, putting process in place can also benefit the one- or two-person business.

If you do go on to expand your business, having good processes can make it far easier to bring in permanent or temporary help. Those tried and tested checklists can be given to someone who can perform the rote tasks, leaving you to do the more interesting creative work.

Most importantly, by not expending effort on the mundane you can leave more time free for the work you love to do—the work that can only be done by you. You can then feel free to put aside all thoughts of checklists and to-do lists and work in exactly the way you know enables your best accomplishments.

Read the full article


Building to Learn

Source: A List Apart

I’ve spent my fair share of the last 10 years in the web world learning new things. We all have; it’s the one constant in this industry: things will change and you will need to change with them.

And for people just starting out on the web, building and learning is pretty much continual. This summer, as a friend learns to build things on the web for the first time, I’ve thought more about how I learned, how I got started in this webbish world in which I find myself day in and day out.

If you’re just getting started on the web the biggest piece of advice I have for you is: build something that interests you. That may not sound that radical, but it’s truly one of the best ways I’ve found to learn something new, whether that’s here on the web or elsewhere in life. Many online code courses have you building something they’ve chosen, but if you don’t care about building their to-do list or whatever, you aren’t going to be as excited about the project. If you aren’t excited about it, you aren’t going to learn as much.

When I was first learning HTML, CSS, and ColdFusion (yes, I learned ColdFusion as my first dynamic language to interact with a database), I made a small site about art. I went back to school to learn about the web because it was more marketable than the art degree I got in college, but art was something I was still very interested in and familiar with—plus, I had resources sitting around in my personal library for data and information. I remembered a small book on artwork through history I had on my shelf and used it as the basis for a small site. It was perfect because it gave me the database fields easily (such as the title, artist, date, and genre). The structure of the book made some of those decisions for me, so I could focus on the code. It was thrilling when I was done, when I could click around a site and pull up various art works. It wasn’t perfect, but I learned a lot about how to pull information from a database that’s still relevant in my work today.

In addition to creating something that’s interesting to you, many folks suggest making something you would actually use in your day-to-day life. One thing I’ve seen is a meal planning application that someone made for themself and was able to use with their partner regularly. Maybe you’re interested in history and want to link publicly available photos to places in your city. What you make isn’t as important as the fact that you’re excited to make it. You want the finished product, so hopefully you’ll persevere through the tough parts.

Of course, having to do something is also a great motivator for learning how to get it done. When I was on a project and we had to get a password meter working with JavaScript, a colleague coached me through it and I learned. When I was passed a new design to lay out and it seemed like flexbox would be a great solution, I learned flexbox as I got the site working in the browser.

I’ve found when I start doing an online tutorial, if I’m not interested in what they’re having me build, I don’t learn as much. It’s not that I don’t understand what’s going on, but the concepts don’t stick with me. When I need to figure something out on the job or I’m building something that I want to use in my own life, though, I learn so much more. And when I need to use those same coding concepts that I learned to make that password meter in JavaScript, they come back to me more easily.

I’ve already written about how learning new things in our industry can be overwhelming with all the options out there and all the change that is constantly happening. But when you slow down and focus on something you find useful or something you need to know how to do, you flip the equation. Instead of trying to get through a tutorial or lesson, you’re making something you want, which keeps you motivated as you figure out how to get there. When you need to remember those concepts down the road, it’s so much easier to retrace how you built a project you’re excited about and proud of instead of a cookie-cutter tutorial you can’t quite remember.

Read the full article


The Language of Modular Design

Source: A List Apart

As many of us move away from designing pages toward designing systems, one concept keeps cropping up: modularity. We often hear about the benefits of a modular approach; modules are scalable, replaceable, reusable, easy to test, quick to put together—“They’re just like LEGO!”

Modularity might appear to be a simple concept at first, but making it work for your team demands significant effort and commitment.

The biggest challenges around modularity are all the decisions that need to be reached: when to reuse a module and when to design a new one, how to make modules distinct enough, how to combine them, how to avoid duplications with the modules other designers and teams create, and so on. When modularizing an existing design or building a new one, it’s not always clear where to begin.

Start with language

Language is fundamental to collaboration. In her book How to Make Sense of Any Mess, Abby Covert says that the biggest obstacle teams face is the lack of a shared language. To help establish that shared language, she suggests that we discuss, vet, and document our ontological decisions in the form of “controlled vocabularies.”

In short, we should start with language, not interfaces.

For about a year now, our team at FutureLearn, an open education platform, has been experimenting with a modular approach. I’d like to share a few ways we have tried to hone a shared language to help our team transition into modular design.

Build a pattern library as a team

One of our first experiments with modularity was an attempt to redesign our homepage. A visual designer created modular slices, and we then held a workshop where we tried to organize the modules into comps. That’s what we thought (perhaps naively) a “modular design process” would look like.

Photograph of the team at FutureLearn organizing modules into comps.

One of our first experiments with modularity.

We ended up with three designs that eventually became fully functioning prototypes. But even though it was a useful exercise, the result we came up with wasn’t truly modular:

  • Modules weren’t clearly defined.
  • They didn’t have clear functions; the differences between them were often merely aesthetic.
  • We didn’t standardize and name them.
  • We didn’t put a lot of thought into how they would be reused.

Ultimately, we decided not to use the resulting designs. These experiments were useful in propelling us into a modular mindset, but the defining step toward thinking modularly was going through the process of building a pattern library as a team, which took several months (and is still in progress).

The atomic design methodology pioneered by Brad Frost served as our foundation. This is when we started looking closely at the UI, taking the interface apart, conducting inventories, and defining the core elements and patterns that we used to build new pages.

Once we had a library, we were better prepared to think about design in terms of distinct reusable components. Until then—even after all of our experiments—we were still thinking in pages.

Name things collaboratively, based on their high-level function

Once you lay the foundation, it’s important to build on it by evolving the language as a team. An important part of that is naming the things you create.

Imagine you have a simple component whose function is to persuade people to take a specific online course. What would you call it?

Screenshot of a module promoting an online course in cyber security.

UI component promoting an online course on FutureLearn.

The name depends on the component’s function and how and where it appears in the interface. Some people, for example, might call it “image header” or “course promo.”

James Britton, a well-known British educator, explains in Language and Learning that by conferring names on objects, we engage in a “process of bringing [them] into existence,” just like children who use language to “call into existence, to draw out of nothingness,” the world around them. Similarly, if an object in the interface doesn’t have a name—a name that makes sense to your team, and is known and used by people on your team—then it doesn’t exist as a concrete, actionable module to work with.

Once you name an object, you shape its future. For example, if you give it a presentational name, its future will be limited, because it will be confined by its style. A functional name might work better. But functional names require more thought and are harder to arrive at, because function can be relative. For example, we almost called the component above “course poster” because it had an image of the course in the background and its function was to promote the course. It wasn’t a bad name (it was quite functional, in fact), but it was also limiting.

Around the same time, for another project, a different designer introduced a component that looked (apart from minor variations in layout and typography) quite similar to our “course poster.”

Screenshot of a module inviting learners to take part in a discussion on brain activity.

UI component inviting learners to take part in a discussion.

The function of the new component was to invite people to take part in a discussion. So the first thought that came to mind was to call it “discussion.” No one made a connection with “course poster” at first, because its name limited it to one specific function—promoting courses—and the function of “discussion” had little to do with it.

If we had given those components the names we initially thought of (“course poster” and “discussion”), we would have ended up with two named modules that were almost identical but non-reusable. Such oversights can lead to duplications and inconsistencies—which undermine modularity.

Although their functions may appear different at first, if you look at multiple uses of these components in context, or even imagine potential use cases, it’s easier to see that they both do analogous things: they serve as attention-seeking slices. They command the core calls to action on those pages. In other words: their high-level function is to focus users’ attention on the most important action.

Screenshots of multiple billboard components in use.

A billboard component in use.

In the end, we created a single component called a “billboard.” Billboards are not restricted by their position on the page, or by their content, or by their appearance. They can appear either with an image as the background or as part of the content. What matters is the high-level function, and that this high-level function is understood in the same way by different people on the team.

Screenshot of a billboard component with an image of a hamburger inserted between the headline and the call to action.

Example of a billboard component with an image as part of the content.

In the process of naming an element, you work out the function as a group and reach an agreement. It’s not so much about giving something a great name (although, of course, that’s an ideal to aspire to), but agreeing on the name. That determines how the element will be used and helps to ensure that it’s used consistently by everyone.

Make design language part of everyday culture

Naming things this way may take longer, at least initially, because it doesn’t yet feel habitual. It requires additional effort and commitment from the whole team to make the process more familiar.

One way to make conversations about language happen is to create a physical space for them in the office.

A photograph of two walls papered in printouts of modules and naming discussions.

A space in our office where language conversations often take place.

High-level functions are easier to define if you have the whole UI printed out and intelligible at a glance. It’s also a lot easier to spot any duplications and inconsistencies that way.

Slack or other chat clients are also a viable way  to have these discussions. For example, it can help to post new elements you’ve just introduced, or existing ones that you suspect are inconsistent or potential duplicates, and then try to work out their function and find a suitable name. When thinking of names, it helps to have a common point of reference; our team often borrows terms from other industries, such as publishing or architecture, to give us ideas.

Screenshot from a Slack discussion about potential names, such as 'bracket' or 'triglyph,' for a module with three content chunks.

A typical naming discussion on Slack.

Keeping design language alive by making it part of our day-to-day conversations, whether in-person or remote, plays a key role in maintaining modularity within our team.

Define CSS architecture at the design stage

Needless to say, reaching consensus can be difficult. For example, we may disagree on whether we should reuse an existing module, customize it for a specific context, or create a new component.

Several articles have been written about styling UI components based on context. But Harry Roberts has suggested that “having to change the cosmetics of a component in a certain context is a Design Smell”—a sign that your design is failing. How do you prevent this from happening?

What helps us is trying to standardize elements at the design stage, before building them—in other words, starting with design language. This means that developers need to understand why things are designed in a certain way, and designers need to know how the modules are built so that they can make tweaks without having to create a different version of the module.

Before writing the CSS, it’s useful for designers and developers to understand the purpose of every element they create. They might start by asking lots of questions: “Will this module always be full width? Why? Will it always include those buttons? Is the typography likely to change? Is the image background critical to the design? Are the horizontal rules part of the molecule?”

Answering these questions helps to ensure that components follow through on design intent. For example, you might choose to specify some styles at the atomic level, instead of at the organism level, to make it easier to change those properties without changing the module itself.

Involve users in the design process

Another critical aspect in establishing a shared understanding is involving people from different disciplines, as well as users, in the design process from the outset. When brainstorming and sketching together, we can’t help but talk about the design elements, so we inevitably make ontological decisions that help to strengthen and evolve the design language.

Getting to the testing stage early is important, even if modules are presented as simple paper cards. Testing with ideas on cards is very different from our usual process, where we have a list of tasks and scenarios that we walk users through. Here, participants can pick up, move around, discuss, and scribble on the cards, actively becoming part of the design process. This gives us a chance to test our language choices and make sure that the functions we’ve defined make sense to our users.

Three photographs of users reacting to large paper printouts of modules.

User testing and participatory design with learners.


A well-established language foundation is a powerful tool that allows teams to synthesize their efforts around implementing modular design. But the way a shared design language evolves is a piecemeal, gradual, and organic process. Every person on the team plays a role in making it more coherent. Going through the process of building a pattern library as a team is an effective way to establish a language foundation. Using a solid methodology, like atomic design, can speed up the process.

Naming things together is a useful habit for your team to develop, because in the process of trying to give something a name that makes sense, you work out its function and, most importantly, reach consensus. The agreed-upon name determines how the element will be built and encourages consistent usage across the team. As Abby Coverts writes, “If you don’t get agreement up front, prepare for more work later.”

Make an effort to refer to the elements by the name you agreed on—no matter how strange this might sound in everyday conversations. It takes more effort initially to call something a “whisper box” (yes, we have an element called “whisper box”) rather than “that thing with the lines and an icon in the middle.” But until you start referring to an element by its proper name, it doesn’t exist in your modular system as a solid, actionable block. Every time you use the name you agreed on, you strengthen the element you call on and evolve your design language.

Put your language to the test outside of your team by using it throughout the company, with other teams, and with users. It’s always interesting to see what sticks—it’s a real kick when someone outside the product team starts using the name, too.

Finally, remember that no language (aside from a few exceptions) exists in isolation. By evolving and strengthening your design language, you have an opportunity to contribute to the larger language of the web, and to help make it more consistent and coherent for everyone.

Read the full article


Sharing Our Work: Testing and Feedback in Design

Source: A List Apart

When I was a younger, less experienced designer, I was uncomfortable showing work that wasn’t “done.” I thought that design was something I should show only in its glorious, final state.

Many designers and design processes suffer from the same isolation problem: we don’t show our work to our users until the very end—when they’re stuck with it. We treat research as a box to check off, rather than an asset to use as a design evolves. We rely on personal opinions to make decisions instead of validating them with the people using the product.

However, the more we share our work in progress, using a variety of testing methods at every stage of design, the more input we can get from the people the design is for. Multiple research methods ensure that we receive diverse feedback; and more diverse feedback helps our products better meet our users’ needs.

Learning to share

When I first came to Etsy, I was surprised to learn how much their design process focuses on iteration and testing. Designers show Etsy’s buyers and sellers early versions of new designs to get direct feedback.

This doesn’t just happen once, either—research is integrated throughout the entire design process, from small conceptual tests to working prototypes to fully functioning features. At each point in the design process, we ask specific questions to help us move forward to the next phase of work.

To answer these questions, we use different research and testing methods, tailored to the type of feedback we’re looking for. Each type of research has strengths and weaknesses. If we limited ourselves to one type of research, like usability testing, we wouldn’t catch everything. Gaps in the feedback would leave us to build something that didn’t totally align with what our users need.

Here is how we use research at Etsy at each point in the design process to solicit different types of feedback (and the surprises we encounter along the way!).


At the beginning of a project, we define what we’re going to build. To formulate a project goal, we start by looking at high-level business goals, research from past user testing, and data on current Etsy usage. The direction we pick in this phase dictates what the next few months of work will look like, so user validation is particularly important here.

To help choose our path, we create low-fidelity mockups and do concept testing with Etsy users who fit the target audience for the project. Rather than invest a lot of engineering time up front on building something we might not use, we often test clickable prototypes, which, while clunky, are cheap to create and involve zero engineering time. They’re mockups of an unbuilt interface, which also means we’re able to throw in blue sky features. Focusing on the best-case scenario of the feature lets us test whether sellers grasp the concept—realism and constraints can come later.

My team at Etsy, Shop Management, recently tested concepts for a promotional tool for sellers. We had a rough idea of what we wanted to build, but it was important to see if sellers understood the feature and its benefits before we went too far. We recruited sellers to remotely walk through our prototype, asking them:

  • “What’s the purpose of this screen?”
  • “Tell me about what you just did there.”
  • “What’s the value of this tool?”
  • “How would you use a tool like this for your shop?”
  • “How would you describe this tool to a friend?”

Even though the format of these sessions is similar to how usability testing is conducted, we’re not focused on usability feedback at this early stage; we’re more concerned with solidifying a direction. There might be gaping holes or implausible scenarios; in one version of our clickable prototype, I forgot to account for the iOS keyboard! But mixing up details like that is okay when the questions we’re asking are broad. Instead of focusing on the interface, we’re asking participants about the idea. Validating our direction as early as possible sets us up for success down the road.


Once the concept has been validated, we dive into designing the new feature. Design constraints come into play, and we’re now tasked with solving some of the details that we punted on in earlier conceptual versions. As more constraints are applied and we get deeper into uncovering the specifics of what we’re creating, the research becomes more focused on the interface itself. This is where usability testing becomes our best friend.

Last year, the Shop Management team redesigned the core of Etsy’s seller tools, the Listings Manager. The redesign was much needed; the interface was showing its age, and so was the technology behind it. Many useful new features had been added to the Listings Manager over the years, but they were added as their own pages instead of being integrated into existing workflows. Nothing was optimized for mobile, despite increased traffic to Etsy from mobile devices. We needed to rearchitect the Listings Manager with sellers’ workflows and technology best practices in mind.

Redesigning such an integral part of a seller’s toolset was going to be tricky, though. Sellers are very sensitive to change because these tools are what they use every single day to run their businesses. So we conducted usability testing every two weeks to make sure our design decisions matched the way sellers wanted to work. And we used task-oriented questions during these sessions, like asking sellers to:

  • perform an action that existed in the old design, like editing a listing
  • find a familiar feature, like “quick edit,” in a new location
  • go through a common flow, like finding a listing that had expired and renewing it
  • use new design paradigms, like a gear dropdown for performing actions

We tried a few clever ways of redesigning the Listings Manager interface; for example, we added a sidebar for editing listings, so sellers wouldn’t have to go to an entirely new page. But the sidebar totally bombed—it required way too much scrolling and wasn’t as useful as we anticipated. It was painful for us to watch sellers struggle to use our prototype. Thanks to usability testing, we immediately ditched the sidebar and moved on to a more practical interface.


After weeks of iteration, we have a solidified design that works end to end. The product has bugs and missing features, needs a lot of polish, and is months away from launch—but this is when we want Etsy users to start kicking the tires and using it as a part of their normal workflows.

Usability testing is great for feedback on specific tasks and first impressions, but because it’s a simulated environment, it can’t provide the answer to every question. We might still be trying to validate whether we successfully hit the original goals we set for our project, and for that we need the feedback of people who use the product regularly.

To catch these types of issues and to vet new features on Etsy, we created beta tester groups to opt-in specific buyers and sellers to early versions of our features. We call these “prototype groups,” and each one has a forum in which members can post feedback and talk to one another and to our product teams. The scale of prototype groups can range anywhere from a few dozen people to thousands; our largest prototype group to date has been 10,000 Etsy users. Having so many people use a pre-release version of a feature means that we’re able to catch edge cases, weird bugs, and gnarly user experience issues that bubble up before we release it to everyone.

When we released the Listings Manager redesign to a prototype group, we wondered things like:

  • If we repeatedly got feedback on something in usability testing, were we able to successfully fix it, or was it still an issue?
  • Is it faster to edit listings in the new Listings Manager? If not, what are the biggest points of friction?
  • What tasks are sellers trying to perform when they switch back to use the old version of the Listings Manager? Why did they switch?

We added some new image editing tools for sellers’ listing images, but noticed that the tool icons were crowding the images interface. Our solution for this was to roll the actions up into a small dropdown. When we put these updates through usability testing, nothing noteworthy came out about the new interface, so we moved forward with it.

After sellers in the prototype group started using it, however, we saw consistent negative comments in the forums about the new dropdown. To create a new listing, sellers tend to copy an existing listing as a template, then edit attributes such as the photos and title. In the old design, editing photos was a straightforward flow, but the new dropdown added in two clicks, more reading, and extra mouse movement. We had created more friction for sellers adding new listings.

The prototype group allowed us to catch issues like this because sellers were putting our product through realistic scenarios. We spent the next six months fixing problems that came directly out of the prototype group. Having a direct line of communication with our beta-testing sellers helped us find patterns, identify problems, and vet solutions before our full release.


When a feature is fully functional and any design kinks we’ve uncovered have been smoothed over, we’ll often release it as an experiment: we’ll direct a portion of traffic to a different version of a page or a flow, then compare metrics like conversion or bounces. What people say anecdotally doesn’t always line up with what they actually do; data helps us understand how people are actually using a new interface.

Etsy’s seller onboarding process is a great place to run experiments because new sellers don’t know how onboarding will work. We’re also able to analyze the long-term impact that onboarding has on a shop’s success. For example, our team noticed that it was taking sellers up to a month to complete the onboarding process and open up their shops, so we began a redesign project to decrease the amount of time it takes to open a shop on Etsy.

At the onset of the project, we defined a number of metrics to determine the success of the redesign, including:

  • the time it took for a seller to go through the onboarding process
  • the percentage of shops that completed onboarding
  • key shop success metrics, such as the number of listings in a shop

We designed another version of onboarding that was solely about getting the basics of a shop—shop name, items, payments—in place. Anything optional, like a decorative banner, return policy, or an About page, could be easily added after the shop opened. We were thrilled with the new interface and simple design, but we wanted proof that this was the right direction.

It’s a good thing we tested the new onboarding against the old. When the results of the experiment came back, we saw that more people were completing the new onboarding (good!), but the number of listings per shop was down (bad!). We had over-optimized and made it too easy for new sellers to go through onboarding. The data from the experiment uncovered design flaws that we never would have found otherwise.

Share early and often

Becoming comfortable with showing unfinished design work isn’t easy. As designers, we’re tempted to want to exhibit control over our work. But by waiting until the very end, we’re assuming that our decisions are right. There’s so much that we can learn early on from the people who use our products. Ultimately, we want to be confident going into a launch that our users won’t feel surprised, confused, or ignored.

Successful product launches are a direct result of continual research throughout a project. Using a variety of methods to get feedback at different points in the process will help surface a range of issues. Addressing these issues will bring your product that much closer to meeting your users’ needs. Don’t wait until design decisions are solidified to ask what your users think. If you ask questions at the right times along the way, you’ll be surprised by what you learn.

Read the full article


This week’s sponsor: Bushel

Source: A List Apart

Managing MacBooks and iPhones for your team? Our sponsor Bushel is here to help, so you can focus on work.

Read the full article


Who Needs UX Strategy?

Source: UXMatters

By Paul Bryan

Published: August 10, 2015

“UX strategy is a counterbalance to efficiency-driven, product-centric methodologies like agile, Lean Startup, and Lean UX.”

UX strategy has come into prominence in the past few years as a specialty area within the field of User Experience, as shown by the rapid increase in UX Strategist job titles and events such as the conference UX STRAT. For many of us who have been in the field for a long time, UX strategy is a counterbalance to efficiency-driven, product-centric methodologies like agile, Lean Startup, and Lean UX. For others, it is a natural progression from basic UX design activities like wireframing to more rigorous, analytical activities such as formulating data-driven personas.

An important question that people ask me frequently at the UX STRAT events that I organize is: “Who needs a UX strategy?” Developing a UX strategy takes time and effort, so what circumstances indicate that developing a UX strategy would be a profitable exercise? The short answer to this question is: If your company has multiple digital products and services, has access to substantial customer data, and has competitors that could take away market share, you need an overarching experience strategy to guide product and service design. Conversely, if your company is a startup with one or two products and an extremely limited runway before it runs out of cash, you should focus on developing a product strategy that is more fluid. This strategy may change as you show your product to potential users before or even after launch.
Who Needs UX Strategy?


Applied UX Strategy, Part 3: Platform Thinking

Source: UXMatters

By Yury Vetrov

Published: August 10, 2015

“Many designers still focus on deliverables—work products of their creative process.”

In Part 1 of my series on applied UX strategy, I defined a framework and a profile for product designers. We need both to approach design systematically. Now, in Part 3, I’ll explore how these work.

Many designers still focus on deliverables—work products of their creative process. Following this approach, they do research on a market and users, define scenarios and information architectures, explore solutions through sketching and prototyping, create mockups and guidelines, then give all of their deliverables to the developers. Next, they review the implementation of their design, which usually requires a lot of corrections, until the team achieves the right product-market fit and a decent level of quality. While this works in general, this classic assembly-line approach burns a lot of time and effort on needless deliverables. Designers spend their time polishing supplementary documentation instead of focusing on the product itself. The purpose of most deliverables is simply to transfer knowledge about the product design to other team members, and they quickly become obsolete. This approach leads to high transactional costs. It’s definitely not an optimal approach!
Applied UX Strategy, Part 3: Platform Thinking


UX Strategies Summit 2015 Review, Part 2: Day 1 of the General Summit

Source: UXMatters

By Pabini Gabriel-Petit and Jim Nieters

Published: August 10, 2015

“For Day 2 of the conference, the audience was happily united in a single track.”

In Part 1 of our three-part review of UX Strategies Summit 2015, we provided an overview of the conference’s organization, content and presenters, proceedings, venue, hospitality, community, and workshops, as well as a detailed review of the workshop that Pabini attended, “Rapid Prototyping for Mobile Experience Design,” which was presented by Will Hacker. Now, in Part 2, we’ll review Day 1 of the General Summit, which took place on June 11, at the Marines’ Memorial Club & Hotel, in San Francisco, California.

Highlights from Day 1 of the General Summit

The stronger day of the two-day General Summit, Day 1 began well, with all attendees together in the elegant Commandants room for two sessions.
UX Strategies Summit 2015 Review, Part 2: Day 1 of the General Summit


The Intersection of Design and Technology: How to Find Development Harmony

Source: UXMatters

By Jaron Rubenstein

Published: August 10, 2015

“There’s a tough balancing act between form and function. Functional solutions often lack visual appeal, while designs with a visual focus sometimes lack functionality and usability.”

When design studio karlssonwilker came to me with a concept for Wolf-Gordon’s new Web site, another development firm had already given up on their vision. The studio wanted an interactive experience that would allow users to leaf through wall-covering swatches as though they were in a bricks-and-mortar store. Their previous development firm had believed that this vision was too ambitious. The site design would require a cutting-edge technology implementation.

Anyone who has ever tried to bring a product to market knows this challenge well. There’s a tough balancing act between form and function. Functional solutions often lack visual appeal, while designs with a visual focus sometimes lack functionality and usability. But that’s no reason to cite irreconcilable differences and give up. By taking the right approach, designers and developers can marry form and function—hitting the sweet spot between simple engineering and a seamless user experience.
The Intersection of Design and Technology: How to Find Development Harmony

Older posts «