In Part 1 of this series, we explored the “lopsided horse” problem born from mockup-centric design and demonstrated how the seductive promise of vibe coding often leads to structural flaws. The main question remains:

How might we close the gap between our design intent and a live prototype, so that we can iterate on real functionality from day one, without getting caught in the ambiguity trap?

In other words, we need a way to build prototypes that are both fast to create and founded on a clear, unambiguous blueprint.

The answer is a more disciplined process I call Intent Prototyping (kudos to Marco Kotrotsos, who coined Intent-Oriented Programming). This method embraces the power of AI-assisted coding but rejects ambiguity, putting the designer’s explicit intent at the very center of the process. It receives a holistic expression of intent (sketches for screen layouts, conceptual model description, boxes-and-arrows for user flows) and uses it to generate a live, testable prototype.

This method solves the concerns we’ve discussed in Part 1 in the best way possible:

• Unlike static mockups, the prototype is fully interactive and can be easily populated with a large amount of realistic data. This lets us test the system’s underlying logic as well as its surface.
• Unlike a vibe-coded prototype, it is built from a stable, unambiguous specification. This prevents the conceptual model failures and design debt that happen when things are unclear. The engineering team doesn’t need to reverse-engineer a black box or become “code archaeologists” to guess at the designer’s vision, as they receive not only a live prototype but also a clearly documented design intent behind it.

This combination makes the method especially suited for designing complex enterprise applications. It allows us to test the system’s most critical point of failure, its underlying structure, at a speed and flexibility that was previously impossible. Furthermore, the process is built for iteration. You can explore as many directions as you want simply by changing the intent and evolving the design based on what you learn from user testing.

My Workflow

To illustrate this process in action, let’s walk through a case study. It’s the very same example I’ve used to illustrate the vibe coding trap: a simple tool to track tests to validate product ideas. You can find the complete project, including all the source code and documentation files discussed below, in this GitHub repository.

Step 1: Expressing An Intent

Imagine we’ve already done proper research, and having mused on the defined problem, I begin to form a vague idea of what the solution might look like. I need to capture this idea immediately, so I quickly sketch it out:

In this example, I used Excalidraw, but the tool doesn’t really matter. Note that we deliberately keep it rough, as visual details are not something we need to focus on at this stage. And we are not going to be stuck here: we want to make a leap from this initial sketch directly to a live prototype that we can put in front of potential users. Polishing those sketches would not bring us any closer to achieving our goal.

What we need to move forward is to add to those sketches just enough details so that they may serve as a sufficient input for a junior frontend developer (or, in our case, an AI assistant). This requires explaining the following:

• Navigational paths (clicking here takes you to).
• Interaction details that can’t be shown in a static picture (e.g., non-scrollable areas, adaptive layout, drag-and-drop behavior).
• What parts might make sense to build as reusable components.
• Which components from the design system (I’m using Ant Design Library) should be used.
• Any other comments that help understand how this thing should work (while sketches illustrate how it should look).

Having added all those details, we end up with such an annotated sketch:

As you see, this sketch covers both the Visualization and Flow aspects. You may ask, what about the Conceptual Model? Without that part, the expression of our intent will not be complete. One way would be to add it somewhere in the margins of the sketch (for example, as a UML Class Diagram), and I would do so in the case of a more complex application, where the model cannot be simply derived from the UI. But in our case, we can save effort and ask an LLM to generate a comprehensive description of the conceptual model based on the sketch.

For tasks of this sort, the LLM of my choice is Gemini 2.5 Pro. What is important is that this is a multimodal model that can accept not only text but also images as input (GPT-5 and Claude-4 also fit that criteria). I use Google AI Studio, as it gives me enough control and visibility into what’s happening:

Note: All the prompts that I use here and below can be found in the Appendices. The prompts are not custom-tailored to any particular project; they are supposed to be reused as they are.

As a result, Gemini gives us a description and the following diagram:

The diagram might look technical, but I believe that a clear understanding of all objects, their attributes, and relationships between them is key to good design. That’s why I consider the Conceptual Model to be an essential part of expressing intent, along with the Flow and Visualization.

As a result of this step, our intent is fully expressed in two files: Sketch.png and Model.md. This will be our durable source of truth.

Step 2: Preparing A Spec And A Plan

The purpose of this step is to create a comprehensive technical specification and a step-by-step plan. Most of the work here is done by AI; you just need to keep an eye on it.

I separate the Data Access Layer and the UI layer, and create specifications for them using two different prompts (see Appendices 2 and 3). The output of the first prompt (the Data Access Layer spec) serves as an input for the second one. Note that, as an additional input, we give the guidelines tailored for prototyping needs (see Appendices 8, 9, and 10). They are not specific to this project. The technical approach encoded in those guidelines is out of the scope of this article.

As a result, Gemini provides us with content for DAL.md and UI.md. Although in most cases this result is quite reliable enough, you might want to scrutinize the output. You don’t need to be a real programmer to make sense of it, but some level of programming literacy would be really helpful. However, even if you don’t have such skills, don’t get discouraged. The good news is that if you don’t understand something, you always know who to ask. Do it in Google AI Studio before refreshing the context window. If you believe you’ve spotted a problem, let Gemini know, and it will either fix it or explain why the suggested approach is actually better.

It’s important to remember that by their nature, LLMs are not deterministic and, to put it simply, can be forgetful about small details, especially when it comes to details in sketches. Fortunately, you don’t have to be an expert to notice that the “Delete” button, which is in the upper right corner of the sketch, is not mentioned in the spec.

Don’t get me wrong: Gemini does a stellar job most of the time, but there are still times when it slips up. Just let it know about the problems you’ve spotted, and everything will be fixed.

Once we have Sketch.png, Model.md, DAL.md, UI.md, and we have reviewed the specs, we can grab a coffee. We deserve it: our technical design documentation is complete. It will serve as a stable foundation for building the actual thing, without deviating from our original intent, and ensuring that all components fit together perfectly, and all layers are stacked correctly.

One last thing we can do before moving on to the next steps is to prepare a step-by-step plan. We split that plan into two parts: one for the Data Access Layer and another for the UI. You can find prompts I use to create such a plan in Appendices 4 and 5.

Step 3: Executing The Plan

To start building the actual thing, we need to switch to another category of AI tools. Up until this point, we have relied on Generative AI. It excels at creating new content (in our case, specifications and plans) based on a single prompt. I’m using Google Gemini 2.5 Pro in Google AI Studio, but other similar tools may also fit such one-off tasks: ChatGPT, Claude, Grok, and DeepSeek.

However, at this step, this wouldn’t be enough. Building a prototype based on specs and according to a plan requires an AI that can read context from multiple files, execute a sequence of tasks, and maintain coherence. A simple generative AI can’t do this. It would be like asking a person to build a house by only ever showing them a single brick. What we need is an agentic AI that can be given the full house blueprint and a project plan, and then get to work building the foundation, framing the walls, and adding the roof in the correct sequence.

My coding agent of choice is Google Gemini CLI, simply because Gemini 2.5 Pro serves me well, and I don’t think we need any middleman like Cursor or Windsurf (which would use Claude, Gemini, or GPT under the hood anyway). If I used Claude, my choice would be Claude Code, but since I’m sticking with Gemini, Gemini CLI it is. But if you prefer Cursor or Windsurf, I believe you can apply the same process with your favourite tool.

Before tasking the agent, we need to create a basic template for our React application. I won’t go into this here. You can find plenty of tutorials on how to scaffold an empty React project using Vite.

Then we put all our files into that project:

Once the basic template with all our files is ready, we open Terminal, go to the folder where our project resides, and type “gemini”:

And we send the prompt to build the Data Access Layer (see Appendix 6). That prompt implies step-by-step execution, so upon completion of each step, I send the following:

Thank you! Now, please move to the next task.
Remember that you must not make assumptions based on common patterns; always verify them with the actual data from the spec. 
After each task, stop so that I can test it. Don’t move to the next task before I tell you to do so.

As the last task in the plan, the agent builds a special page where we can test all the capabilities of our Data Access Layer, so that we can manually test it. It may look like this:

It doesn’t look fancy, to say the least, but it allows us to ensure that the Data Access Layer works correctly before we proceed with building the final UI.

And finally, we clear the Gemini CLI context window to give it more headspace and send the prompt to build the UI (see Appendix 7). This prompt also implies step-by-step execution. Upon completion of each step, we test how it works and how it looks, following the “Manual Testing Plan” from UI-plan.md. I have to say that despite the fact that the sketch has been uploaded to the model context and, in general, Gemini tries to follow it, attention to visual detail is not one of its strengths (yet). Usually, a few additional nudges are needed at each step to improve the look and feel:

Once I’m happy with the result of a step, I ask Gemini to move on:

Thank you! Now, please move to the next task.
Make sure you build the UI according to the sketch; this is very important. Remember that you must not make assumptions based on common patterns; always verify them with the actual data from the spec and the sketch.  
After each task, stop so that I can test it. Don’t move to the next task before I tell you to do so.

Before long, the result looks like this, and in every detail it works exactly as we intended:

The prototype is up and running and looking nice. Does it mean that we are done with our work? Surely not, the most fascinating part is just beginning.

Step 4: Learning And Iterating

It’s time to put the prototype in front of potential users and learn more about whether this solution relieves their pain or not.

And as soon as we learn something new, we iterate. We adjust or extend the sketches and the conceptual model, based on that new input, we update the specifications, create plans to make changes according to the new specifications, and execute those plans. In other words, for every iteration, we repeat the steps I’ve just walked you through.

Is This Workflow Too Heavy?

This four-step workflow may create an impression of a somewhat heavy process that requires too much thinking upfront and doesn’t really facilitate creativity. But before jumping to that conclusion, consider the following:

• In practice, only the first step requires real effort, as well as learning in the last step. AI does most of the work in between; you just need to keep an eye on it.
• Individual iterations don’t need to be big. You can start with a Walking Skeleton: the bare minimum implementation of the thing you have in mind, and add more substance in subsequent iterations. You are welcome to change your mind about the overall direction in between iterations.
• And last but not least, maybe the idea of “think before you do” is not something you need to run away from. A clear and unambiguous statement of intent can prevent many unnecessary mistakes and save a lot of effort down the road.

Intent Prototyping Vs. Other Methods

There is no method that fits all situations, and Intent Prototyping is not an exception. Like any specialized tool, it has a specific purpose. The most effective teams are not those who master a single method, but those who understand which approach to use to mitigate the most significant risk at each stage. The table below gives you a way to make this choice clearer. It puts Intent Prototyping next to other common methods and tools and explains each one in terms of the primary goal it helps achieve and the specific risks it is best suited to mitigate.

The key takeaway is that each method is a specialized tool for mitigating a specific type of risk. For example, Figma de-risks the visual presentation. ProtoPie de-risks the feel of an interaction. Intent Prototyping is in a unique position to tackle the most foundational risk in complex applications: building on a flawed or incoherent conceptual model.

Bringing It All Together

The era of the “lopsided horse” design, sleek on the surface but structurally unsound, is a direct result of the trade-off between fidelity and flexibility. This trade-off has led to a process filled with redundant effort and misplaced focus. Intent Prototyping, powered by modern AI, eliminates that conflict. It’s not just a shortcut to building faster — it’s a fundamental shift in how we design. By putting a clear, unambiguous intent at the heart of the process, it lets us get rid of the redundant work and focus on architecting a sound and robust system.

There are three major benefits to this renewed focus. First, by going straight to live, interactive prototypes, we shift our validation efforts from the surface to the deep, testing the system’s actual logic with users from day one. Second, the very act of documenting the design intent makes us clear about our ideas, ensuring that we fully understand the system’s underlying logic. Finally, this documented intent becomes a durable source of truth, eliminating the ambiguous handoffs and the redundant, error-prone work of having engineers reverse-engineer a designer’s vision from a black box.

Ultimately, Intent Prototyping changes the object of our work. It allows us to move beyond creating pictures of a product and empowers us to become architects of blueprints for a system. With the help of AI, we can finally make the live prototype the primary canvas for ideation, not just a high-effort afterthought.

Appendices

You can find the full Intent Prototyping Starter Kit, which includes all those prompts and guidelines, as well as the example from this article and a minimal boilerplate project, in this GitHub repository.

(yk)

There is a spectrum of opinions on how dramatically all creative professions will be changed by the coming wave of agentic AI, from the very skeptical to the wildly optimistic and even apocalyptic. I think that even if you are on the “skeptical” end of the spectrum, it makes sense to explore ways this new technology can help with your everyday work. As for my everyday work, I’ve been doing UX and product design for about 25 years now, and I’m always keen to learn new tricks and share them with colleagues. Right now, I’m interested in AI-assisted prototyping, and I’m here to share my thoughts on how it can change the process of designing digital products.

To set your expectations up front: this exploration focuses on a specific part of the product design lifecycle. Many people know about the Double Diamond framework, which shows the path from problem to solution. However, I think it’s the Triple Diamond model that makes an important point for our needs. It explicitly separates the solution space into two phases: Solution Discovery (ideating and validating the right concept) and Solution Delivery (engineering the validated concept into a final product). This article is focused squarely on that middle diamond: Solution Discovery.

How AI can help with the preceding (Problem Discovery) and the following (Solution Delivery) stages is out of the scope of this article. Problem Discovery is less about prototyping and more about research, and while I believe AI can revolutionize the research process as well, I’ll leave that to people more knowledgeable in the field. As for Solution Delivery, it is more about engineering optimization. There’s no doubt that software engineering in the AI era is undergoing dramatic changes, but I’m not an engineer — I’m a designer, so let me focus on my “sweet spot”.

And my “sweet spot” has a specific flavor: designing enterprise applications. In this world, the main challenge is taming complexity: dealing with complicated data models and guiding users through non-linear workflows. This background has had a big impact on my approach to design, putting a lot of emphasis on the underlying logic and structure. This article explores the potential of AI through this lens.

I’ll start by outlining the typical artifacts designers create during Solution Discovery. Then, I’ll examine the problems with how this part of the process often plays out in practice. Finally, we’ll explore whether AI-powered prototyping can offer a better approach, and if so, whether it aligns with what people call “vibe coding,” or calls for a more deliberate and disciplined way of working.

What We Create During Solution Discovery

The Solution Discovery phase begins with the key output from the preceding research: a well-defined problem and a core hypothesis for a solution. This is our starting point. The artifacts we create from here are all aimed at turning that initial hypothesis into a tangible, testable concept.

Traditionally, at this stage, designers can produce artifacts of different kinds, progressively increasing fidelity: from napkin sketches, boxes-and-arrows, and conceptual diagrams to hi-fi mockups, then to interactive prototypes, and in some cases even live prototypes. Artifacts of lower fidelity allow fast iteration and enable the exploration of many alternatives, while artifacts of higher fidelity help to understand, explain, and validate the concept in all its details.

It’s important to think holistically, considering different aspects of the solution. I would highlight three dimensions:

1. Conceptual model: Objects, relations, attributes, actions;
2. Visualization: Screens, from rough sketches to hi-fi mockups;
3. Flow: From the very high-level user journeys to more detailed ones.

One can argue that those are layers rather than dimensions, and each of them builds on the previous ones (for example, according to Semantic IxD by Daniel Rosenberg), but I see them more as different facets of the same thing, so the design process through them is not necessarily linear: you may need to switch from one perspective to another many times.

This is how different types of design artifacts map to these dimensions:

As Solution Discovery progresses, designers move from the left part of this map to the right, from low-fidelity to high-fidelity, from ideating to validating, from diverging to converging.

Note that at the beginning of the process, different dimensions are supported by artifacts of different types (boxes-and-arrows, sketches, class diagrams, etc.), and only closer to the end can you build a live prototype that encompasses all three dimensions: conceptual model, visualization, and flow.

This progression shows a classic trade-off, like the difference between a pencil drawing and an oil painting. The drawing lets you explore ideas in the most flexible way, whereas the painting has a lot of detail and overall looks much more realistic, but is hard to adjust. Similarly, as we go towards artifacts that integrate all three dimensions at higher fidelity, our ability to iterate quickly and explore divergent ideas goes down. This inverse relationship has long been an accepted, almost unchallenged, limitation of the design process.

The Problem With The Mockup-Centric Approach

Faced with this difficult trade-off, often teams opt for the easiest way out. On the one hand, they need to show that they are making progress and create things that appear detailed. On the other hand, they rarely can afford to build interactive or live prototypes. This leads them to over-invest in one type of artifact that seems to offer the best of both worlds. As a result, the neatly organized “bento box” of design artifacts we saw previously gets shrunk down to just one compartment: creating static high-fidelity mockups.

This choice is understandable, as several forces push designers in this direction. Stakeholders are always eager to see nice pictures, while artifacts representing user flows and conceptual models receive much less attention and priority. They are too high-level and hardly usable for validation, and usually, not everyone can understand them.

On the other side of the fidelity spectrum, interactive prototypes require too much effort to create and maintain, and creating live prototypes in code used to require special skills (and again, effort). And even when teams make this investment, they do so at the end of Solution Discovery, during the convergence stage, when it is often too late to experiment with fundamentally different ideas. With so much effort already sunk, there is little appetite to go back to the drawing board.

It’s no surprise, then, that many teams default to the perceived safety of static mockups, seeing them as a middle ground between the roughness of the sketches and the overwhelming complexity and fragility that prototypes can have.

As a result, validation with users doesn’t provide enough confidence that the solution will actually solve the problem, and teams are forced to make a leap of faith to start building. To make matters worse, they do so without a clear understanding of the conceptual model, the user flows, and the interactions, because from the very beginning, designers’ attention has been heavily skewed toward visualization.

The result is often a design artifact that resembles the famous “horse drawing” meme: beautifully rendered in the parts everyone sees first (the mockups), but dangerously underdeveloped in its underlying structure (the conceptual model and flows).

While this is a familiar problem across the industry, its severity depends on the nature of the project. If your core challenge is to optimize a well-understood, linear flow (like many B2C products), a mockup-centric approach can be perfectly adequate. The risks are contained, and the “lopsided horse” problem is unlikely to be fatal.

However, it’s different for the systems I specialize in: complex applications defined by intricate data models and non-linear, interconnected user flows. Here, the biggest risks are not on the surface but in the underlying structure, and a lack of attention to the latter would be a recipe for disaster.

Transforming The Design Process

This situation makes me wonder:

How might we close the gap between our design intent and a live prototype, so that we can iterate on real functionality from day one?

“

If we were able to answer this question, we would:

• Learn faster.
  By going straight from intent to a testable artifact, we cut the feedback loop from weeks to days.
• Gain more confidence.
  Users interact with real logic, which gives us more proof that the idea works.
• Enforce conceptual clarity.
  A live prototype cannot hide a flawed or ambiguous conceptual model.
• Establish a clear and lasting source of truth.
  A live prototype, combined with a clearly documented design intent, provides the engineering team with an unambiguous specification.

Of course, the desire for such a process is not new. This vision of a truly prototype-driven workflow is especially compelling for enterprise applications, where the benefits of faster learning and forced conceptual clarity are the best defense against costly structural flaws. But this ideal was still out of reach because prototyping in code took so much work and specialized talents. Now, the rise of powerful AI coding assistants changes this equation in a big way.

The Seductive Promise Of “Vibe Coding”

And the answer seems to be obvious: vibe coding!

“Vibe coding is an artificial intelligence-assisted software development style popularized by Andrej Karpathy in early 2025. It describes a fast, improvisational, collaborative approach to creating software where the developer and a large language model (LLM) tuned for coding is acting rather like pair programmers in a conversational loop.”

— Wikipedia

The original tweet by Andrej Karpathy:

The allure of this approach is undeniable. If you are not a developer, you are bound to feel awe when you describe a solution in plain language, and moments later, you can interact with it. This seems to be the ultimate fulfillment of our goal: a direct, frictionless path from an idea to a live prototype. But is this method reliable enough to build our new design process around it?

The Trap: A Process Without A Blueprint

Vibe coding mixes up a description of the UI with a description of the system itself, resulting in a prototype based on changing assumptions rather than a clear, solid model.

The pitfall of vibe coding is that it encourages us to express our intent in the most ambiguous way possible: by having a conversation.

“

This is like hiring a builder and telling them what to do one sentence at a time without ever presenting them a blueprint. They could make a wall that looks great, but you can’t be sure that it can hold weight.

I’ll give you one example illustrating problems you may face if you try to jump over the chasm between your idea and a live prototype relying on pure vibe coding in the spirit of Andrej Karpathy’s tweet. Imagine I want to prototype a solution to keep track of tests to validate product ideas. I open my vibe coding tool of choice (I intentionally don’t disclose its name, as I believe they all are awesome yet prone to similar pitfalls) and start with the following prompt:

I need an app to track tests. For every test, I need to fill out the following data:
- Hypothesis (we believe that...) 
- Experiment (to verify that, we will...)
- When (a single date, or a period) 
- Status (New/Planned/In Progress/Proven/Disproven)

And in a minute or so, I get a working prototype:

Inspired by success, I go further:

Please add the ability to specify a product idea for every test. Also, I want to filter tests by product ideas and see how many tests each product idea has in each status.

And the result is still pretty good:

But then I want to extend the functionality related to product ideas:

Okay, one more thing. For every product idea, I want to assess the impact score, the confidence score, and the ease score, and get the overall ICE score. Perhaps I need a separate page focused on the product idea, with all the relevant information and related tests.

And from this point on, the results are getting more and more confusing.

The flow of creating tests hasn’t changed much. I can still create a bunch of tests, and they seem to be organized by product ideas. But when I click “Product Ideas” in the top navigation, I see nothing:

I need to create my ideas from scratch, and they are not connected to the tests I created before:

Moreover, when I go back to “Tests”, I see that they are all gone. Clearly something went wrong, and my AI assistant confirms that:

No, this is not expected behavior — it’s a bug! The issue is that tests are being stored in two separate places (local state in the Index page and App state), so tests created on the main page don’t sync with the product ideas page.

Sure, eventually it fixed that bug, but note that we encountered this just on the third step, when we asked to slightly extend the functionality of a very simple app. The more layers of complexity we add, the more roadblocks of this sort we are bound to face.

Also note that this specific problem of a not fully thought-out relationship between two entities (product ideas and tests) is not isolated at the technical level, and therefore, it didn’t go away once the technical bug was fixed. The underlying conceptual model is still broken, and it manifests in the UI as well.

For example, you can still create “orphan” tests that are not connected to any item from the “Product Ideas” page. As a result, you may end up with different numbers of ideas and tests on different pages of the app:

Let’s diagnose what really happened here. The AI’s response that this is a “bug” is only half the story. The true root cause is a conceptual model failure. My prompts never explicitly defined the relationship between product ideas and tests. The AI was forced to guess, which led to the broken experience. For a simple demo, this might be a fixable annoyance. But for a data-heavy enterprise application, this kind of structural ambiguity is fatal. It demonstrates the fundamental weakness of building without a blueprint, which is precisely what vibe coding encourages.

Don’t take this as a criticism of vibe coding tools. They are creating real magic. However, the fundamental truth about “garbage in, garbage out” is still valid. If you don’t express your intent clearly enough, chances are the result won’t fulfill your expectations.

Another problem worth mentioning is that even if you wrestle it into a state that works, the artifact is a black box that can hardly serve as reliable specifications for the final product. The initial meaning is lost in the conversation, and all that’s left is the end result. This makes the development team “code archaeologists,” who have to figure out what the designer was thinking by reverse-engineering the AI’s code, which is frequently very complicated. Any speed gained at the start is lost right away because of this friction and uncertainty.

From Fast Magic To A Solid Foundation

Pure vibe coding, for all its allure, encourages building without a blueprint. As we’ve seen, this results in structural ambiguity, which is not acceptable when designing complex applications. We are left with a seemingly quick but fragile process that creates a black box that is difficult to iterate on and even more so to hand off.

This leads us back to our main question: how might we close the gap between our design intent and a live prototype, so that we can iterate on real functionality from day one, without getting caught in the ambiguity trap? The answer lies in a more methodical, disciplined, and therefore trustworthy process.

In Part 2 of this series, “A Practical Guide to Building with Clarity”, I will outline the entire workflow for Intent Prototyping. This method places the explicit intent of the designer at the forefront of the process while embracing the potential of AI-assisted coding.

Thank you for reading, and I look forward to seeing you in Part 2.

(yk)

Ever sat in a meeting where everyone jumped straight to solutions? “We need a new app!” “Let’s redesign the homepage!” “AI will fix everything!” This solution-first thinking is endemic in digital development — and it’s why so many projects fail to deliver real value. As the creator of the Core Model methodology, I developed this approach to flip the script: instead of starting with solutions, we start FROM the answer.

What’s the difference? Starting with solutions means imposing our preconceived ideas. Starting FROM the answer to a user task means forming a hypothesis about what users need, then taking a step back to follow a simple structure that validates and refines that hypothesis.

Six Good Questions That Lead to Better Answers

At its heart, the Core Model is simply six good questions asked in the right order, with a seventh that drives action. It appeals to common sense — something often in short supply during complex digital projects.

When I introduced this approach to a large organization struggling with their website, their head of digital admitted: “We’ve been asking all these questions separately, but never in this structured way that connects them.”

These questions help teams pause, align around what matters, and create solutions that actually work:

1. Who are we trying to help, and what’s their situation?
2. What are they trying to accomplish?
3. What do we want to achieve?
4. How do they approach this need?
5. Where should they go next?
6. What’s the essential content or functionality they need?
7. What needs to be done to create this solution?

This simple framework creates clarity across team boundaries, bringing together content creators, designers, developers, customer service, subject matter experts, and leadership around a shared understanding.

Starting With a Hypothesis

The Core Model process typically begins before the workshop. The project lead or facilitator works with key stakeholders to:

1. Identify candidate cores based on organizational priorities and user needs.
2. Gather existing user insights and business objectives.
3. Form initial hypotheses about what these cores should accomplish.
4. Prepare relevant background materials for workshop participants.

This preparation ensures the workshop itself is focused and productive, with teams validating and refining hypotheses rather than starting from scratch.

The Core Model: Six Elements That Create Alignment

Let’s explore each element of the Core Model in detail:

1. Target Group: Building Empathy First

Rather than detailed personas, the Core Model starts with quick proto-personas that build empathy for users in specific situations:

• A parent researching childcare options late at night after a long day.
• A small business owner trying to understand tax requirements between client meetings.
• A new resident navigating unfamiliar public services in their second language.

The key is to humanize users and understand their emotional and practical context before diving into solutions.

2. User Tasks: What People Are Actually Trying to Do

Beyond features or content, what are users actually trying to accomplish?

• Making an informed decision about a major purchase.
• Finding the right form to apply for a service.
• Understanding next steps in a complex process.
• Checking eligibility for a program or benefit.

These tasks should be based on user research and drive everything that follows. Top task methodology is a great approach to this.

3. Business Objectives: What Success Looks Like

Every digital initiative should connect to clear organizational goals:

• Increasing online self-service adoption.
• Reducing support costs.
• Improving satisfaction and loyalty.
• Meeting compliance requirements.
• Generating leads or sales.

These objectives provide the measurement framework for success. (If you work with OKRs, you can think of these as Key Results that connect to your overall Objective.)

4. Inward Paths: User Scenarios and Approaches

This element goes beyond just findability to include the user’s entire approach and mental model:

• What scenarios lead them to this need?
• What terminology do they use to describe their problem?
• How would the phrase their need to Google or an LLM?
• What emotions or urgency are they experiencing?
• What channels or touchpoints do they use?
• What existing knowledge do they bring?

Understanding these angles of different approaches ensures we meet users where they are.

5. Forward Paths: Guiding the Journey

What should users do after engaging with this core?

• Take a specific action to continue their task.
• Explore related information or options.
• Connect with appropriate support channels.
• Save or share their progress.

These paths create coherent journeys (core flows) rather than dead ends.

6. Core Content: The Essential Solution

Only after mapping the previous elements do we define the actual solution:

• What information must be included?
• What functionality is essential?
• What tone and language are appropriate?
• What format best serves the need?

This becomes our blueprint for what actually needs to be created.

Action Cards: From Insight to Implementation

The Core Model process culminates with action cards that answer the crucial seventh question: “What needs to be done to create this solution?”

These cards typically include:

• Specific actions required;
• Who is responsible;
• Timeline for completion;
• Resources needed;
• Dependencies and constraints.

Action cards transform insights into concrete next steps, ensuring the workshop leads to real improvements rather than just interesting discussions.

The Power of Core Pairs

A unique aspect of the Core Model methodology is working in core pairs—two people from different competencies or departments working together on the same core sheet. This approach creates several benefits:

• Cross-disciplinary insight
  Pairing someone with deep subject knowledge with someone who brings a fresh perspective.
• Built-in quality control
  Partners catch blind spots and challenge assumptions.
• Simplified communication
  One-to-one dialogue is more effective than group discussions.
• Shared ownership
  Both participants develop a commitment to the solution.
• Knowledge transfer
  Skills and insights flow naturally between disciplines.

The ideal pair combines different perspectives — content and design, business and technical, expert and novice — creating a balanced approach that neither could achieve alone.

Creating Alignment Within and Between Teams

The Core Model excels at creating two crucial types of alignment:

Within Cross-Functional Teams

Modern teams bring together diverse competencies:

• Content creators focus on messages and narrative.
• Designers think about user experience and interfaces.
• Developers consider technical implementation.
• Business stakeholders prioritize organizational needs.

The Core Model gives these specialists a common framework. Instead of the designer focusing only on interfaces or the developer only on code, everyone aligns around user tasks and business goals.

As one UX designer told me:

“The Core Model changed our team dynamic completely. Instead of handing off wireframes to developers who didn’t understand the ‘why’ behind design decisions, we now share a common understanding of what we’re trying to accomplish.”

Between Teams Across the Customer Journey

Users don’t experience your organization in silos — they move across touchpoints and teams. The Core Model helps connect these experiences:

• Marketing teams understand how their campaigns connect to service delivery.
• Product teams see how their features fit into larger user journeys.
• Support teams gain context on user pathways and common issues.
• Content teams create information that supports the entire journey.

By mapping connections between cores (core flows), organizations create coherent experiences rather than fragmented interactions.

Breaking Down Organizational Barriers

The Core Model creates a neutral framework where various perspectives can contribute while maintaining a unified direction. This is particularly valuable in traditional organizational structures where content responsibility is distributed across departments.

The Workshop: Making It Happen

The Core Model workshop brings these elements together in a practical format that can be adapted to different contexts and needs.

Workshop Format and Timing

For complex projects with multiple stakeholders across organizational silos, the ideal format is a full-day (6–hour) workshop:

First Hour: Foundation and Context

• Introduction to the methodology (15 min).
• Sharing user insights and business context (15 min).
• Reviewing pre-workshop hypotheses (15 min).
• Initial discussion and questions (15 min).

Hours 2–4: Core Mapping

• Core pairs work on mapping elements (120 min).
• Sharing between core pairs and in plenary between elements.
• Facilitators provide guidance as needed.

Hours 5–6: Presentation, Discussion, and Action Planning

• Each core pair presents its findings (depending on the number of cores).
• Extensive group discussion and refinement.
• Creating action cards and next steps.

The format is highly flexible:

• Teams experienced with the methodology can conduct focused sessions in as little as 30 minutes.
• Smaller projects might need only 2–3 hours.
• Remote teams might split the workshop into multiple shorter sessions.

Workshop Environment

The Core Model workshop thrives in different environments:

• Analog: Traditional approach using paper core sheets.
• Digital: Virtual workshops using Miro, Mural, FigJam, or similar platforms.
• Hybrid: Digital canvas in physical workshop, combining in-person interaction with digital documentation.

Note: You can find all downloads and templates here.

Core Pairs: The Key to Success

The composition of core pairs is critical to success:

• One person should know the solution domain well (subject matter expert).
• The other brings a fresh perspective (and learns about a different domain).
• This combination ensures both depth of knowledge and fresh thinking.
• Cross-functional pairing creates natural knowledge transfer and breaks down silos.

Workshop Deliverables

Important to note: The workshop doesn’t produce final solutions.

Instead, it creates a comprehensive brief containing the following:

• Priorities and context for content development.
• Direction and ideas for design and user experience.
• Requirements and specifications for functionality.
• Action plan for implementation with clear ownership.

This brief becomes the foundation for subsequent development work, ensuring everyone builds toward the same goal while leaving room for specialist expertise during implementation.

Getting Started: Your First Core Model Implementation

Ready to apply the Core Model in your organization? Here’s how to begin:

1. Form Your Initial Hypothesis

Before bringing everyone together:

• Identify a core where users struggle and the business impact is clear.
• Gather available user insights and business objectives.
• Form a hypothesis about what this core should accomplish.
• Identify key stakeholders across relevant departments.

2. Bring Together the Right Core Pairs

Select participants who represent different perspectives:

• Content creators paired with designers.
• Business experts paired with technical specialists.
• Subject matter experts paired with user advocates.
• Veterans paired with fresh perspectives.

3. Follow the Seven Questions

Guide core pairs through the process:

• Who are we trying to help, and what’s their situation?
• What are they trying to accomplish?
• What do we want to achieve?
• How do they approach this need?
• Where should they go next?
• What’s the essential content or functionality?
• What needs to be done to create this solution?

4. Create an Action Plan

Transform insights into concrete actions:

• Document specific next steps on action cards.
• Assign clear ownership for each action.
• Establish timeline and milestones.
• Define how you’ll measure success.

In Conclusion: Common Sense In A Structured Framework

The Core Model works because it combines common sense with structure — asking the right questions in the right order to ensure we address what actually matters.

By starting FROM the answer, not WITH the solution, teams avoid premature problem-solving and create digital experiences that truly serve user needs while achieving organizational goals.

Whether you’re managing a traditional website, creating multi-channel content, or developing digital products, this methodology provides a framework for better collaboration, clearer priorities, and more effective outcomes.

This article is a short adaptation of my book The Core Model — A Common Sense to Digital Strategy and Design. You can find information about the book and updated resources at thecoremodel.com.

(yk)

As a designer, you’re no doubt familiar with the concept of the Double Diamond, that super simple graphical representation of the ideal design process.

Typically you’ll see two squares rotated 45 degrees: the first square will say something like “discover” and “define,” while the second one will encourage you to “explore” and “create.” Each diamond will have a heading, such as “problem” and “solution,” or the more punchy “design the right thing” and “design the thing right.” Along the side of each diamond, there will be a label explaining how you must first diverge, i.e., come up with lots of options before you can converge into a single answer.

It’s one of the simplest articulations of the design process out there. It’s also why many designers hate their jobs. Let me explain…

Note: If you’re curious as to who and when nailed down the Double Diamond concept in its present modern form — which we see being referenced practically everywhere nowadays — check the Appendix at the end of the article (“How do We Describe Design Process?”).

Designers Are Problem-Finders And Problem-Solvers

As designers, we like to think of ourselves as problem-finders as well as problem-solvers. Give us a user challenge, and we’ll use our research skills to uncover what’s really going on below the surface! We’ll take this information, reframe the problem, and come up with an even better solution — one that’s never been considered before. That’s what the double diamond is all about. It’s about avoiding the obvious, shallow solutions and instead freeing us up to be truly creative.

“The formulation of a problem is often more essential than its solution, which may be merely a matter of mathematical or experimental skill. To raise new questions, new possibilities, to regard old problems from a new angle, requires creative imagination and marks real advance in science.”

— Albert Einstein & Leopold Infeld (via: “Using the Problem Reframing Method”

I think the best example of this can be found in the UK TV program Blue Peter, a British children’s television entertainment program created by John Hunter Blair, which is the longest-running children’s TV show in the world.

A few years back, Blue Peter got to interview design legend Jony Ive. They explained to Jony how they’d set a challenge for their young viewers to design a lunchbox, pencil case, and school bag, all in one. He responded by saying that you needed to be really careful not to have the word “box” in the brief because it might determine the path you went down. You could imagine if Jony had set the challenge, he might have asked the kids to “design a means of storing and transporting your lunch to school.” A nice reframing of the problem which didn’t contain the proposed solution!

I’ve been in countless meetings where stakeholders have effectively made the same “mistake” as the Blue Peter presenters when they defined what the outcome should be. And I have seen an equal number of annoyed designers, questioning the point of them even being there if they’re just going to be told what to design and how to design it. (And, of course, they rarely say this to the stakeholders’ faces. Instead, they simply moan about it behind their backs.)

Exploring The Context

Designers understandably feel frustrated when asked to “design a lunchbox” because it immediately limits the potential outcome. This goes against what they’ve been taught design is all about and what design workflow models, such as the Double Diamond claim.

In an ideal world, designers would much prefer to spend time “bathing” in the problem space. This would include wanting to understand the variety of food items kids take to school with them and the level of protection they need. It would also involve following kids’ journeys over a couple of weeks to see how the products are used and talking to kids, to understand what they think is cool, and to their parents, to understand what’s practical. Of course, there’s a good chance that after all this, you might decide that a lunch box is exactly the sort of thing you should be designing! However, rather than this being only a hypothesis, you’ll now have confidence that you’re on the right path.

The architect Eliel Saarinen talks eloquently about the importance of designing a thing by considering it in its context:

“Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan.”

— Eliel Saarinen

As such, it’s natural for designers to want to diverge, even if they end up converging on exactly the same thing. However, for our business partners, this sort of behavior can be very frustrating.

What If You Actually Just Want A Lunch Box?

While designers like to believe they’ve been hired to “think outside the lunch box” (sorry for the pun), the truth of the matter is that most business stakeholders don’t see design this way.

Instead, when most business stakeholders are tasked with creating a way for kids to take food to school, they immediately think of “lunchbox.” They will then ask their industrial designers and graphic designers to come up with something interesting that parents and children will buy; ideally, something which can be made cost-effectively using their existing factories, equipment, and supply chain. Oh, and they need it ready for when the kids go back to school in three months’ time, as that’s peak lunchbox-buying season.

Question: How many UX Designers does it take to screw in a lightbulb?
Answer: First, we need to undertake a six months long project understanding the role of light in society!

In this context, the organization has already decided that the lunchbox is a perfectly reasonable, logical, and obvious solution, so when the design team starts pushing back and asking for time to do additional research, it sounds like a waste of time. Or worse, it might sound like the design team is actively trying to derail the project. As such, much as I hate to say this, sometimes you’ve just got to grit your teeth and design the darn lunchbox.

How Design Actually Gets Done (Outside Apple And Airbnb)

While the double diamond concept is a wonderful model, it’s also largely a fantasy. Instead, most organizations will have a few meetings which generally won’t involve design (sorry). If you’re lucky, they might look at some external survey data or market data and come to the conclusion that we, too, need a lunchbox.

Getting anything done inside even a relatively small organization takes effort, as anybody who has ever been tasked to organize a team lunch or a short company retreat will know. As such, it usually requires a senior stakeholder to galvanize support. Because of this, “customer discovery” is often more about finding evidence to back up the assertion that this is the right thing to build rather than potentially discovering that it’s the wrong thing to build.

By the time the idea gets to design, the decision has usually been made, resources have usually already been allocated, a launch date may have been set (often arbitrarily and without really understanding how long designing the thing will actually take), and there’s little or no interest in doing anything which might slow this decision train down or derail it altogether. I call this process the reverse double diamond.

While this way of working may seem crazy to designers, in most organizations, this is exactly how things work, and fighting against that process is truly an uphill battle. However, there is an opportunity here if you want to grab it, which lies in the second half of the “reverse double diamond” concept.

The Reverse Double Diamond (Or Making It Work Better)

Now, let me start with this: I’m not claiming that the reverse double diamond is ideal. Far from it. However, it is a realistic model for how work actually gets done.

I also believe there is a way for design teams to slowly — and I really do mean slowly — pivot away from this and towards the traditional double diamond. But you’re not going to get there by adding a couple of slides about it to the design deck your boss asks you to present at the next leadership away day. Instead, it’s all about what you do post-launch.

If you take a close look at the model above, you’ll see that the first part of the reverse double diamond is essentially accepting the status quo, letting your boss tell you to deliver the metaphorical equivalent of a “lunchbox feature,” and creating the best version possible with the time and information available. However, the trick to making the reverse double diamond work is to actively monitor how this new feature performs and — wait for it — make suggestions about how it can be improved post-launch.

Once the lunchbox feature has been delivered and is out in the wild, the stakeholder who sponsored it no longer needs to be protective of it. The problem switches from being a delivery problem (“Can we actually get this thing launched?”) to being a value extraction problem (“How can we make this existing thing work better?”). This is the exact point in time where you put your business hat on, look at the stats, and say something like this, “This feature currently has relatively low utilization of only 5%. However, we believe that with some tweaks, we can get this up to 20%.”

In ye olde days, this used to be called “making a business case,” and it’s frankly much easier to make a business case for something that already exists and you believe can be made better than it is doing research on something that doesn’t yet exist and might be just fine as it is.

In essence, you’re still doing research work, and you’re still going to be exploring a range of potential solutions — you’re just doing this once the feature is already out in the market and you know exactly how it’s performing. Of course, this all depends on a number of things, including how well or poorly the feature performs, how good your design and product leaders are at making a business case, and how much work the design team has on. Unless you’re able to make a solid release plan, it’s likely that the second half of the reverse double diamond will actually be uncoupled from the first.

For companies that have featured teams and growth teams, it’s even possible that your feature teams will deliver the first half of the reverse double diamond before handing it over to the growth team to do the second half. As a result, this process is less than ideal. However, it’s much more pragmatic and goes fine “with the grain” of most organizations.

Iterating Towards The Traditional Double Diamond

Earlier, I hinted that this process might, over time, allow you to get to the “design nirvana” represented by the traditional double diamond. The logic here is that by constantly improving products post-launch, the organization learns to trust the design team’s ability and, more importantly, their vision.

As you garner more trust and evidence, over time, you can start making the case that it would be quicker and more cost-effective if you spent a few weeks upfront trying to avoid the mistakes, which can often take months or even years to address. Mistakes that will also often result in some lost revenue. In fact, this is effectively the same argument many designers make for adopting the traditional double diamond workflow in the first place — you’re just doing so by using evidence rather than belief and theory.

Conclusion

The Double Diamond concept is great, but it’s just not the way most organizations function. If, as a designer, you set your expectations around this theoretical model, you’re going to be continually disappointed! However, designers are meant to be great at understanding how things actually work rather than how we think they should work.

If we want to initiate change, we need to ask for more accurate models of how design actually works inside our organizations and target the areas where we have the most leverage. I believe this means adopting some variant of the “reverse double diamond” idea, accepting that we’re going to be told to deliver “lunch box features” 90% of the time, and shifting our attention away from pre-launch solutions to post-launch solutions.

We can design and then release a good first version of a product out into the world as quickly as possible and then use our business and communication skills to petition for and make measurable improvements to it. And if we can do this consistently, there’s a slim — but tangible! — chance that we can switch the “double diamond” back around.

Further Reading

• “Should You Create An MVP Before Creating An App?,” by Suzanne Scacca (Smashing Magazine)
  Apps are neither small undertaking nor cheap to build and maintain. So, before you move ahead with creating a new mobile app or SaaS for your client, perhaps you should consider launching a minimum viable product (MVP) instead. With an MVP, you have a low-risk and lower-cost way of testing your concept on the market. What’s not to love about that?
• “Getting Back Into The (Right) Deliverables Business,” by Rian van der Merwe (Smashing Magazine)
  “Get out of the deliverables business” has become quite a mantra in the lean startup and UX movements. There’s much to love in that sentiment. After all, for every wireframe you make, you’re not shipping code to customers. But just like with the concept of a minimum viable product (MVP), it’s likely that we’ve taken this sound advice to an extreme which actually is hurtful to the creation of good products. What follows is the author’s account of navigating these stormy design seas together with the community.
• “Design Thinking & Minimum Viable Product: Is This the Right Approach?,” by Masha Panchenko (Eleken Blog)
  Design thinking has become a highly popular approach during the last forty years. It is used in IT, business, education, design — literally everywhere. There is even a book about applying design thinking for personal use called Designing Your Life. We don’t know if design thinking will help to change your life for the better, but what we know is that design thinking is a great approach when it comes to building a Minimum Viable Product.
• Designing Your Life, a book by Bill Burnett & Dave Evans
  A book that shows you how to build — to design — a life you can thrive in at any age or stage. Designers create worlds and solve problems using design thinking. Everything in our lives was designed by someone, and every design starts with a problem that a designer or team of designers seeks to solve. In this book, the authors show us how design thinking can help us create a life that is both meaningful and fulfilling, regardless of who or where we are, what we do or have done for a living, or how young or old we are.
  (Editor’s Note: This book was, in fact, also recommended to me by Joshua Mauldin a while ago, and I cannot but highly recommend it to everyone! It’s a fantastic, very useful read. — M.B.)
• “Using the Problem Reframing Method,” by Sebastian Straube (product management & discovery coach at Accenture Business Agility)
  Avoid jumping directly into solution thinking and not empathizing with the problem itself; looking at a problem from different angles helps to build more innovative, sustainable solutions, and you need to try different reframing practices and methods as there is not a one-size-fits-all approach.
• “Is UX Research About ‘De-risking’ Design?,” by Jonathan Baker-Bates (UX architect at LBi, VP of UX at TES Global)
  Is UX research centered on helping designers predict eventual outcomes of design interventions, or is its role to “de-risk” UX and business ideas? Research is often framed as a way of lowering the risk to the business (this applies both to design validation as well as to exploratory research), but research should be checking whether what we said about a given intervention actually tends to happen.
• “Modern Double Diamond design: Rethinking a classic design process,” by Victory Brown
  To accomplish your tasks, you’ll need to set up a process that will allow you to complete them quickly and also give the best results. Sometimes the design process can be a jungle of trends and patterns; it involves a lot of back and forth to produce the best design solutions. No design is the final design, and every procedure can be iterated on. This is why the Design Council came together in 2005 to develop a new approach to designing solutions with creative thinking, systems design, and design management in mind: the Double Diamond design process.
• “History of the Double Diamond”
  This article describes the history behind the Double Diamond concept, created by the Design Council (established in 1944 by Winston Churchill’s wartime government). Over the course of several sessions, the group came up with a simplified way to describe any design and innovation process. It is based on four distinct phases that the design team, deliberately seeking a memorable device, named Discover, Define, Develop, and Deliver.

Appendix: “How Do We Describe The Design Process?”

A short bit of history. In 2003, the Design Council promoted the positive impact of adopting a strategic approach to design and the value of “design management” as a practice. However, they had no standard way of describing the supporting process. Richard Eisermann, Design Council’s then Director of Design and Innovation, thought this was incompatible with their broader message, so he asked his team, “How do we describe the design process?”

“The team put in the work trying to define design, process, methods, etc. What we did with the Double Diamond was codify it, rename the steps, and popularize it. It was important work, but we were certainly standing on the shoulders of giants.”

— Richard Eisermann

Of course, kite-shaped (diamond-shaped) process models have been referenced as far back as the 1960s, but models of the design process were not widely shared at this point. Part of the Design Council’s reason for creating the Double Diamond concept was to address this lack of visibility. Today the Double Diamond is considered a universally accessible description of the design process, has become an accepted part of design language, and is used and referenced worldwide.

→ History of the Double Diamond, The Design Council

(mb, yk)

Design process is messy. You might be following a structured approach, but with all the last-minute changes and overlooked details, too often, it takes a life of its own. And before you know it, you are designing in a chaotic environment full of refinements, final-final deliverables, and missed deadlines.

This article is part of our ongoing series on design patterns. It’s an upcoming part of the video library on Smart Interface Design Patterns 🍣 and is a part of the live UX training as well.

What’s The “Right” Design Process?

Of course, there is no “right-and-only” way to frame a design process. It’s defined by whatever works well for you and for your team. Personally, I tend to rely on 4 design models that seem to fit well with my design work:

• Double Diamond Process for its comprehensive and reliable methodology for solving problems. In this guide, Dan Nessler breaks down the entire Double-Diamond process into single parts, explaining how exactly it works, step-by-step, in all fine details.

• Triple Diamond Process for its more realistic approach to the designer’s input across the product’s life cycle. That’s a piece by Adam Gray on why bringing flexibility to the messy reality of the design process is critical to improving planning and involving design work as prototypes are being built.

• Enterprise Design Thinking Model by IBM for its focus on design maturity and scale, which really helps large organizations. A useful model that helps argue for user research, user-centricity, and rapid low-fidelity prototyping — and how to transfer ownership to design teams at scale.

• Hot Potato process, for its simplicity in bridging design and development across the entire product lifecycle. Designers and developers throw ideas, mock-ups, and prototypes to each other permanently. Sometimes there are more involved design phases than dev phases, but there is no hand-off, and the entire process is driven by continuous collaboration.

These ways of thinking about the design process translated into a process that works well for me but has to be adjusted for every project that I’m working on. In a nutshell, here’s how it would work.

A Process That Works For Me

There is no such thing as enough user research. In every project, I start with involving users as early as possible. I explore all the data we have, interview customer support and the service desk, check for technical debt and design issues, backlog items, and dismissed ideas. I explore organizational charts to understand layers of management. I set the right expectations and seek allies.

From there, I would typically spend weeks or even months in diagrams and spreadsheets and endless docs before drawing a single pixel on the screen. I try to get developers on board, so they can start setting up the dev environment already.

I bring in stakeholders and people who have a vested interest in contributing to the success of the project. Voices that need to be heard but are often forgotten. I see my role as a person who needs to bridge the gap between business requirements and user needs through the lens of design.

Then I take a blank piece of paper and start sketching. I sketch ideas. I sketch customer journey maps. I sketch content boxes. I write down components that we will surely need in the product — the usual suspects. I set up a workshop with designers and developers to decide on names. Then developers can go ahead and prototype while designers focus on UI and interaction design.

To make sure I get both sides of the equation right, I draft customer journey maps, brainstorm ideas and prioritize them with the Kano model and Impact ÷ Effort matrix (with developers, PMs, and stakeholders).

I don’t want to waste time designing and building the wrong thing, so I establish design KPIs and connect them with business goals using KPI trees. I get a sign-off on those, and then the interface design starts.

I develop hypotheses. Low-fidelity mock-ups. Speak to developers. Get their feedback. Refine. Throw the mock-ups to developers. Bring them into HTML and CSS. Test hypotheses in usability sessions until we get to an 80% success rate for top tasks. Designers keep refining, and developers keep building out.

Establish a process to continuously measure the quality of design. Track task completion rates. Track task completion times. Track error rates. Track error recovery rates. Track accessibility. Track sustainability. Track performance. In a B2B setting, we track the time customers need to complete their tasks and try to minimize it.

Make them visible to the entire organization to show the value of design and its impact on business KPIs. Explain that the process isn’t based on hunches. It’s an evidence-driven design.

Establish ownership and governance. The search team must be measured by the quality of search results for the top 100 search queries over the last two months. People who publish content are owners of that content. It’s their responsibility to keep it up-to-date, rewrite, archive, or delete it.

Refine, refine, refine. Keep throwing new components and user journeys to developers. Stop. Test with users to check how we are doing. Keep going and refine in the browser. Continuously and rigorously test. Launch and keep refining. Measure the KPIs and report to the next iteration of the design.

Admittedly, it is a bit messy. But it helps me stay on track when navigating a complex problem space in a way that delivers measurable results, removes bias and subjectivity from design decisions, and helps deliver user-centric designs that also address business needs.

Wrapping Up

Of course, there is no “right-and-only” way to frame a design process. It’s defined by whatever works well for you and for your team. Explore options and keep them in mind when designing your design process. Whatever you choose, don’t follow it rigidly just for the sake of it, and combine bits from all models to make it right for you.

As long as it works well for you, it’s right. And that’s the only thing that matters.

You can find more details on design patterns in the video library on Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up in September this year.

Further Reading on Smashing Magazine

• “Why Content Is Such A Fundamental Part Of The Web Design Process,” Matt Saunders
• “Where Does SEO Belong In Your Web Design Process?,” Suzanne Scacca
• “The Impact Of Agile Methodologies On Code Quality,” Sarah Oke Okolo
• “A Pragmatist’s Guide To Lean User Research,” Paul Boag

(yk, il)

As software development continues to evolve, so too do the methodologies and approaches used to create it. In recent years, Agile methodologies have gained widespread adoption as a modern approach to software development, with a focus on flexibility, collaboration, and delivering working software in short increments. This is a key differentiator when it comes to other development workflows.

One of the key benefits of Agile methodologies is its impact on the quality of the code that ships. Code quality is an essential aspect of software development, as high-quality code is critical to ensure the reliability, maintainability, and scalability of any software, website, or application.

Overview Of Agile Methodologies

Agile methodologies are a set of software development approaches that prioritize flexibility, collaboration, and delivering working software in short increments. Agile methodologies aim to improve the quality of the software by allowing for frequent feedback, continuous improvement, and adaptation to changing requirements.

The Agile Manifesto, created in 2001 by a group of software developers who wanted to find a better way of developing software, outlines the core values and principles of Agile methodologies. These values include prioritizing individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change rather than following a concrete, long-term plan.

Agile methods break down projects into small and manageable units called sprints. Sprints are completed by cross-functional and self-organizing teams in a short period of time, usually two to four weeks. During each sprint, the team works on a specific set of tasks, and at the end of the sprint, they review their work, evaluate customer satisfaction, and identify areas for improvement. Because each sprint is focused on a specific set of tasks, the team can quickly pivot and adjust their approach if they receive new information or feedback from customers or stakeholders. This results in faster turnaround times and a more responsive development process which is essential for creating high-quality software that meets the needs of the end users.

There are several Agile methodologies that teams can choose from to develop software in a more flexible and iterative way.

• Scrum: This is perhaps the most popular Agile methodology. It involves a small team of developers working together in short sprints to deliver a working product incrementally. Each sprint typically lasts for 2–4 weeks.
• Kanban: This methodology focuses on continuous delivery and improving workflow efficiency. Work is broken down into smaller pieces and tracked on a visual board, and team members pull work items as they are ready to work on them. If you’ve used a Trello board before, then you know exactly how this works. Other apps, like Notion, offer similar features.
• Extreme Programming (XP): XP is a methodology that emphasizes software quality and customer satisfaction. It involves practices such as pair programming, test-driven development, and continuous integration.
• Lean Development: This methodology aims to reduce waste and increase efficiency in the development process. It involves continuous improvement and a focus on delivering value to the customer.
• Crystal: This methodology is designed for small teams working on projects with a high degree of uncertainty. It involves frequent communication, regular feedback loops, and an emphasis on collaboration.
  

How Agile Methodologies Can Impact Code Quality

Code quality is one of the most essential aspects of any development process, as it directly impacts the success of any product. Agile methodologies have been designed to prioritize a customer-centric approach by breaking down features into smaller, manageable pieces of functionality. This allows for more frequent releases of working quality code that can be tested and reviewed to help deliver high-quality software that meets customer needs. Here are some practical ways in which Agile methodologies help promote and impact efficient code quality in development:

• Prioritizing simplicity and efficiency.
  Agile methodologies prioritize simplicity and efficiency in software development. This means that developers are encouraged to write code that is not only functional but also easy to understand, test, debug, maintain, and modify. The goal is to create a codebase that is clean and simple, which can help reduce the potential for bugs and errors.
• Encouraging modularization.
  The Agile process promotes the modularization of code. By breaking code down into smaller, modular components, developers can create code that is more flexible and reusable. This can save time and effort in the long run by reducing the need for repetitive or verbose code. Additionally, by optimizing the performance of each component, the developer is able to reduce the overall processing time, resulting in a more efficient codebase, breaking down features into smaller, more manageable pieces — often referred to as user stories or epics. This approach allows development teams to focus on delivering small, working pieces of functionality that can be tested and validated before being integrated into the larger codebase while also enabling them to respond quickly to changing requirements or feedback.
• Improving readability.
  It’s important that code is legible and understood across the team, as it affects not only the developer who wrote the code but also other developers who may need to modify or maintain the code in the future. Agile methodologies help developers focus on writing code that is self-documenting and easy to understand by promoting the use of clear and concise coding practices such as self-descriptive naming conventions and avoiding complex code structures.
• Test-Driven Development (TDD).
  TDD involves writing tests for the code before writing the code itself, which can help ensure that the code is well-structured and easy to read. This method emphasizes continuous feedback and improvement on the code, as developers are regularly provided with feedback on their work and have opportunities to make improvements as they go. By receiving feedback early on in the development process, developers can address issues and make changes to their code before they become bigger problems.
• Continuous integration.
  This is a development practice that involves frequently integrating code changes from multiple developers into a single shared codebase. With continuous integration, code is automatically compiled, tested, and validated, which helps to catch issues early on in the development process. This approach ensures that code is always in a releasable state, which ultimately helps to improve code quality and reduce the risk of bugs or errors.

Overall, Agile methodologies can help developers write better code by promoting continuous code feedback and improvement while prioritizing simplicity and efficiency. By following these principles, developers can create code that is more efficient, maintainable, and robust, ultimately resulting in a better end product.

Key Principles Of Agile Development

At its core,

Agile methodologies value individuals and their interactions over following strict processes and tools.

“

This means that communication and collaboration between team members are prioritized to ensure everyone is working towards the same goals.

These processes are governed by a set of guiding principles that help the development team to create software that is tailored to the customer’s needs while ensuring high-quality delivery.

• Customer satisfaction is the top priority.
  The goal of Agile development is to create software that meets the needs of the customer. This means that the customer is involved in every step of the process, from planning to testing.
• Teamwork is essential.
  Cross-functional teams that work together to complete tasks are a core principle. This means that everyone on the team has a role to play, and everyone works together to achieve the same goal.
• Flexibility is key.
  Everything about Agile development is designed to be flexible and adaptable. This means that the team can change course if needed, and the development process can be adjusted based on feedback from the customer.
• Communication is critical.
  Open and honest communication between team members and the customer is encouraged. Everyone should feel empowered to share their ideas, concerns, and feedback.
• Iterative development.
  Agile development involves breaking the development process down into smaller, more manageable pieces. By working on one sprint at a time, the team can make progress quickly and efficiently.
• Continuous improvement.
  This means that the team is always looking for ways to improve the development process and make it more effective.

Prioritizing Collaboration And Communication

Effective collaboration and communication are crucial in any team-oriented project, and Agile methodologies place a particular emphasis on these values.

Prioritizing collaboration and communication ensures that everyone involved in the project is working towards the same goals and that any issues or concerns can be addressed quickly and effectively.

“

When collaboration and communication are prioritized, team members are encouraged to share their expertise and insights, which can lead to more creative and innovative solutions.

In an Agile environment, team members work closely together, and there is often a high level of interdependence between different areas of the project. If one team member is struggling or working in isolation, it can have a ripple effect on the rest of the team and ultimately impact the success of the project. Collaborating with other developers can help identify issues in the code that may not have been noticed otherwise. For example, another developer may notice a potential security vulnerability or identify a bug the original developer missed. Here are some of the key ways to ensure this:

• Encourage cross-functional teams.
  Bringing together individuals with different skills and expertise can lead to stronger communication between business owners and the technical team that produces the product. I remember a time when I was working on a project with my team, and we divided the work based on each person’s strengths. This approach allowed everyone to contribute their best work to the project.
• Break down silos.
  Silos refer to a situation where different teams or departments within an organization work in isolation from each other, without much communication or collaboration. Silos can lead to several negative outcomes, such as a lack of transparency, duplication of effort, and a slower development process. Eliminating barriers between individuals and teams would help foster collaboration by allowing individuals to share their skills and expertise.
• Hold regular check-ins and feedback sessions.
  Scheduling consistent check-ins and feedback sessions can help ensure everyone is aligned on priorities and goals. I’ve found that this approach helps keep everyone motivated and focused on the end goal.
• Use proper communication channels.
  Utilizing appropriate communication channels can increase the transparency and visibility of the project. In my experience, using tools like instant messaging (like Slack) and video conferencing (like Zoom) has helped facilitate collaboration and information sharing, particularly in a remote team environment.
• Hold dedicated “Ask Me Anything”(AMA) sessions.
  AMA sessions can help frontline managers understand the rationale behind the approach and become comfortable with empowering their teams and giving up control. I remember a time when my team participated in one of these sessions, and it helped us better understand the benefits of Agile methodology because it put everyone on the same page and made everyone more confident in the overall direction.

Failing to prioritize collaboration and communication can have serious consequences for an Agile project. Miscommunications and misunderstandings can lead to delays, missed deadlines, and even project failure. Team members may become demotivated or disengaged if they feel they are working in isolation or not being heard. In the worst-case scenario, the lack of collaboration and communication can lead to a breakdown in the project team, which can be difficult to recover from.

Refactoring And Code Reviews

Refactoring refers to the process of improving the internal structure of code without changing its external behavior. It is done to enhance code readability, maintainability, and performance. On the other hand, code review is the process of examining code to identify issues or defects that may affect its quality, security, or functionality.

Refactoring

Refactoring is the process of restructuring existing code without changing its external behavior. It should be done frequently in Agile projects — often in the middle of a sprint — to keep the codebase clean and avoid technical debt. Here are some steps on how to carry out refactoring in Agile:

• Identify the parts of the codebase that need refactoring.
• Discuss with the team why refactoring is necessary and the benefits it can bring.
• Prioritize the refactoring tasks based on their impact on the project.
• Break down the refactoring tasks into small, manageable chunks.
• Refactor the code while ensuring that it still passes all the tests.
• Get feedback from the team and stakeholders on the refactored code.

Code Review

A code review is a process of systematically reviewing the code written by other team members. It aims to improve the code’s quality, find bugs, and ensure it adheres to coding standards. A code review should be done early and often in Agile projects to ensure that the codebase is always of high quality. Here are some steps on how to carry out a code review in Agile:

• Assign a team member to review the code written by another team member.
• Review the code for readability, maintainability, and adherence to the coding standards.
• Provide feedback on the code and suggest improvements.
• Discuss the feedback with the code author and come up with a plan to address the issues.
• Make sure that the code changes are reviewed again after they are implemented to ensure that they meet the desired quality standards.

Overall, refactoring and code review are essential practices in Agile methodologies that help ensure the code is of high quality and meets the customer’s needs. By incorporating these practices into the development process, the team can improve collaboration, reduce technical debt, and deliver high-quality software faster.

Agile Compared To Traditional Workflows

Traditional workflows refer to development methodologies that follow a linear, sequential process, where each phase of development must be completed before moving on to the next phase, with a focus on ensuring that all requirements are clearly defined before development begins. Some examples of traditional workflows include the Waterfall model, the V-model, the Spiral model, and the Rational Unified Process. These methodologies are often referred to as “plan-driven” or “heavyweight” methodologies, as they involve extensive planning and documentation upfront, with less flexibility for changes during the development process.

Take a look at the Waterfall model, for example. This model, also known as the “classic life cycle model,” is based on a series of well-defined phases, with each phase depending on the successful completion of the previous one.

The phases of the Waterfall model typically include requirements gathering, design, implementation, testing, deployment, and maintenance. Once one phase is completed, the next phase begins, and there is no going back to the previous phase. This means that the Waterfall model follows a “top-down” approach, where each phase is dependent on the previous phase’s success. And, true to its name, the process resembles a waterfall.

One of the key characteristics of the Waterfall model is that it is heavily focused on planning and documentation. Before the development team begins coding, the project requirements and design specifications must be fully documented. This documentation is then used to guide the entire development process.

While the Waterfall model has been a popular development process for many years, it has several limitations. For instance, the linear and sequential nature of the model can be inflexible, making it challenging to incorporate changes and feedback throughout the development process. It also puts a lot of emphasis on up-front planning, which can be time-consuming and costly. Plus, we all know that even the best-laid plans don’t always go right.

As a result, many software development teams have shifted towards using Agile methodologies instead of the Waterfall model. Agile methodologies offer greater flexibility and collaboration, enabling teams to adjust their approach as they gather feedback and insights throughout the development process.

Here are some key differences between Agile methodologies and traditional workflows:

While traditional workflows may have some advantages, such as providing a clear roadmap and a structured approach, I believe Agile methodologies are better suited for today’s fast-paced, ever-changing software development landscape. Agile methodologies offer the flexibility and adaptability necessary to meet changing requirements and deliver high-quality software products.

Conclusion

In conclusion, adopting Agile methodologies can have a significant positive impact on code quality. By prioritizing collaboration and communication, implementing test-driven development, and regularly conducting code reviews and refactoring, development teams can ensure that the code they produce is high-quality, maintainable, and meets the customer’s needs.

It’s worth noting that Agile methodologies are not without their challenges, such as the potential for scope creep. You can imagine how a flexible process that encourages frequent collaboration and feedback could lead to a project growing more legs than it needs. That said, Organizations that have adopted Agile methodologies report higher levels of customer satisfaction, faster time-to-market, and overall improved project success rates. As the industry continues to evolve, it’s likely that we will see more and more organizations embrace Agile methodologies to improve code quality and project outcomes.

Further Reading On SmashingMag

• “Why Collaborative Coding Is The Ultimate Career Hack”, Bobby Sebolao
• “Beyond Sprint 0: An Alternative For Integrating Teams”, Shamsi Brinn
• “Adapting Agile For Part-Time Teams”, Philip Kiely
• “Bringing A Healthy Code Review Mindset To Your Team”, Sandrina Pereira
• “Bringing A Better Design Process To Your Organization”, Eric Olive

(gg, yk)

We all have a role to play in the building of a website. Designers create beautiful and interactive interfaces. Copywriters create messaging that gets visitors to take notice and action. Developers bring it all together with code.

But there’s one piece of the puzzle that can’t be handed off to just one person. And that’s SEO.

If you’re building websites for clients and they’re expecting impressive outcomes in the end (i.e. high conversion rates), SEO has to be part of your process. You can’t just leave it in the hands of your writer or a dedicated SEO and assume that’s enough.

Google is a demanding overlord and we must appease it if we want our websites to reach the top of search. And what that means is taking a well-rounded approach to SEO throughout the lifecycle of the website design and development process.

If you haven’t accounted for this already or you want to make sure you’ve covered all the bases in what you currently do, this post is for you. I’m going to run through when and how SEO needs to enter the picture in your workflow. In addition, I’ve included an SEO checklist at the bottom of this post that you and your team can adapt to your workflow.

Where Does SEO Belong In Your Web Design Process?

SEO should be something you’re always thinking about and planning for, from the prospecting phase all the way to the launch date.

SEO During The Proposal Phase

When you talk to a prospect about what they need your help for, they’re going to focus on the website itself.

“I need a website so I can sell my products online/grow my presence/get new customers.”

But that’s not really what they’re asking for. What they want is a website to help their business get found in Google and to convert visitors, which requires something more complex from you than just slapping together some copy and designs.

You know that the website needs to be optimized for search if the website is to do what the client needs it to. Because of this, it’s going to impact things like cost, timeline and process flow. All of these details should be mapped out on your end as you prepare the proposal.

As for what you actually tell your clients? This is where things get tricky.

You have to somehow address SEO with your prospect 1) to set the right expectations and 2) to justify what you’re about to propose to them in terms of scope and cost. The only problem is, some clients might know the term “SEO”, but they don’t really understand what it entails.

The conversation could quickly devolve into something like this:

You: [You explain the details of your design offering and mention that SEO is part of it.]

Client: “Oh, great. I have a list of 20 keywords I want included in every page.”

You: “Well, that’s not really what search engine optimization is. If you want your website to perform well, you need to pay attention to things like caching, security and mobile-first design.”

Client: “What are you talking about? Cashing? What even is that? I thought you said you do SEO. I want to rank for these 20 keywords.”

It’s your job to get clients the results they need, not to try and explain to them the technicalities of how you do it. That’s why they’re paying you to do this, after all. So, here’s what I’d recommend for your proposal and early discussions with clients:

First, let your website do all the talking about SEO like UPQODE’s does:

This would allow you to clearly spell out the kinds of SEO you provide (which will also help those SEO-minded clients find you in the first place). It’s okay to include technical terms here so long as you briefly explain what each is in layman’s terms:

What I like about this approach is that it enables you to say “We’re going to do X, Y and Z” while framing it in a light that the client actually understands. In this case, what you’d really be saying is “We handle all the technical stuff so your site’s visibility grows in search and, consequently, you get more traffic.”

This is how you should be talking to your prospects and laying out SEO-related details in your proposals and contracts, too.

In other words, don’t delve too much into your SEO tasks. Instead, just spell out the benefits. For example:

• Responsive web design that looks great on all devices.
• Web pages that load in three seconds or less for optimal visitor experiences.
• Tightened up security to keep all your business data as well as your visitors’ data private.
• Content that’s easy for humans to read and even easier for Google bots to understand.
• Custom-built user pathways that turn visitors into customers in no time.

The goal is to get them onboard with your search-optimized web design services and perhaps even ongoing maintenance and support afterwards. To do that, you have to clearly convey the benefits without getting them wrapped up in the technicalities of SEO.

SEO During The Setup And Planning Phase

In the early phases of an approved project, SEO shouldn’t be far from your mind. While you might not actively be working on optimizations yet, it’s a good idea to make sure the baseline you’re working from won’t cause more work for you down the line.

Here are some things to keep in mind:

Review the Client’s Design Assets

You probably ask clients to provide you with assets, logins and even copy before a project gets underway. While this is mainly to protect yourself from scope creep, it can also come in handy for SEO.

Say your client hands over logos and other image assets that are really low quality or look super outdated. The earlier you have these assets in hand, the sooner you can let them know that they need to be replaced if they want people to take their website seriously.

If visitors don’t like the look of a website, they’re going to abandon it without fail and that high bounce rate is going to kill the site’s ranking. So, make sure your clients don’t stand in the way of the results you’re trying to help them achieve.

Work in Tandem with the Copywriter

Even if a professional copywriter is creating the content for your website, if you’re not working closely with them from the start, there could be problems.

Web design agencies often debate the merits of content-first website development vs. design-first. The truth is, they should be created together. If you don’t, you put the whole project at risk.

For starters, a writer and designer working in isolation are bound to come up with different ways to handle style and layout. But if you establish guidelines from the get-go (which you can easily do with wireframes), you can avoid any disjoint in how the copy and design are created.

You’re going to wireframe any website you build anyway, so why not provide a copy of it to the writer so you two can be on the same page from the beginning? Even better, why not collaborate with the writer? They might not know design techniques or best practices, but they can certainly provide insight on things like optimal text length, the priority of certain sales or marketing messages and so on.

Then, there’s the matter of optimizing copy for search. Ideally, you’d want to work with a copywriter who can do the following:

• Create actionable messaging and CTAs,
• Naturally weave target keywords into the copy,
• Write for user intent,
• Write in HTML,
• Create copy that’s both readable and scannable,
• Build a system of internal links from page to page,
• Create meta tags and optimize URLs for search,
• Write alt tags for images.

The more of this that gets built into the copy from the get-go, the less back-and-forth you have to do with them later. It’ll also spare you the trouble of trying to fix this on your own (which you shouldn’t attempt to do).

Design for Sales Funnels

In order to increase conversions on a site, you should be designing sales funnels into them. But sales funnels aren’t just a series of steps that you lay down for visitors on the website.

It all begins with understanding user intent outside of the site. If you know what draws visitors to your site from search engines and social media, you can design your metadata and landing pages to align with that intent.

Again, if you do the research and planning upfront with SEO in mind, you’ll have less cleanup work to do later.

SEO During Design And Development

This, obviously, is the most important and labor-intensive stage for you. And while it’s easy to get wrapped up in designing and coding, it’s important not to lose sight of SEO here.

What I’d recommend is creating a universal SEO checklist you can use from project to project. If you account for every possible optimization now, you can take the guesswork out of SEO. Plus, a checklist allows you to become better acquainted with everything that needs to be done, which will enable you to find more efficient ways of building search optimizations into your process.

To help you along, I’ve created the following SEO checklist. Feel free to copy and use for your own needs:

• Technical SEO
• Web hosting with 99.9%+ uptime
• Domain with clean web history
• SSL certificate installed
• Firewall implemented
• Caching enabled (page, browser, object, etc.)
• Image compression and resizing (in-house system or automated)
• Automated backups
• Google Analytics account connected
• Google Analytics goal tracking, ecommerce tracking and other special tracking enabled
• Google Search Console account connected
• XML sitemap set up and submitted to Google
• Separate sitemap submitted for images and for videos
• Robots.txt set up
• Schema.org markup (when relevant) written

• Design SEO
• Information architecture mapped out
• Responsive web design
• Mobile-first web design
• 1 clear CTA per page
• Custom 404 page set up
• All links, buttons and forms tested and working

• On-page SEO
• 1 unique focus keyword per page
• Focus keyword density between 1-3%
• 50-60 character meta title including the focus keyword
• 150-160 character meta description including the focus keyword
• Short but descriptive slug including the focus keyword
• Error-free content
• At least 1 relevant internal link per page
• Featured image for each page
• Descriptive alt text for each image
• Header tags used (focus keyword included in at least 1)
• Headers appear every 300 words or so
• Sentences stretch no more than two lines
• Paragraphs stretch no more than five lines
• Duplicate content analysis
• Plagiarism check

• Local SEO
• Google My Business page set up
• Geo-specific keywords included
• Location-specific pages created (when relevant)
• Contact information provided (e.g. phone number, address, etc.)

• Ongoing SEO Support
• Web server uptime, speed and security analysis
• Page speed testing
• Security monitoring
• Google blacklist monitoring
• Keyword rank monitoring
• Broken link checking
• Software updates

A Few Notes

1. Anything that’s not relevant to the kinds of clients you serve or the kinds of services you offer, delete the row.
2. If there’s anything I’m missing, feel free to add it on (like if you specialize in e-commerce design and want to prep product pages to appear in Google Shopping results).
3. If you’re not comfortable checking the on-page SEO stuff, hand it off to a proofreader or editor (someone who didn’t do the copywriting).

For those of you looking for additional opportunities to make money, this SEO checklist can also be used to analyze an existing website and present a prospective client with a website redesign or optimization plan.

Wrapping Up

Keyword optimization and link building are only part of the SEO puzzle. As a web designer or developer, you have a huge contribution to make here as well. Whether it’s in the quality of code written on the backend, the way images are optimized or how well-secured the site is, these are the kinds of tasks you’re responsible for managing that no writer or SEO is going to or should handle. And, without these optimizations, Google and your visitors will fail to take notice of the site you worked so hard to build for them.

Further Reading

• Adding Search To Your Site In 15 Minutes
• When Friction Is A Good Thing: Designing Sustainable E-Commerce Experiences
• Improving The Double Diamond Design Process
• The Impact Of Agile Methodologies On Code Quality

(ra, il, mrn)

This article is mostly directed at you, dear Frontend Developer, who enjoys implementing user interfaces but struggles in aligning expectations with designers you work with. Perhaps you are referred to as the “UI Developer” or “UX Engineer.” Regardless of the title that you carry around, your job (and as well as mine) consists of more than breathing life into design files. We are also responsible for filling the gap between the design and development workflows. However, when crossing that bridge, we are faced with multiple challenges.

Today, I’d like to share with you practical tips that have helped me to collaborate more efficiently with designers in the past years.

I believe it’s our job, as UI Developers, to not only help designers in their journey to learn how the web works, but also to get to know their reality and learn their language.

Understanding UX Designers’ Background

Most of the UX designers (also referred to as Web Designers or Product Designers) out there took their first steps in the design world through tools like Photoshop and Illustrator. Perhaps they were Graphic Designers: their main goal was to create logos and brand identities and to design layouts for magazines. They could also have been Marketing Designers: printing billboards, designing banners and creating infographics.

This means that most UX designers spent their early days designing for print, which is a totally different paradigm from their current medium, the screen. That was their first big challenge. When dealing with print, designers cared about pixel alignment, but on a fixed area (paper). They didn’t have to contend with a dynamic layout (screens). Thinking about text breaking or states of interactions was simply not part of their job either. Designers also had complete freedom over colors, images, and typography without performance constraints.

Fortunately, there have been many efforts from the self-taught UX designers community, to teach development fundamentals, discuss whether designers should learn to code and understand how to best perform hand-off to developers. The same held true for the development side as well (more about that in a minute). However, there is still friction happening between the two fields.

On the one hand, designers complaining each time an implementation doesn’t match their designs or feeling misunderstood when those are rejected by the developers without a clear explanation. On the other hand, developers might take for granted that designers know something technical when that might not be true. I believe we can all do better than that.

Embracing A New Way Of Thinking

The websites and apps that we are building will be displayed on a wide range of screen sizes. Each person will use them on multiple devices. Our common goal is to create a familiar experience across their journeys.

When we, as developers, think that designers are being picky about pixel alignments, we need to understand why that is. We need to recognize that it’s beyond fidelity and consistency. It’s about the sum of all the parts working together. It’s cohesion. We have to embrace it and do our best to accomplish it. Learning the fundamentals of design principles is a good starting point. Understand the importance of selecting the right colors, how the hierarchy works, and why white space matters.

Note: There’s an online course known as “Design for Developers” and a book called “Refactoring UI” — both are great to get you started. With these, you’ll be able to implement user interfaces with a sharp eye for detail and gain significant leverage when communicating with designers.

Magnifying Your Designers’ Awareness

You might take for granted that designers know the web as much as you do. Well, they might not. Actually, they don’t have to! It’s our responsibility, as developers, to keep them updated with the current state of the web.

I’ve worked with the two sides of this spectrum: Designers who think that anything can be built (such as complex filters, new scroll behaviors or custom form inputs) without giving browser compatibility a thought. Then, there are designers with assumptions about the “low limitations of the web” and just assume by themselves that something is impossible to implement. We need to show them the true possibilities of web design and not let the limitations hold back their skills.

Teach Them Code, Not How To Code

This seems contradictory but bear with me: knowing how to code is at the core of a developer’s job. We work in a fast-paced industry with new stuff popping up every day. It would be a hypocritical request from us to demand designers to learn how to code. However, we can help them to understand code.

Sit next to the designer you work with for 15 minutes and teach them how they can see for themselves whether the specs of an element are correct and how to change them. I find Firefox Page Inspector remarkably user-friendly for this.

Nowadays, it’s a joy to visualize layouts, debug CSS animations and tweak typography. Show them a ready-to-use code playground like Codepen for them to explore. They don’t need to know all CSS specs to understand how the layout paradigm works. However, they need to know how elements are created and behave in order to empower their daily work.

Include Designers In The Development Process

Invite designers to join you in the stand-up meeting, to be part of the QA process and to sit down with you while you refine visual details in your implementations. This will make them understand the constraints of the web and, soon enough, they’ll recognize why a feature takes time to implement.

Ask Designers To Include You In Their Design Process

You’ll realize that they do much more than “make things pretty”. You’ll learn more about the research process and how user testing is done. You’ll discover that for each design proposal they show to you, several other studies were previously dropped. When designers request a change, ask the reason behind it, so you can learn more about the decisions being made. Ultimately, you’ll start to understand why they are picky about white space and alignments, and hopefully, soon you’ll be too!

I find it crucial to treat frontend development as a core part of the design process, and design as a core part of the development process. Advocating a mindset where everyone gets the chance to be involved in the design and development cycle will help us all to better understand each other’s challenges and to create great experiences as well.

We May Use Different Tools, But We Must Speak The Same Language

Now that we are starting to understand each other’s workflow a little better, it’s time for the next step: to speak the same language.

Looking Beyond The Code Editor

Once you start to pay attention to your surroundings, you’ll be better equipped to tackle problems. Get to know the business better and be willing to listen to what designers have to say. That will make you a team member with richer contributions to the project. Collaborating in areas beyond our expertise is the key to creating meaningful conversations and mutual trust.

Using UI Systems As A Contract

Ask designers to share their design system with you (and if they don’t use one, it’s never too late to start). That will save you the bother of handpicking the colors used, figuring out margins or guessing a text style. Make sure you are familiar with the UI System as much as they are.

You might already be familiar with the component-based concept. However, some designers might not perceive it in the same way as you do. Show them how components can help you to build user interfaces more efficiently. Spread that mindset and also say bye-bye to similar-but-not-equal-names: header vs hero, pricing info vs price selector. When a piece of the user interface (a.k.a ‘a component’) is built, stride to use the same names so they can be reflected in both design and code files. Then, when someone says, “We need to tweak the proposal invitation widget,” everyone knows exactly what is being talked about.

Acknowledging The Real Source Of Truth

Despite the fact that the user interface is first created in the design files, the real source of truth is on the development side. At the end of the day, it is what people actually see, right? When a design is updated, it’s a good idea to leave a side note about its development status, especially in projects where a large number of people are involved. This trick helps to keep the communication smooth, so nobody (including you) wonders: “This is different from the live version. Is it a bug or hasn’t so-and-so been implemented just yet?”

Keeping The Debt Under Control

So, you know all about technical debt — it happens when the cost to implement something new is high because of a shortcut we took in the past to meet a deadline. The same can happen on the design side too and we call it design debt.

You can think about it like this: The higher the UX & UI inconsistency, the higher the debt (technical and design). One of the most common inconsistencies is in having different elements to represent the same action. This is why bad design is usually reflected in bad code. It’s up to all of us, both as designers and developers, to treat our design debt seriously.

Being Accessible Doesn’t Mean It Has To Be Ugly

I’m really pleased to see that both we, as developers and designers, are finally starting to bring accessibility into our work. However, a lot of us still think that designing accessible products is hard or limits our skills and creativity.

Let me remind you that we are not creating a product just for ourselves. We are creating a product to be used by all the people, including those who use the product in different ways from you. Take into account how individual elements can be more accessible while keeping the current userflows clear and coherent.

For example, if a designer really believes that creating an enhanced select input is necessary, stand by their side and work together to design and implement it in an accessible way to be used by a wide range of people with diverse abilities.

Giving Valuable Feedback To Designers

It’s unavoidable that questions will pop up when going through the designs. However, that’s not a reason for you to start complaining about the designers’ mistakes or about their ambitious ideas. The designers are not there to drive you mental, they just don’t always intuitively know what you need to do your job. The truth is that, in the past, you didn’t know about this stuff either, so be patient and embrace collaboration as a way of learning.

The Earlier The Feedback, The Better

The timing for feedback is crucial. The feedback workflow depends a lot on the project structure, so there isn’t a one-size-fits-all solution for it. However, when possible, I believe we should aim for a workflow of periodic feedback — starting in the early stages. Having this mindset of open collaboration is the way to reduce the possibility of unexpected big re-iterations later in the road. Keep in mind that the later you give the designer your first feedback, the higher will be the cost for them to explore a new approach if needed.

Explain Abstract Ideas In Simple Terms

Remember when I said that performance was not a concern of the designers’ previous jobs? Don’t freak out when they are not aware of how to create optimized SVGs for the web. When faced with a design that requires a lot of different fonts to be loaded, explain to them why we should minimize the number of requests, perhaps even take advantage of Variable Fonts. Asides from loading faster, it also provides a more consistent user experience. Unless designers are keen to learn, avoid using too many technical terms when explaining something. You can see this as an opportunity of improving your communication skills and clarifying your thoughts.

Don’t Let Assumptions Turn Into Decisions

Some questions about a design spec only show up when we get our hands dirty in the code. To speed things up, we might feel tempted to make decisions based on our assumptions. Please, don’t. Each time you turn an assumption into a decision, you are risking the trust that the design team puts on you to implement the UI. Whenever in doubt, reach out and clarify your doubts. This will show them that you care about the final result as much as they do.

Don’t Do Workarounds By Yourself

When you are asked to implement a design that is too hard, don’t say “It’s impossible” or start to implement a cheap alternative version of it by yourself. This immediately causes friction with the design team when they see their designs were not implemented as expected. They might react angrily, or not say anything but feel defeated or frustrated. That can all be avoided if we explain to them why something it’s not possible, in simple terms and suggest alternative approaches. Avoid dogmatic behaviors and be open to collaborating on a new solution.

Let them know about the Graceful Degradation and Progressive Enhancement techniques and build together an ideal solution and a fallback solution. For example, we can enhance a layout from flexbox to CSS Grid. This allows us to respect the core purpose of a feature and at the same time make the best use of web technologies.

When it comes to animations, let’s be real: deep down you are as thrilled to implement the next wow animation as much as the designers are to create it. The difference between us and them is that we are more aware of the web’s constraints. However, don’t let that limit your own skills! The web evolves fast, so we must use that in our favor.

The next time you are asked to bring a prototype to life, try not to reject it upfront or do it all by yourself. See it as an opportunity to push yourself. Animations are one of the pickiest parts of web development, so make sure to refine each keyframe with your designer — in person or by sharing a private synced link.

Think Beyond The Ideal State — Together

Here’s the thing: it’s not all about you. One of the designers’ challenges is to really understand their users and present the designs in the most attractive way to sell to the Product Manager. Sometimes they forget about what’s beyond the ideal state and developers forget it too.

In order to help avoid these gaps from happening, align with designers the scenario requirements:

• The worst-case scenario
  A scenario where the worst possibilities are happening. This helps designers to say no to fixed content and let it be fluid. What happens if the title has more than 60 characters or if the list is too long? The same applies to the opposite, the empty scenario. What should the user do when the list is empty?
• Interaction states
  The browser is more than hovering and clicking around. There are a bunch of states: default, hover, focus, active, disable, error… and some of them can happen at the same time. Let’s give them the proper attention.
• The loading state
  When building stuff locally, we might use mocks and forget that things actually take time to load. Let designers know about that possibility too and show them that are ways to make people perceive that things don’t take that long to load.

Taking into consideration all these scenarios will save you a lot of time going back and forth during the development phase.

Note: There’s a great article by Scott Hurff about how to fix bad user interfaces that will take us a step closer to an accessible product.

Embrace Change Requests

Developers are known for not being too happy about someone finding a bug in their code — especially when it’s a design bug reported by a designer. There are a lot of memes around it, but have you ever reflected how those bugs can compoundingly rot both the quality of the experience as well as your relationship when these design bugs are casually dismissed? It happens slowly, almost like falling asleep. Bit by bit, then all at once. Designers might start out saying, “It’s just a tiny little detail,” until the indifference and resentment builds up and nothing is said. The damage has then already been done.

This situation is two-fold: both to your peers and to your work. Don’t let that happen. Work on what’s coloring your reaction. A designer being ‘picky’ can be inconvenient, but it can also be an engineer’s shallow interpretation of attentiveness and enthusiasm. When someone tells you that your implementation is not perfect (yet), put your ego aside and show them how you recognize their hard work in refining the final result.

Go Off The Record Once In A While

We all have tasks to deliver and roadmaps to finish. However, some of the best work happens off the record. It won’t be logged into the TO DO board and that’s okay. If you find a designer you have a rapport with, go sneak into their workspace and explore together new experiments. You never know what can come from there!

Conclusion

When you are willing to learn from the design team, you are also learning different ways of thinking. You’ll evolve your mindset of collaboration with other areas out of your experience while refining your eye for creating new experiences. Be there to help and be open to learning, because sharing is what makes us better.

This article wouldn’t be possible without the feedback of many great people. I want to gratefully thank to the designers Jasmine Meijer and Margarida Botelho for helping me to share a balanced perspective about the misunderstandings between designers and developers.

Related Reading on SmashingMag:

• “Design For Developers” by Mason Gentry
• “Working Together: How Designers And Developers Can Communicate To Create Better Projects” by Rachel Andrew
• “How Frontend Developers Can Help To Bridge The Gap Between Designers And Developers” by Stefan Kaltenegger
• “Which Podcasts Should Web Designers And Developers Be Listening To?” by Ricky Onsman

(ra, yk, il)

A ‘code review’ is a moment in the development process in which you (as a developer) and your colleagues work together and look for bugs within a recent piece of code before it gets released. In such a moment, you can be either the code author or one of the reviewers.

When doing a code review, you might not be sure of what you are looking for. On the other side, when submitting a code review, you might not know what to wait for. This lack of empathy and wrong expectations between the two sides can trigger unfortunate situations and rush the process until it ends in an unpleasant experience for both sides.

In this article, I’ll share how this outcome can be changed by changing your mindset during a code review:

• As a team
• As an author
• As a reviewer

👩‍💻👨‍💻 Working As A Team

Foster Out A Culture Of Collaboration

Before we start, it’s fundamental to understand the value of why code needs to be reviewed. Knowledge sharing and team cohesion are beneficial to everyone, however, if done with a poor mindset, a code review can be a huge time consumer with unpleasant outcomes.

The team attitude and behavior should embrace the value of a nonjudgmental collaboration, with the common goal of learning and sharing — regardless of someone else’s experience.

Include Code Reviews In Your Estimations

A complete code review takes time. If a change took one week to be made, don’t expect the code review to take less than a day. It just doesn’t work like that. Don’t try to rush a code review nor look at it as a bottleneck.

Code reviews are as important as writing the actual code. As a team, remember to include code reviews in your workflow and set expectations about how long a code review might take, so everyone is synced and confident about their work.

Save Time With Guidelines And Automatization

An effective way to guarantee consistent contributions is to integrate a Pull Request template in the project. This will help the author to submit a healthy PR with a complete description. A PR description should explain what’s the change purpose, the reason behind it, and how to reproduce it. Screenshots and reference links (Git issue, design file, and so on) are the final touches for a self-explanatory submission.

Doing all of this will prevent early comments from reviewers asking for more details. Another way of making code reviews seem less nitpicky is to use linters to find code formatting and code-quality issues before a reviewer even gets involved. Whenever you see a repetitive comment during the review process, look for ways to minimize it (being with better guidelines or code automatization).

Stay A Student

Anyone can do a code review, and everyone must receive a code review — no matter the seniority level. Receive any feedback gratefully as an opportunity to learn and to share knowledge. Look at any feedback as an open discussion rather than a defensive reaction. As Ryan Holiday says:

“An amateur is defensive. The professional finds learning (and even, occasionally, being shown up) to be enjoyable; they like being challenged and humbled, and engage in education as an ongoing and endless process. (...)”

— Ryan Holiday, Ego Is the Enemy

Stay humble because the second you stop being a student, your knowledge becomes fragile.

The Art Of Selecting Reviewers

In my opinion, picking the reviewers is one of the most important decisions for an effective and healthy code review as a team.

Let’s say your colleague is submitting a code review and decides to tag “everyone” because, unconsciously, she/he might want to speed up the process, deliver the best code possible or making sure everyone knows about the code change. Each one of the reviewers receives a notification, then opens the PR link and sees a lot of people tagged as reviewers. The thought of “someone else will do it” pops up in their minds, leading to ignore the code review and close the link.

Since nobody started the review yet, your colleague will remind each one of the reviewers to do it, i.e. creating pressure on them. Once the reviewers start to do it, the review process takes forever because everyone has their own opinion and it’s a nightmare to reach a common agreement. Meanwhile, whoever decided to not review the code, is then spammed with zillions of e-mail notifications with all of the review comments, thus creating noise in their productivity.

This is something I see happening more than I’d like: Pull Requests with a bunch of people tagged as reviewers and ending, ironically, in a non-productive code review.

There are some common effective flows when selecting the reviewers: A possible flow is to pick two to three colleagues who are familiar with the code and ask them to be reviewers. Another approach, explained by Gitlab team is to have a chained review flow in which the author picks one reviewer who picks another reviewer until at least two reviewers agree with the code. Regardless of the flow you choose, avoid having too many reviewers. Being able to trust your colleagues’ code’s judgment is the key to conduct an effective and healthy code review.

Have Empathy

Spotting pieces of code to improve is just a part of a successful code review. Just as important is to communicate that feedback in a healthy way by showing empathy towards your colleagues.

Before writing a comment, remember to put yourself in the other people’s shoes. It’s easy to be misunderstood when writing, so review your own words before sending them. Even if a conversation starts being ugly, don’t let it affect you — always stay respectful. Speaking well to others is never a bad decision.

Know How To Compromise

When a discussion isn’t solved quickly, take it to a personal call or chat. Analyze together if it’s a subject worth paralyzing the current change request or if it can be addressed in another one.

Be flexible but pragmatic and know how to balance efficiency (delivering) and effectiveness (quality). It’s a compromise to be made as a team. In these moments I like to think of a code review as an iteration rather than a final solution. There’s always room for improvement in the next round.

In-Person Code Reviews

Gathering the author and the reviewer together in a pair programming style can be highly effective. Personally, I prefer this approach when the code review involves complex changes or there’s an opportunity for a large amount of knowledge sharing. Despite this being an offline code review, it’s a good habit to leave online comments about the discussions taken, especially when changes need to be made after the meeting. This is also useful to keep other online reviewers up to date.

Learn From Code Review Outcomes

When a code review has suffered a lot of changes, took too long or has already had too many discussions, gather your team together and analyze the causes and which actions can be taken from it. When the code review is complex, splitting a future task into smaller tasks makes each code review easier.

When the experience gap is big, adopting pair programming is a strategy with incredible results — not only for knowledge sharing but also for off-line collaboration and communication. Whatever the outcome, always aim for a healthy dynamic team with clear expectations.

📝 As An Author

One of the main concerns when working on a code review as an author is to minimize the reviewer’s surprise when reading the code for the first time. That’s the first step to a predictable and smooth code review. Here’s how you can do it.

Establish Early Communication

It’s never a bad idea to talk with your future reviewers before coding too much. Whenever it’s an internal or external contribution, you could do a refinement together or a little bit of pair programming at the beginning of the development to discuss solutions.

There’s nothing wrong in asking for help as a first step. In fact, working together outside the review is a first important step to prevent early mistakes and guarantee an initial agreement. At the same time, your reviewers get aware of a future code review to be made.

Follow The Guidelines

When submitting a Pull Request to be reviewed, remember to add a description and to follow the guidelines. This will save the reviewers from spending time to understand the context of the new code. Even if your reviewers already know what it is about, you can also take this opportunity as a way to improve your writing and communication skills.

Be Your First Reviewer

Seeing your own code in a different context allows you to find things you would miss in your code editor. Do a code review of your own code before asking your colleagues. Have a reviewer mindset and really go through every line of code.

Personally, I like to annotate my own code reviews to better guide my reviewers. The goal here is to prevent comments related to a possible lack of attention and making sure you followed the contribution guidelines. Aim to submit a code review just as you would like to receive one.

Be Patient

After submitting a code review, don’t jump right into a new private message asking your reviewers to “take a look, it only takes a few minutes” and indirectly craving for that thumbs-up emoji. Trying to rush your colleagues to do their work is not a healthy mindset. Instead, trust your colleagues’ workflow as they trust you to submit a good code review. Meanwhile, wait for them to get back to you when they are available. Don’t look at your reviewers as a bottleneck. Remember to be patient because hard things take time.

Be A Listener

Once a code review is submitted, comments will come, questions will be asked, and changes will be proposed. The golden rule here is to not take any feedback as a personal attack. Remember that any code can benefit from an outside perspective.

Don’t look at your reviewers as an enemy. Instead, take this moment to set aside your ego, accept that you make mistakes, and be open to learning from your colleagues, so that you can do a better job the next time.

👀 As A Reviewer

Plan Ahead Of Your Time

When you are asked to be a reviewer, don’t interrupt things right away. That’s a common mistake I see all the time. Reviewing code demands your full attention, and each time you switch code contexts, you are decreasing your productivity by wasting time in recalibrating your focus. Instead, plan ahead by allocating time slots of your day to do code reviews.

Personally, I prefer to do code reviews first thing in the morning or after lunch before picking any other of my tasks. That’s what works best for me because my brain is still fresh without a previous code context to switch off from. Besides that, once I’m done with the review, I can focus on my own tasks, while the author can reevaluate the code based on the feedback.

Be Supportive

When a Pull Request doesn’t follow the contribution guidelines, be supportive — especially to newcomers. Take that moment as an opportunity to guide the author to improve his/her contribution. Meanwhile, try to understand why the author didn’t follow the guidelines in the first place. Perhaps there’s room for improvement that you were not aware of before.

Check Out The Branch And Run It

While reviewing the code, make it run on your own computer — especially when it involves user interfaces. This habit will help you to better understand the new code and spot things you might miss if you just used a default diff-tool in the browser which limits your review scope to the changed code (without having the full context as in your code editor).

Ask Before Assuming

When you don’t understand something, don’t be afraid to say it and ask questions. When asking, remember to first read the surrounding code and avoid making assumptions.

Most of the questions fit in these two types of categories:

1. “How” Questions
   When you don’t understand how something works or what it does, evaluate with the author if the code is clear enough. Don’t mistake simple code with ignorance. There’s a difference between code that is hard to read and code that you are not aware of. Be open to learn and use a new language feature, even if you don’t know it deeply yet. However, use it only if it simplifies the codebase.
2. “Why” Questions
   When you don’t understand the “why”, don’t be afraid of suggesting to commenting the code, especially if it’s an edge case or a bug fix. The code should be self-explanatory when it comes to explaining what it does. Comments are a complement to explaining the why behind a certain approach. Explaining the context is highly valuable when it comes to maintainability and it will save someone from deleting a block of code that thought was useless. (Personally, I like to comment on the code until I feel safe about forgetting it later.)

Constructive Criticism

Once you find a piece of code you believe it should be improved, always remember to recognize the author’s effort in contributing to the project and express yourself in a receptive and transparent way.

• Open discussions.
  Avoid formalizing your feedback as a command or accusation such as “You should…” or “You forgot…”. Express your feedback as an open discussion instead of a mandatory request. Remember to comment on the code, not the author. If the comment is not about the code, then it shouldn’t belong in a code review. As said before, be supportive. Using a passive voice, talking in the plural, expressing questions or suggestions are good approaches to emphasize empathy with the author.

Instead of “Extract this method from here…” prefer “This method should be extracted…” or “What do you think of extracting this method…”

• Be clear.
  A feedback can easily be misinterpreted, especially when it comes to expressing an opinion versus sharing a fact or a guideline. Always remember to clear that right away on your comment.

Unclear: “This code should be….”

Opinion: “I believe this code should be…”

Fact: “Following [our guidelines], this code should be…”.

• Explain why.
  What’s obvious for you, might not be for others. It’s never too much explaining the motivation behind your feedback, so the author not only understands how to change something but also what’s the benefit from it.

Opinion: “I believe this code could be…”

Explained: “I believe this code could be (…) because this will improve readability and simplify the unit tests.”

• Provide examples.
  When sharing a code feature or a pattern which the author is not familiar with, complement your suggestion with a reference as guidance. When possible, go beyond MDN docs and share a snippet or a working example adapted to the current code scenario. When writing an example is too complex, be supportive and offer to help in person or by a video call.

Besides saying something such as “Using filter will help us to [motivation],” also say, “In this case, it could be something like: [snippet of code]. You can check [an example at Finder.js]. Any doubt, feel free to ping me on Slack.”

• Be reasonable.
  If the same error is made multiple times, prefer to just leave one comment about it and remember the author to review it in the other places, too. Adding redundant comments only creates noise and might be contra-productive.

Keep The Focus

Avoid proposing code changes unrelated to the current code. Before suggesting a change, ask yourself if it’s strictly necessary at that moment. This type of feedback is especially common in refactors. It’s one of the many trade-offs between efficiency and effectiveness that we need to make as a team.

When it comes to refactors, personally, I tend to prefer small but effective improvements. Those are easier to review and there’s less chance of having code conflicts when updating the branch with the target branch.

Set Expectations

If you leave a code review half-done, let the author know about it, so time expectations are under control. In the end, also let the author know if you agree with the new code or if you would like to re-review it once again later.

Before approving a code review, ask yourself if you are comfortable about the possibility of touching that code in the future. If yes, that’s a sign you did a successful code review!

Learn To Refuse A Code Review

Although nobody admits it, sometimes you have to refuse a code review. The moment you decide to accept a code review but try to rush it, the project’s quality is being compromised as well as your team’s mindset.

When you accept to review someone’s else code, that person is trusting your capabilities — it’s a commitment. If you don’t have the time to be a reviewer, just say no to your colleague(s). I really mean it; don’t let your colleagues wait for a code review that will never be done. Remember to communicate and keep expectations clear. Be honest with your team and — even better — with yourself. Whatever your choice, do it healthily, and do it right.

Conclusion

Given enough time and experience, doing code reviews will teach you much more than just technical knowledge. You’ll learn to give and receive feedback from others, as well as make decisions with more thought put into it.

Each code review is an opportunity to grow as a community and individually. Even outside code reviews, remember to foster a healthy mindset until the day it comes naturally to you and your colleagues. Because sharing is what makes us better!

Further Reading

• Working Together: How Designers And Developers Can Communicate To Create Better Projects
• Better Collaboration By Bringing Designers Into The Code Review Process
• Which Podcasts Should Web Designers And Developers Be Listening To?
• How To Craft The Perfect Web Developer Ré­su­mé

(ra, yk, il, mrn)

The goal of machine learning is to find patterns in data and use those patterns to make predictions. It can also give us a framework to discuss machine learning problems and solutions — as you’ll see in this article.

First, we will start with definitions and applications for machine learning. Then, we will discuss abstractions in machine learning and use that to frame our discussion: data, models, optimization models, and optimization algorithms. Later on in the article, we will discuss fundamental topics that underlie all machine learning methods and conclude with practical guidance for getting started with using machine learning. By the end, you should have an understanding of how to advance your practice and study of machine learning.

Let’s begin.

So, What Exactly Is Machine Learning?

Machine learning is generically a set of techniques to find patterns in data. Applications range from self-driving cars to personal AI assistants, from translating between French and Taiwanese to translating between voice and text. There are a few common applications of machine learning that already or could potentially permeate your day-to-day.

1. Detecting anomalies
   Recognize spikes in website traffic or highlight abnormal bank activity.
2. Recommend similar content
   Find products you may be looking for or even Smashing Magazine articles that are relevant.
3. Predict the future
   Plan the path of neighboring vehicles or identify and extrapolate market trends for stocks.

The above are few of many applications of machine learning, but most applications tie back to learning the underlying distribution of data. A distribution specifies events and probability of each event. For example:

• With 50% probability, you buy an item $5 or less.
• With 25% probability, you buy an item $5-$10.
• With 24% probability, you buy an item $10-100.
• With 1% probability, you buy an item > $100.

Using this distribution, we can accomplish all of our tasks above:

1. Detecting anomalies
   With a $100 purchase, we can confidently call this an anomaly.
2. Recommend similar content
   A purchase of $3 means we should recommend more items $5 or less.
3. Predict the future
   Without any prior information, we can predict that the next purchase will be $5 or less.

With a distribution of data, we can accomplish a myriad of tasks. In sum, one goal in machine learning is to learn this distribution.

Even more generically, our goal is to learn a specific function with particular inputs and outputs. We call this function our model. Our input is denoted x. Say our model, which accepts input x, is

f(x) = ax

Here, a is a parameter of our model. Each parameter corresponds to a different instance of our model. In other words, the model where a=2 is different from the model where a=3. In machine learning, our goal is to learn this parameter, changing it until we do “well.” How do we determine which values of a do “well”?

We need to define a way to evaluate our model, for each parameter a. To start, the output of f(x) is our prediction. We will refer to y as our label, meaning the true and desired output. With our predictions and our labels, we can define a loss function. One such loss function is simply the difference between our prediction and our label, |f(x) - y|. Using this loss function, we can then evaluate different parameters for our model. Picking the best parameter for our model is known as training. If we have a few possible parameters, we can simply try each parameter and pick the one with the smallest loss!

However, most problems are not as simple. What happens if there are an infinite number of different parameters? Let’s say all decimal values between 0 and 1? Between 0 and infinity? This brings us to our next topic: abstractions in machine learning. We will discuss different facets of machine learning, to compartmentalize your knowledge into data, models, objectives, and methods of solving objectives. Beyond learning the right parameter, there are plenty of other challenges: how do we break down a problem as complex as controlling a robot? How do we control a self-driving car? What does it mean to train a model that identifies faces? The section below will help you organize answers to these questions.

Abstractions

There are countless topics in machine learning — at various levels of specificity. To better understand where each piece fits in the larger picture, consider the following abstractions for machine learning. These abstractions compartmentalize our discussion of machine learning topics, and knowing them will make it easier for you to frame topics. The following classifications are taken from Professor Jonathan Shewchuck at UC Berkeley:

1. Application and Data
   Consider the possible inputs and the desired output for the problem.
   

   Questions: What is your goal? How is your data structured? Are there labels? Is it reasonable for us to extract output from the provided inputs?
   
   Example: The goal is to classify pictures of handwritten digits. The input is an image of a handwritten number. The output is a number.

   
   
2. Model
   Determine the class of functions under consideration.
   

   Questions: Are linear functions sufficient? Quadratic functions? Polynomials? What types of patterns are we interested in? Are neural networks appropriate? Logistic regression?
   
   Example: Linear regression

   
   
3. Optimization Problem
   Formulate a concrete objective in mathematics.
   

   Questions: How do we define loss? How do we define success? Should we apply additionally penalties to bias our algorithm? Are there imbalances in the data our objective needs to consider?
   
   Example: Find `x` that minimizes |Ax-b|^2

   
   
4. Optimization Algorithm
   Determine how you will solve the optimization problem.
   

   Questions: Can we compute a solution by hand? Do we need an iterative algorithm? Can we convert this problem to an equivalent but easier-to-solve objective, and solve that one?
   
   Example: Take derivative of the function. Set it to zero. Solve for our optimal parameter.

   
   

Abstraction 1: Data

In practice, collecting, managing, and packaging data is 90% of the battle. The data contains samples in which each sample is a specific realization of our input. For example, our input may generically be images of dogs. The first sample is specifically a picture of Maxie, my Bernese Mountain dog-chow chow mix at home. The second sample is specifically a picture of Charlie, a young corgi.

While training your model, it is important to handle your data properly. This means separating our data accordingly and not peeking prematurely at any set of data. In general, our data is split into three portions:

1. Training set
   This is the dataset you train your model on. The model may see this set hundreds of times.
2. Validation set
   This is the dataset you evaluate your model on, to assess accuracy and tune your model or method accordingly.
3. Test set
   This is the dataset you evaluate on to assess accuracy, once at the very end. Running on the test set prematurely could mean your model overfits to the test set as well, so run only once. We will discuss the notion of “overfitting” in more detail below.

Abstraction 2: Models

Machine learning methods are split into the following two:

Supervised Learning

In supervised learning, our algorithm has access to labeled data. Still, we explore the following two classes of problems:

• Classification
  Determine which of k classes {C_1, C_2, ... C_k} to which each sample belongs, e.g. “Which breed of dog is this?” The dog could be one of {"corgi", "bernese mountain dog", "chow chow"...}
• Regression
  Determine a real-valued output (which are often probabilities), e.g. “What is the probability this patient has neuroblastoma (eye cancer)?”

Unsupervised Learning

In unsupervised learning, our algorithm does not have access to labels, and we explore the following classes of problems:

• Clustering
  Cluster samples into k clusters. We do not have a label for the resulting clusters. “Which DNA sequences are most similar?”
• Dimensionality reduction
  Reduce the number of “unique” (linearly independent) features we consider. “What are common features of faces?”

Abstraction 3: Optimization Objective

Before discussing optimization objectives and algorithms, we’ll need an example to discuss. Least squares are the canonical example. We will restrict our attention to a specific form of least squares: Let us return to our grade-school problem of fitting a line to some points.

Let’s recall the equation of a line:

y = m * x + b

Assume we have such a line. This is the true underlying model.

Now, sample points from this line.

For each point, jiggle it a little bit. In other words, add noise, which is random perturbations. This noise is due to real-world processes.

This gives us our observed data. We will call these points (x_1, y_1), (x_2, y_2), (x_3, y_3).... This is the training data we are given to train a model on. We do not have access to the underlying line that generated this data (the original green line).

Say we have an estimate for the parameters of a line. In this case, the parameters are m and b. This gives us a predicted line, drawn in blue below.

We wish to evaluate our blue line, to see how accurate it is. To start, we use m and b to estimate y. We compute a set of ŷ values.

ŷ_i = m * x_i + b

The error for a single predicted ŷ_i and true y_i is simply

(ŷ_i−y_i)^2

Our total error is then the sum of squared differences, across all samples. This yields our loss.

∑(ŷ_i−y_i)^2

Presented visually, this is the vertical distance between our observed points and our predicted line.

Plugging in ŷ_i from above, we then have the total error in terms of m and b.

∑(m * x_i + b − y_i)^2

Finally, we want to minimize this quantity. This yields our objective function, abstraction 3 from our list of abstractions above.

min_{m, b} ∑(m * x_i + b−y_i)^2

The above states in mathematics that the goal is to minimize the loss by changing values of m and b. The purpose of this section was to motivate fitting a line of best of fit, a special case of least squares. Additionally, we showed examined the least squares objective. Next, we need to solve this objective.

Abstraction 4: Optimization Algorithm

How do we minimize this? We take the derivative with respect to m`, set to 0 and solve. After solving, we obtain the analytical solution. Solving for an analytical solution was our optimization algorithm, the fourth and final abstraction in our list of abstractions.

Note: The important portion of this section is to inform you that least squares have a closed form solution, meaning that the optimal solution for our problem can be computed, explicitly. To understand why this is significant, we need to examine a problem without a closed-form solution. For example, we could never solve x=logx for a standard base-10 logarithm. Try graphing these two lines, and we see that they never intersect. In which case, we have no closed-form solution. On the other hand, ordinary least squares have a closed-form — which is good news. For any problem reduced to least squares, we can then compute the optimal solution, given our data and assumptions.

Fundamental Topics

Before studying more methods, it is necessary to understand the undercurrents of machine learning. These will govern the initial study of machine learning:

Bias-Variance Tradeoffs

One of machine learning’s most dreaded evils is overfitting in which a model is too closely tailored to the training data. In the limit, the most overfit model will memorize the data. This might mean that if one does well on exam A, one repeats every detail for exam B — down to the duration of an inter-exam restroom trip and whether or not one used the urinal.

A related but less common evil is underfitting, where the model is not sufficiently expressive to capture important information in the data. This could mean that one looks only at homework scores to predict exam scores, ignoring the effects of reading notes, completing practice exams, and more. Our goal is to build a model that generalizes to new examples while making the appropriate distinctions.

Given these two evils, there are a variety of approaches to fighting both. One is modifying your optimization objective to include a term that penalizes model complexity. Another is tuning hyperparameters that govern either your objective or your algorithm, which may correspond to notions such as “training speed” or “momentum.” The bias-variance tradeoff gives us a precise way of defining and handling both overfitting and underfitting.

Maximum Likelihood Estimation (MLE) + Maximum A Posteriori (MAP)

Say we have ice cream flavors A, B, and C. We observe different recipes. Our goal is to predict which flavor each recipe produces.

One way to predict flavors based on recipes is to first estimate the following probability:

P(flavor|recipe)

Given this probability and a new recipe, how can we predict the flavor? Given a recipe, simply consider the probability of each of the flavors A, B, C.

P(flavor=A|recipe) = 0.4
P(flavor=B|recipe) = 0.5
P(flavor=C|recipe) = 0.1

Then, pick the flavor that has the highest probability. Above, flavor B has the highest probability, given our recipe. Thus, we predict flavor B. Restating the above rule in mathematics, we have:

argmax_{flavor} P(flavor|recipe)  # argmax means take the flavor that corresponds to the max value

However, the only information at our disposal is the reverse: the probability of some recipe given the flavor.

P(recipe|flavor)

For Maximum Likelihood Estimates, we make assumptions and find that the two values are proportional.

P(recipe|flavor) ~ P(flavor|recipe)

Since we’re only interested in the class with maximum probability P(flavor|recipe), we can simply find the class with maximum probability, for a proportional value P(recipe|flavor).

argmax_{flavor} P(recipe|flavor)

MLE offers the above objective as one way to predict, using the probability of data given the labels.

However, allow me to convince you that it’s reasonable to assume we have (x|y). We can estimate this from observed, real-world data. For example, say we wish to estimate the number of marbles each student in your class carries, based on the number of rubber ducks the student carries.

Each student’s number of rubber ducks is the data x, and the number of marbles she or he has is y. We will use this sample data below.

| x | y |
|---|---|
| 1 | 2 |
| 1 | 1 |
| 1 | 2 |
| 2 | 1 |
| 2 | 2 |
| 1 | 2 |

For every y, we can compute the number of x, given us P(x|y). For the first one, P(x=1|y=1), consider all of the rows where y=1. There are 2, and only one of them has x=1. Therefore, P(x=1|y=1) = 1⁄2. We can repeat this for all values of x and y.

P(x=1|y=1) = 1/2
P(x=2|y=1) = 1/2
P(x=1|y=2) = 3/4
P(x=2|y=2) = 1/4

Featurizations, Regularization

Least squares draw lines of best fit for us. Note that least squares can fit the model anytime the model is linear in its inputs x and outputs y.

Say m=1. We have the following equation:

y = x + b

However, what if we had data that doesn’t generally follow a line? Specifically, consider a set of data sampled along a circle. Recall that the equation for a circle is:

x^2 + y^2 = r^2

Can least squares fit this well? As it stands, no. The model is not linear in its inputs x and outputs y. Instead, the model above is quadratic in x and y. However, it turns out that we can use still use least squares, just with a modification. To accomplish this, we featurize our samples.

Consider the following: what if the input to our model was x_ = x^2 and y_ = y^2? Then, our model is trying to learn the following model.

x_ + y_ = r^2

Is this linear in the model’s input x_ and output y_? Yes. Note the subtlety. The current model is still quadratic in x,y but it is linear in x_,y_. This means that least squares can fit the data if we square x^2 and y^2 before training least squares.

More generally, we can take any non-linear featurization to apply least squares to labels that are non-linear in the features. This is a fairly powerful tool, known as featurization.

However, featurizations lead to more complex models. Regularization allows us to penalize model complexity, ensuring that we do not overfit the training data.

Conclusion

In this article, you’ve touched on major topics in the fundamentals of machine learning. Using the abstractions above, you now have a framework to discuss machine learning problems and solutions. Using the fundamental topics above, you now also have quintessential concepts to learn more about, giving you the necessary tools to evaluate risk and other concerns in a machine learning application.

Other Resources

We will continue to explore these topics in depth, both the undercurrents of machine learning and specific methods. In the interim, here are resources to further your study and exploration of machine learning:

• “Introduction to Machine Learning,” Machine Learning course CS189, UC Berkeley
• NumPy (for efficient linear algebra utilities)
• scikit-learn (for out-of-the-box machine learning methods)

Further Reading

• The Impact Of Agile Methodologies On Code Quality
• Crafting Experiences: Uniting Rikyu’s Wisdom With Brand Experience Principles
• Powerful Image Analysis With Google Cloud Vision And Python
• Using Friction As A Feature In Machine Learning Algorithms

(ra, il, mrn)

Smooth collaboration between developers and designers is something everyone aspires to, but it’s notoriously difficult. But with today’s advanced web, it's difficult — if not impossible — to build a truly great product without collaborating across disciplines. Because of the range of technologies required to build a product, the product can only truly succeed when all disciplines — developers and designers, content creators, and user experience strategists — are deeply involved from the early stages of the project. When this happens, all ends of what it takes to build a product come naturally together into a unified whole, and a thus great product.

Because of this, no one is really promoting waterfall processes anymore. Nevertheless, involving other people early on, especially people from other disciplines, can feel scary. In the worst case scenario, it leads to “design by committee.”

Moreover, both designers and content strategists often have backgrounds in fields in which a sole creative genius is still the ideal. Having someone else proof your work can feel like a threat to your creativity.

So how can you involve people early on so that you’re avoiding the waterfall, but also making sure that you’re not setting yourself up for design by committee? I found my answer when learning about code reviews.

The Aha! Moment

In July 2017, I founded Confrere together with two developers, and we quickly hired our first engineer (I’m not a developer myself, I’m more of a UX or content designer). Our collaboration was running surprisingly smoothly, so much so that at our retrospectives, the recurring theme was that we all felt that we were “doing it right.”

I sat down with my colleagues to try to pinpoint what exactly it was that we were “doing right” so that we could try to preserve that feeling even as our company grew and our team expanded. We came to the realization that we all appreciated that the whole team was involved early on and that we were being honest and clear in our feedback to each other. Our CTO Dag-Inge added: “It works because we’re doing it as peers. You’re not being berated and just getting a list of faults”.

The word “peer” is what gave me the aha moment. I realized that those of us working within UX, design, and content have a lot to learn from developers when it comes to collaboration.

Peer reviewing in the form of code reviews is essential to how software gets built. To me, code reviews offer inspiration for improving collaboration within our own fields, but also a model for collaborating across fields and disciplines.

If you’re already familiar with code reviews, feel free to skip the next section.

What Is A Code Review?

A code review can be done in various ways. Today, the most typical form of code review happens in the way of so-called pull requests (using a technology called git). As illustrated below, the pull requests let other people on the team know that a developer has completed code that they wish to merge with the main code base. It also allows the team to review the code: they give feedback on the code before it gets merged, in case it needs improvement.

Pull requests have clearly defined roles: there is an author and a reviewer(s).

As an example, let’s say our senior engineer Ingvild has made a change to Confrere’s sign-up flow. Before it is merged into the main code base and gets shipped, she (the author) creates a pull request to request a review from our CTO Dag-Inge (the reviewer). He won’t make any changes to her code, only add his comments.

It’s up to Ingvild how she wants to act on the feedback she received in the review. She’ll update her pull request with the changes she sees fit.

When the reviewer(s) approve the pull request, Ingvild can then merge her changes with the main code base.

Why Bother Doing Code Review?

If you’ve never done code review, the process above might sound bureaucratic. If you have doubts, here’s a ton of blog posts and academic research about the advantages of code review.

"Code reviews set the tone for the entire company that everything we do should be open to scrutiny from others, and that such scrutiny should be a welcome part of your workflow rather than viewed as threatening.

— Bruce Johnson, co-founder of Full Story"

Code review reduces risk. Having someone proof your work, and also knowing someone will proof your work, helps weed out errors and heightens quality. In addition, it ensures consistency and helps every team member familiarize with more of the code base.

When done right, code review also builds a culture for collaboration and openness. Trying to understand and critique other people’s work is an excellent way to learn, and so is getting honest feedback on your work.

Always having at least two people look over the code also curtails ideas of “my” code and “your” code. It’s our code.

Considering these advantages, a review shouldn’t just be for code.

Review Principles For All Disciplines, Not Just Code

With reviews, there is always one author and one or more reviewers. That means you can involve people early on without falling into design by committee.

First, I have to mention two important factors which will affect your team’s ability to do beneficial reviews. You don’t necessarily have to have mastered them, but as a minimum, you should aspire to the following:

• You and your colleagues respect each other and each other’s disciplines.
• You’re sufficiently self-assured in your own role so that you feel like you can both give and receive criticism (this is also connected to the team’s psychological safety).

Even if we’re not reviewing code, there’s a lot to learn from existing best practices for code reviews.

Within our team, we try to adhere to the following principles when doing reviews:

1. Critique the work, not the author.
2. Be critical, but remain affable and curious.
3. Differentiate between a) Suggestions b) Requirements, c) Points that need discussion or clarification.
4. Move discussions from text to face-to-face. (Video counts)
5. Don’t forget to praise the good parts! What’s clever, creative, solid, original, funny, nice, and so on?

These principles weren’t actually written down until after we discussed why our collaboration was working so well. We all felt we were allowed to and expected to ask questions and suggest improvements already, and that our motivations were always about building something great together, and not about criticising another person.

Because we were being clear about what kind of feedback we were giving, and also remembered to praise each other’s good work, doing reviews was a positive force rather than a demotivating one.

An Example

To give you an idea of how our team uses review across disciplines and throughout a process, let’s look at how the different members of our team switched between the roles of author and reviewer when we created our sign-up flow.

Step 1: Requirements Gathering

Author: Ida (UX)

Reviewers: Svein (strategy), Dag-Inge (engineering), Ingvild (engineering).

Whiteboard sessions can be exhausting if there’s no structure to them. To maintain productivity and creativity, we use the author/reviewer structure, even for something as seemingly basic as brainstorming on a whiteboard. In this case, in which we were coming up with the requirements for our sign-up flow, I got to be the author, and the rest of the team gave their feedback and acted as reviewers. Because they also knew they’d be able to review what I came up with in step 2 (plenty more opportunity for adjustments, suggestions, and improvements), we worked swiftly and were able to agree upon the requirements in under 2 hours.

Step 2: Mockup With Microcopy

Author: Ida (UX)

Reviewers: Ingvild (engineering), Eivind (design), Svein (strategy).

As an author, I created a mockup of the sign-up flow with microcopy. Did the sign-up flow make sense, from both the user and engineering perspective? And how could we improve the flow from a design and frontend perspective? At this stage, it was essential to work in a format in which it would be easy for all disciplines to give feedback (we opted for Google Docs, but it could also have been done with a tool like InvisionApp).

Step 3: Implementing The Sign-Up Flow

Author: Ingvild (engineering)

Reviewer: Ida (UX) and Dag-Inge (engineering).

We had agreed upon the flow, the input fields, and the microcopy, and so it was up to Ingvild to implement it. Thanks to Surge, we can automatically create preview URLs of the changes so that people who can’t read code are able to give feedback at this stage as well.

Step 4: User Testing

Author: Ida (UX)

Reviewer: The users.

Yes, we consider user testing a form of review. We brought our newly built sign-up flow face-to-face with actual users. This step gave us a ton of insight, and the most significant changes in our sign-up flow came as a result.

Step 5: Design

Author: Eivind (design)

Reviewers: Ingvild (engineering) and Ida (UX).

When design suddenly shows up here in step 5, it might look a lot like a waterfall process. However, our designer Eivind had already been involved as a reviewer since step 2. He gave a bunch of useful feedback at that stage and was also able to start thinking about how we could improve the design of the sign-up flow beyond the existing modules in our design system. At this step, Eivind could also help solve some of the issues that we identified in the user testing.

Step 6: Implementation

Author: Ingvild (engineering)

Reviewer: Eivind (design), Ida (UX) and Dag-Inge (engineering).

And then we’re back to implementing.

Why Review Works

In summary, there’s always just one author, thus avoiding design by committee. By involving a range of disciplines as reviewers early on, we avoid having a waterfall process.

People can flag their concerns early and also start thinking about how they can contribute later on. The clearly defined roles keep the process on track.

Regular Review Walkthroughs

Taking inspiration from code walkthroughs, we also do regular review walkthroughs with different foci, guided by the following principles:

• The walkthrough is done together.
• One person is in charge of reviewing and documenting.
• The idea is to identify issues, not necessarily to solve them.
• Choose a format that gives as much context as possible, so that it’s easy to act upon the findings later (e.g. InvisionApp for visual reviews, Google Docs for text, and so on).

We’ve done review walkthroughs for things such as accessibility audits, reviewing feature requests, auditing the implementation of the design, and doing heuristic usability evaluations.

When we do our quarterly accessibility reviews, our accessibility consultant Joakim first goes through the interface and documents and prioritizes the issues he’s found in a shared Google Sheet. Joakim then walks us through the most important issues he’s identified.

Meeting face-to-face (or at least on video) to go through the issues helps create an environment for learning rather than a feeling of being supervised or micromanaged.

If you find yourself always being tied up with something that’s due for release, or fixing whatever is at the top of your inbox, reviews can help remedy that. If you set aside regular half days for reviewing work you’ve already done, you can identify issues before they become urgent. It can also help you refocus and make sure you’re priorities are keeping along the right lines. Your team should maybe not begin building that new feature before you’re confident that the existing features are living up to your standards.

User Testing Is A Form Of Review

An important motivation for code reviews is to reduce risk. By doing it every single time you introduce a change or add something new to your product, and not just when you suspect something is maybe not up to par, you diminish the chance of shipping bugs or subpar features. I believe we should look at user testing from the same perspective.

You see, if you want to reduce the risk of shipping with major usability issues, user testing has to be part of your process. Just having your UX designers review the interface isn’t enough. Several studies have found that even usability experts fail in identifying every actual usability problems. On average, 1 in 3 issues identified by experts were false alarms — they weren’t issues for users in practice. But worse, 1 in 2 issues that users did in fact have, were overlooked by the experts.

Skipping user testing is just as big a risk as skipping code review.

Does Review Mean Death To Creativity?

People working within design, user experience, and content often have educational backgrounds from art schools or maybe literature, in which the sole creator or creative artistic genius is hailed as the ideal. If you go back in history, this used to be the case for developers as well. Over time, this has changed by necessity as web development has grown more complex.

If you cling to the idea of creativity coming from somewhere deep within yourself, the idea of review might feel threatening or scary. Someone meddling in your half-finished work? Ouch. But if you think about creativity as something that can spring from many sources, including dialogue, collaboration, or any form of inspiration (whether from the outside or from someplace within you), then a review is only an asset and an opportunity.

As long as we’re building something for the web, there’s no way around collaborating with other people, be it within our own field or others. And a good idea will survive review.

Let’s create something great together.

Further Reading

• Improving The Double Diamond Design Process
• The Feature Trap: Why Feature Centricity Is Harming Your Product
• Frequently Heard In My Beginning Front-End Web Development Class
• The Impact Of Agile Methodologies On Code Quality

(rb, ra, yk, il, mrn)

Among the most popular suggestions on Smashing Magazine’s Content User Suggestions board is the need of learning more about the interaction and communication between designers and developers. There are probably several articles worth of very specific things that could be covered here, but I thought I would kick things off with a general post rounding up some experiences on the subject.

Given the wide range of skills held by the line-up at our upcoming SmashingConf Toronto — a fully live, no-slides-allowed event, I decided to solicit some feedback. I’ve wrapped those up with my own experience of 20 years working alongside designers and other developers. I hope you will add your own experiences in the comments.

Some tips work best when you can be in the same room as your team, and others are helpful for the remote worker or freelancer. What shines through all of the advice, however, is the need to respect each other, and the fact that everyone is working to try and create the best outcome for the project.

For many years, my own web development company operated as an outsourced web development provider for design agencies. This involved doing everything from front-end development to implementing e-commerce and custom content management solutions. Our direct client was the designer or design agency who had brought us on board to help with the development aspect of the work, however, in an ideal situation, we would be part of the team working to deliver a great end result to the end client.

Sometimes this relationship worked well. We would feel a valued part of the team, our ideas and experience would count, we would work with the designers to come up with the best solution within budgetary, time, and other constraints.

In many cases, however, no attempt was made to form a team. The design agency would throw a picture of a website as a PDF file over the fence to us, then move on to work on their next project. There was little room for collaboration, and often the designer who had created the files was busy on some other work when we came back with questions.

It was an unsatisfactory way to work for everyone. We would be frustrated because we did not have a chance to help ensure that what was designed was possible to be built in a performant and accessible way, within the time and budget agreed on. The designer of the project would be frustrated: Why were these developers asking so many questions? Can they not just build the website as I have designed? Why are the fonts not the size I wanted?

The Waterfall versus Agile argument might be raised here. The situation where a PDF is thrown over the fence is often cited as an example of how bad a Waterfall approach is. Still, working in a fully Agile way is often not possible for teams made of freelancers or separate parties doing different parts of the work. Therefore, in reading these suggestions, look at them through the lens of the projects you work on. However, try not to completely discount something as unworkable because you can’t use the full process. There are often things we can take without needing to fully adopt one methodology or another.

Setting Up A Project For Success

I came to realize that very often the success of failure of the collaboration started before we even won the project, with the way in which we proposed the working relationship. We had to explain upfront that experience had taught us that the approach of us being handed a PDF, quoting and returning a website did not give the best results.

Projects that were successful had a far more iterative approach. It might not be possible to have us work alongside the designers or in a more Agile way. However, having a number of rounds of design and development with time for feedback from each side went a long way to prevent the frustrations of a method where work was completed by each side independently.

Creating Working Relationships

Having longer-term relationships with an agency, spanning a number of projects worked well. We got to know the designers, learned how they worked, could anticipate their questions and ensure that we answered them upfront. We were able to share development knowledge, the things that made a design easier or harder to implement which would, therefore, have an impact on time and budget. They were able to communicate better with us in order to explain why a certain design element was vital, even if it was going to add complexity.

For many freelance designers and developers, and also for those people who work for a distributed company, communication can become mostly text-based. This can make it particularly hard to build relationships. There might be a lot of communication — by email, in Slack, or through messages on a project management platform such as Basecamp. However, all of these methods leave us without the visual cues we might pick up from in-person meetings. An email we see as to the point may come across to the reader as if we are angry. The quick-fire nature of tools such as Slack might leave us committing in writing something which we would not say to that person while looking into their eyes!

Freelance data scientist Nadieh Bremer will talk to us about visualizing data in Toronto. She has learned that meeting people face to face — or at least having a video call — is important. She told me:

“As a remote freelancer, I know that to interact well with my clients I really need to have a video call (stress on the video) I need to see their face and facial/body interactions and they need to see mine. For clients that I have within public transport distance, I used to travel there for a first ‘getting to know each other/see if we can do a project’ meeting, which would take loads of time. But I noticed for my clients abroad (that I can’t visit anyway) that a first client call (again, make sure it’s a video-call) works more than good enough.

It’s the perfect way to weed out the clients that need other skills that I can give, those that are looking for a cheap deal, and those where I just felt something wasn’t quite clicking or I’m not enthusiastic about the project after they’ve given me a better explanation. So these days I also ask my clients in the Netherlands, where I live, that might want to do a first meeting to have it online (and once we get on to an actual contract I can come by if it’s beneficial).”

Working In The Open

Working in the open (with the project frequently deployed to a staging server that everyone had access to see), helped to support an iterative approach to development. I found that it was important to support that live version with explanations and notes of what to look at and test and what was still half finished. If I just invited people to look at it without that information we would get lists of fixes to make to unfinished features, which is a waste of time for the person doing the reporting. However, a live staging version, plus notes in a collaboration tool such as Basecamp meant that we could deploy sections and post asking for feedback on specific things. This helped to keep everyone up to date and part of the project even if — as was often the case for designers in an agency — they had a number of other projects to work on.

There are collaboration tools to help designers to share their work too. Asking for recommendations on Twitter gave me suggestions for Zeplin, Invision, Figma, and Adobe XD. Showing work in progress to a developer can help them to catch things that might be tricky before they are signed off by the client. By sharing the goal behind a particular design feature within the team, a way forward can be devised that meets the goal without blowing the budget.

Scope Creep And Change Requests

The thing about working in the open is that people then start to have ideas (which should be a positive thing), however, most timescales and budgets are not infinite! This means you need to learn to deal with scope creep and change requests in a way that maintains a good working relationship.

We would often get requests for things that were trivial to implement with a message saying how sorry they were about this huge change and requests for incredibly time-consuming things with an assumption it would be quick. Someone who is not a specialist has no idea how long anything will take. Why should they? It is important to remember this rather than getting frustrated about the big changes that are being asked for. Have a conversation about the change, explain why it is more complex than it might appear, and try to work out whether this is a vital addition or change, or just a nice idea that someone has had.

If the change is not essential, then it may be enough to log it somewhere as a phase two request, demonstrating that it has been heard and won’t be forgotten. If the big change is still being requested, we would outline the time it would take and give options. This might mean dropping some other feature if a project has a fixed budget and tight deadline. If there was flexibility then we could outline the implications on both costs and end date.

With regard to costs and timescales, we learned early on to pad our project quotes in order that we could absorb some small changes without needing to increase costs or delay completion. This helped with the relationship between the agency and ourselves as they didn’t feel as if they were being constantly nickel and dimed. Small changes were expected as part of the process of development. I also never wrote these up in a quote as contingency, as a client would read that and think they should be able to get the project done without dipping into the contingency. I just added the time to the quote for the overall project. If the project ran smoothly and we didn’t need that time and money, then the client got a smaller bill. No one is ever unhappy about being invoiced for less than they expected!

This approach can work even for people working in-house. Adding some time to your estimates means that you can absorb small changes without needing to extend the timescales. It helps working relationships if you are someone who is able to say yes as often as possible.

This does require that you become adept at estimating timescales. This is a skill you can develop by logging your time to achieve your work, even if you don’t need to log your time for work purposes. While many of the things you design or develop will be unique, and seem impossible to estimate, by consistently logging your time you will generally find that your ballpark estimates become more accurate as you make yourself aware of how long things really take.

Respect

Aaron Draplin will be bringing tales from his career in design to Toronto, and responded with the thought that it comes down to respect for your colleague’s craft:

“It all comes down to respect for your colleague’s craft, and sort of knowing your place and precisely where you fit into the project. When working with a developer, I surrender to them in a creative way, and then, defuse whatever power play they might try to make on me by leading the charges with constructive design advice, lightning-fast email replies and generally keeping the spirit upbeat. It’s an odd offense to play. I’m not down with the adversarial stuff. I’m quick to remind them we are all in the same boat, and, who’s paying their paycheck. And that’s not me. It’s the client. I’ll forever be on their team, you know? We make the stuff for the client. Not just me. Not ‘my team’. We do it together. This simple methodology has always gone a long way for me.”

I love this, it underpins everything that this article discusses. Think back to any working relationship that has gone bad, how many of those involved you feeling as if the other person just didn’t understand your point of view or the things you believe are important? Most reasonable people understand that compromise has to be made, it is when it appears that your point of view is not considered that frustration sets in.

There are sometimes situations where a decision is being made, and your experience tells you it is going to result in a bad outcome for the project, yet you are overruled. On a few occasions, decisions were made that I believed so poor; I asked for the decision and our objection to it be put in writing, in order that we could not be held accountable for any bad outcome in future. This is not something you should feel the need to do often, however, it is quite powerful and sometimes results in the decision being reversed. An example would be of a client who keeps insisting on doing something that would cause an accessibility problem for a section of their potential audience. If explaining the issue does not help, and the client insists on continuing, ask for that decision in writing in order to document your professional advice.

Learning The Language

I recently had the chance to bring my CSS Layout Workshop not to my usual groups of front-end developers but instead to a group of UX designers. Many of the attendees were there not to improve their front-end development skills, but more to understand enough of how modern CSS Layout worked that they could have better conversations with the developers who built their designs. Many of them had also spent years being told that certain things were not possible on the web, but were realizing that the possibilities in CSS were changing through things like CSS Grid. They were learning some CSS not necessarily to become proficient in shipping it to production, but so they could share a common language with developers.

There are often debates on whether “designers should learn to code.” In reality, I think we all need to learn something of the language, skills, and priorities of the other people on our teams. As Aaron reminded us, we are all on the same team, we are making stuff together. Designers should learn something about code just as developers should also learn something of design. This gives us more of a shared language and understanding.

Seb Lee-Delisle, who will speak on the subject of Hack to the Future in Toronto, agrees:

“I have basically made a career out of being both technical and creative so I strongly feel that the more crossover the better. Obviously what I do now is wonderfully free of the constraints of client work but even so, I do think that if you can blur those edges, it’s gonna be good for you. It’s why I speak at design conferences and encourage designers to play with creative coding, and I speak at tech conferences to persuade coders to improve their visual acuity. Also with creative coding. :) It’s good because not only do I get to work across both disciplines, but also I get to annoy both designers and coders in equal measure.”

I have found that introducing designers to browser DevTools (in particular the layout tools in Firefox and also to various code generators on the web) has been helpful. By being able to test ideas out without writing code, helps a designer who isn’t confident in writing code to have better conversations with their developer colleagues. Playing with tools such as gradient generators, clip-path or animation tools can also help designers see what is possible on the web today.

We are also seeing a number of tools that can help people create websites in a more visual way. Developers can sometimes turn their noses up about the code output of such tools, and it’s true they probably won’t be the best choice for the production code of a large project. However, they can be an excellent way for everyone to prototype ideas, without needing to write code. Those prototypes can then be turned into robust, permanent and scalable versions for production.

An important tip for developers is to refrain from commenting on the code quality of prototypes from members of the team who do not ship production code! Stick to what the prototype is showing as opposed to how it has been built.

A Practical Suggestion To Make Things Visual

Eva-Lotta Lamm will be speaking in Toronto about Sketching and perhaps unsurprisingly passed on practical tips for helping conversation by visualizing the problem to support a conversation.

"

Creating a shared picture of a problem or a solution is a simple but powerful tool to create understanding and make sure they everybody is talking about the same thing.

Visualizing a problem can reach from quick sketches on a whiteboard to more complex diagrams, like customer journey diagrams or service blueprints.

But even just spatially distributing words on a surface adds a valuable layer of meaning. Something as simple as arranging post-its on a whiteboard in different ways can help us to see relationships, notice patterns, find gaps and spot outliers or anomalies. If we add simple structural elements (like arrows, connectors, frames, and dividers) and some sketches into the mix, the relationships become even more obvious.

Visualising a problem creates context and builds a structural frame that future information, questions, and ideas can be added to in a ‘systematic’ way.

Visuals are great to support a conversation, especially when the conversation is ‘messy’ and several people involved.

When we visualize a conversation, we create an external memory of the content, that is visible to everybody and that can easily be referred back to. We don’t have to hold everything in our mind. This frees up space in everybody’s mind to think and talk about other things without the fear of forgetting something important. Visuals also give us something concrete to hold on to and to follow along while listening to complex or abstract information.

When we have a visual map, we can point to particular pieces of content — a simple but powerful way to make sure everybody is talking about the same thing. And when referring back to something discussed earlier, the map automatically reminds us of the context and the connections to surrounding topics.

When we sketch out a problem, a solution or an idea the way we see it (literally) changes. Every time we express a thought in a different medium, we are forced to shape it in a specific way, which allows us to observe and analyze it from different angles.

Visualising forces us to make decisions about a problem that words alone don’t. We have to decide where to place each element, decide on its shape, size, its boldness, and color. We have to decide what we sketch and what we write. All these decisions require a deeper understanding of the problem and make important questions surface fairly quickly.

All in all, supporting your collaboration by making it more visual works like a catalyst for faster and better understanding."

Working in this way is obviously easier if your team is working in the same room. For distributed teams and freelancers, there are alternatives to communicate in ways other than words, e.g. by making a quick Screencast to demonstrate an issue, or even sketching and photographing a diagram can be incredibly helpful. There are collaborative tools such as Milanote, Mural, and Niice; such tools can help with the process Eva-Lotta described even if people can’t be in the same room.

I’m very non-visual and have had to learn how useful these other methods of communication are to the people I work with. I have been guilty on many occasions of forgetting that just because I don’t personally find something useful, it is still helpful to other people. It is certainly a good idea to change how you are trying to communicate an idea if it becomes obvious that you are talking at cross-purposes.

Over To You

As with most things, there are many ways to work together. Even for remote teams, there is a range of tools which can help break down barriers to collaborating in a more visual way. However, no tool is able to fix problems caused by a lack of respect for the work of the rest of the team. A good relationship starts with the ability for all of us to take a step back from our strongly held opinions, listen to our colleagues, and learn to compromise. We can then choose tools and workflows which help to support that understanding that we are all on the same team, all trying to do a great job, and all have important viewpoints and experience to bring to the project.

I would love to hear your own experiences working together in the same room or remotely. What has worked well — or not worked at all! Tools, techniques, and lessons learned are all welcome in the comments. If you would be keen to see tutorials about specific tools or workflows mentioned here, perhaps add a suggestion to our User Suggestions board, too.

Further Reading

• Recovering Deleted Files From Your Git Working Tree
• The Feature Trap: Why Feature Centricity Is Harming Your Product
• How Frontend Developers Can Empower Designer’s Work
• Making Your Collaboration Problems Go Away By Sharing Components

(il, mrn)

Most design and product teams have some type of persona document. Theoretically, personas help us better understand our users and meet their needs. The idea is that codifying what we’ve learned about distinct groups of users helps us make better design decisions. Referring to these documents ourselves and sharing them with non-design team members and external stakeholders should ultimately lead to a user experience more closely aligned with what real users actually need.

In reality, personas rarely prove equal to these expectations. On many teams, persona documents sit abandoned on hard drives, collecting digital dust while designers continue to create products based primarily on whim and intuition.

In contrast, well-researched personas serve as a proxy for the user. They help us check our work and ensure that we’re building things users really need.

In fact, the best personas don’t just describe users; they actually help designers predict their behavior. In her article on persona creation, Laura Klein describes it perfectly:

“If you can create a predictive persona, it means you truly know not just what your users are like, but the exact factors that make it likely that a person will become and remain a happy customer.”

In other words, useful personas actually help design teams make better decisions because they can predict with some accuracy how users will respond to potential product changes.

Obviously, for personas to facilitate these types of predictions, they need to be based on more than intuition and anecdotes. They need to be data-driven.

So, what do data-driven personas look like, and how do you make one?

Start With What You Think You Know

The first step in creating data-driven personas is similar to the typical persona creation process. Write down your team’s hypotheses about what the key user groups are and what’s important to each group.

If your team is like most, some members will disagree with others about which groups are important, the particular makeup and qualities of each persona, and so on. This type of disagreement is healthy, but unlike the usual persona creation process you may be used to, you’re not going to get bogged down here.

Instead of debating the merits of each persona (and the various facets and permutations thereof), the important thing is to be specific about the different hypotheses you and your team have and write them down. You’re going to validate these hypotheses later, so it’s okay if your team disagrees at this stage. You may choose to focus on a few particular personas, but make sure to keep a backlog of other ideas as well.

I recommend aiming for a short, 1–2 sentence description of each hypothetical persona that details who they are, what root problem they hope to solve by using your product, and any other pertinent details.

You can use the traditional user stories framework for this. If you were creating hypothetical personas for Craigslist, one of these statements might read:

“As a recent college grad, I want to find cheap furniture so I can furnish my new apartment.”

Another might say:

“As a homeowner with an extra bedroom, I want to find a responsible tenant to rent this space to so I can earn some extra income.”

If you have existing data — things like user feedback emails, NPS scores, user interview notes, or analytics data — be sure to go over them and include relevant data points in your notes along with your user stories.

Validate And Refine

The next step is to validate and refine these hypotheses with user interviews. For each of your hypothetical personas, you’ll want to start by interviewing 5 to 10 people who fit that group.

You have three key goals for these interviews. For each group, you need to:

1. Understand the context in which they need to solve the problem.
2. Confirm that members of the persona group agree that the problem you recorded is an urgent and painful one that they struggle to solve now.
3. Identify key predictors of whether a member of this persona is likely to become and remain an active user.

The approach you take to these interviews may vary, but I recommend a hybrid approach between a traditional user interview, which is very non-leading, and a Lean Problem interview, which is deliberately leading.

Start with the traditional user interview approach and ask behavior-based, non-leading questions. In the Craigslist example, we might ask the recent college grad something like:

“Tell me about the last time you purchased furniture. What did you buy? Where did you buy it?”

These types of questions are great for establishing whether the interviewee recently experienced the problem in question, how they solved it, and whether they’re dissatisfied with their current solution.

Once you’ve finished asking these types of questions, move on to the Lean Problem portion of the interview. In this section, you want to tell a story about a time when you experienced the problem — establishing the various issues you struggled with and why it was frustrating — and see how they respond.

You might say something like this:

“When I graduated college, I had to get new furniture because I wasn’t living in the dorm anymore. I spent forever looking at furniture stores, but they were all either ridiculously expensive or big-box stores with super-cheap furniture I knew would break in a few weeks. I really wanted to find good furniture at a reasonable price, but I couldn’t find anything and I eventually just bought the cheap stuff. It inevitably broke, and I had to spend even more money, which I couldn’t really afford. Does any of that resonate with you?”

What you’re looking for here is emphatic agreement. If your interviewee says "yes, that resonates" but doesn’t get much more excited than they were during the rest of the interview, the problem probably wasn’t that painful for them.

On the other hand, if they get excited, empathize with your story, or give their own anecdote about the problem, you know you’ve found a problem they really care about and need to be solved.

Finally, make sure to ask any demographic questions you didn’t cover earlier, especially those around key attributes you think might be significant predictors of whether somebody will become and remain a user. For example, you might think that recent college grads who get high-paying jobs aren’t likely to become users because they can afford to buy furniture at retail; if so, be sure to ask about income.

You’re looking for predictable patterns. If you bring in 5 members of your persona and 4 of them have the problem you’re trying to solve and desperately want a solution, you’ve probably identified a key persona.

On the other hand, if you’re getting inconsistent results, you likely need to refine your hypothetical persona and repeat this process, using what you learn in your interviews to form new hypotheses to test. If you can’t consistently find users who have the problem you want to solve, it’s going to be nearly impossible to get millions of them to use your product. So don’t skimp on this step.

Create Your Personas

The penultimate step in this process is creating the actual personas themselves. This is where things get interesting. Unlike traditional personas, which are typically static, your data-driven personas will be living, breathing documents.

The goal here is to combine the lessons you learned in the previous step — about who the user is and what they need — with data that shows how well the latest iteration of your product is serving their needs.

At my company Swish, each one of our personas includes two sections with the following data:

If you’re looking for more ideas for data to include, check out Coryndon Luxmoore’s presentation on how his team created data-driven personas at Buildium.

It may take some time for your team to produce all this information, but it’s okay to start with what you have and improve the personas over time. Your personas won’t be sitting on a shelf. Every time you release a new feature or change an existing one, you should measure the results and update your personas accordingly.

Integrate Your Personas Into Your Workflow

Now that you’ve created your personas, it’s time to actually use them in your day-to-day design process. Here are 4 opportunities to use your new data-driven personas:

1. At Standups
   At Swish, our standups are a bit different. We start these meetings by reviewing the activation, retention, and referral metrics for each persona. This ensures that — as we discuss yesterday’s progress and today’s obstacles — we remain focused on what really matters: how well we’re serving our users.
2. During Prioritization
   Your data-driven personas are a great way to keep team members honest as you discuss new features and changes. When you know how much of your user base the persona represents and how well you’re serving them, it quickly becomes obvious whether a potential feature could actually make a difference. Suddenly deciding what to work on won’t require hours of debate or horse-trading.
3. At Design Reviews
   Your data-driven personas are a great way to keep team members honest as you discuss new designs. When team members can creditably represent users with actual quotes from user interviews, their feedback quickly becomes less subjective and more useful.
4. When Onboarding New Team Members
   New hires inevitably bring a host of implicit biases and assumptions about the user with them when they start. By including your data-driven personas in their onboarding documents, you can get new team members up to speed much more quickly and ensure they understand the hard-earned lessons your team learned along the way.

Keeping Your Personas Up To Date

It’s vitally important to keep your personas up-to-date so your team members can continue to rely on them to guide their design thinking.

As your product improves, it’s simple to update NPS scores and performance data. I recommend doing this monthly at a minimum; if you’re working on an early-stage, rapidly-changing product, you’ll get better mileage by updating these stats weekly instead.

It’s also important to check in with members of your personas periodically to make sure your predictive data stays relevant. As your product evolves and the competitive landscape changes, your users’ views about their problems will change as well. If your growth starts to plateau, another round of interviews may help to unlock insights you didn’t find the first time. Even if everything is going well, try to check in with members of your personas — both current users of your product and some non-users — every 6 to 12 months.

Wrapping Up

Building data-driven personas is a challenging project that takes time and dedication. You won’t uncover the insights you need or build the conviction necessary to unify your team with a week-long throwaway project.

But if you put in the time and effort necessary, the results will speak for themselves. Having the type of clarity that data-driven personas provide makes it far easier to iterate quickly, improve your user experience, and build a product your users love.

Other Resources

If you’re interested in learning more, I highly recommend checking out the linked articles above, as well as the following resources:

• “Running Lean: How to Iterate from Plan A to a Plan That Works,” Ash Maurya
• “How to Build Robust User Personas in Under a Month,” Tony Zambito, ConversionXL
• “Resurrecting Dead Personas,” Meg Dickey-Kurdziolek, A List Apart
• “A Closer Look At Personas: A Guide To Developing The Right Ones,” Shlomo Goltz, Smashing Magazine.

Further Reading

• When Words Cannot Describe: Designing For AI Beyond Conversational Interfaces
• Everything I Know About UX Research I First Learned From Lt. Columbo
• Improving The Double Diamond Design Process
• Five-Second Testing: Taking A Closer Look At First Impressions (Case Study)

(rb, ra, yk, il, mrn)

(This is a sponsored article.) Having undertaken initial user research and analyzed your research findings, the next phase of the design process is to apply what you’ve learned by developing a series of designs to test your assumptions. In the fourth article in my series for Adobe XD, I’ll be focusing on the initial phase of the design process.

Within this overall series of ten articles, this is the first of three that tie together the design process. This article deals with UX design at a higher level, from a birds’ eye point of view. My next article will explore UI design, exploring interface inventories, building pattern libraries and designing interactions and animations. The third article in this series within a series will explore wireframing and prototyping.

As I explored in my preceding article on UX research, it’s important to stress that we’re building on the user research undertaken. Having analyzed our research findings, our goal at this phase of the design process is to:

• establish some clear user pathways that satisfy different users’ needs by embracing user stories, scenarios and storyboarding;
• apply some lessons from the world of Human Computer Interaction (HCI) so that we design with first principles in mind; and
• establish a ‘look and feel’ for our designs in a manner that’s device-agnostic that can be applied in both a desktop and mobile context.

In short, this article is intended to act as a bridge between the research phase and the design phase. As I stressed in my last article, the design process — research, design, prototype, build, test — is an iterative one; at this phase in the process, we’re focused on developing a series of designs that we can prototype, build and test.

UX Design is a vast topic so consider this article a short primer, but — as in my previous articles — I’ll provide some suggested reading to ensure you’re well covered.

Getting A Skeleton In Place

Before we get down to the details of user interface (UI) design and building interactive prototypes, it’s important to get the high-level flow of the design in place, establishing a skeleton around which we can build our design.

At this point in the process, it’s important to use our research findings to inform the development of user stories, identifying different users’ goals. We can use these user stories to create different scenarios. This helps us to identify clear goals — and an underlying intent — that guides the design process. It also enables us to develop flows through what we’re building.

When developing initial flows — using paper prototypes and storyboards — we’re focused on getting a feel for the design in its totality, before drilling down into detail. It’s important to get a skeleton in place and not get lost in the details, which will follow down the line.

In my previous article, I focused on the importance of undertaking user research before you embark upon the design phase of a project. As I put it:

"Spend some time with your users, getting to know their needs, and what it is they are trying to achieve, these are their ‘jobs to be done.’"

By teasing out our users’ ‘jobs to be done,’ we can ensure that what we design is truly user-centered. Having undertaken some focused user research, it’s important to take your findings and use them to inform your design process. Your research should have helped you establish some patterns, needs that the users you’re designing for having in common.

One size rarely fits all, however, and it’s likely that whatever you’re designing will have multiple user types with different needs. Developing ‘user stories’ — that represent the needs of different users — can help you distill down the goals that you’re trying to solve, helping to shape the rest of the process. But what exactly are user stories?

User Stories

User stories are a useful way of establishing a high-level view of different users’ ‘jobs to be done.’ Written from the perspective of typical users, they help you to establish the different goals your different users have so that you can design for their different needs accordingly.

The term ‘User Story’ was originated by Alistair Cockburn, one of the initiators of the agile movement in software development, who coined the phrase, “a user story is a promise for a conversation,” during a project for Chrysler in 1998.

User stories shift the emphasis from writing about requirements to talking about them. Whilst subtle, this shift — from writing to talking — can have a significant impact upon the design process.

All too often requirements are delivered in an abstract manner, as a list to be checked off that — if you’re not careful — bears little resemblance to what users need and more resemblance to what a ‘design by committee’ needs. User stories help position users at the heart of the conversation.

This idea, of a tool to encourage and facilitate conversation, captures user stories’ strength. They are an ideal tool to start mapping out scenarios, ensuring users always remain at the heart of the design and development process.

Short descriptions of goals and features told from the perspective of different users, user stories help you to get an understanding of the underlying goals your users have so that you can see the problem from their perspective. These follow a pattern as follows:

• As a (person in a particular role),
• I want to (perform an action or find something out),
• So that (I can achieve my goal of).

Using the above template, we can put ourselves in the shoes of different users and develop different stories to shape our design. Imagine, for example, that we’re building a web-based learning resource where lecturers and students can share learning materials. We’re likely to have a number of different users with different needs. A lecturer’s user story might be:

"As a lecturer, I want to share my lecture slides so that I can provide my students with access to resources beyond the classroom."

By developing a short story around this user’s specific needs, we can begin to envisage design patterns that satisfy this type of user. Seen from the perspective of a student — a different user with different needs — we might develop the following user story:

"As a student, I want to access lecture slides so that I can refer to them when I’m revising."

These stories — relayed from different perspectives — provide us with useful provocations we can use at the start of the design process to start mapping out our design at a high level. Importantly, the stories are focused on satisfying our users’ needs. In short, user stories help us to get a feel for what users’ goals are at a high level. We can then use these stories to develop different scenarios which we can begin to design.

Using Scenarios To Inform Your Design

At the start of a project, it’s easy to get carried away adding features aplenty and getting lost in ‘featuritis.’ The danger of this approach is that it’s easy to begin adding features and functionality that detract from your users’ core goals.

By using user stories to develop typical scenarios, you remain focused on your users’ core goals. This approach also enables you to establish expectations and develop benchmarks for typical user needs, which can be used to set clear deliverables and scope at the start of the project.

Returning to the previous example, we can establish some high-level goals from the perspective of our different users: for the lecturer, we’re going to need to design an upload feature; for the student, we’re going to need to design an access feature. These are high-level goals, but we can — as we develop our scenarios — start to add some granularity and complexity to our user stories informing the design further.

For example, returning to the earlier example, from the students’ perspective we might consider the following scenarios:

• At a base level, the students want to access the slides.
• At a slightly more enhanced level, the students might want to be able to annotate the slides, capturing their notes.
• Finally, if resources allow it, the students might want to share their notes with their peers, enabling collaborative learning.

Scenarios, like the example explored above, enable us to get a clear picture of differing levels of complexity and design for these accordingly. They also allow us to get a feel for the flow of users through our design, enabling us to map them out on paper so that we can begin to build a birds’ eye view of the project.

Mapping Your Design Flow

Using your user stories and scenarios as a driver for discussion it’s possible to begin to map pathways through your design at a high level. This process of user story mapping, illustrated earlier, helps us to define different user flows.

At this point in the process, paper is a powerful tool for rapid prototyping, before moving on to develop more refined storyboards. A low-cost, low-fidelity and fast approach, paper prototyping has many benefits:

• It’s low cost, allowing you to explore multiple ideas with very little barrier to entry;
• It’s low fidelity, which encourages you to focus on the big picture and not get lost in the details;
• It’s fast, enabling you to quickly iterate through multiple variations of a flow.

Paper also enables collaboration, allowing multiple participants to get around a table and develop a design quickly, taking on board everyone’s opinions and insights.

Lastly, paper ‘saves itself.’ When we design on screens, we often lose design artifacts due to the nature of software saving ‘states,’ different points in the design process. Paper prototyping allows us to see the entirety of the design process including rejected ideas en route to our finished concept.

In my experience, a typical project will often require multiple rounds of paper prototypes as you iteratively work your way through your thinking. At this point in the process working on screen is too slow and too refined, which can quickly lead to getting lost in needless detail. Paper frees you up to focus on the big picture, which is what matters at this stage.

Of course, even experienced designers can recoil when confronted with the idea of sketching interfaces, finding the process intimidating. It’s not uncommon to hear, “But, I can’t draw!” This is patently untrue, all of us were able to draw just fine when we were children (as all those pictures on our parents’ fridges attested!) we just need to re-learn this valuable skill.

To paraphrase Jason Santa Maria:

"Sketching isn’t about being a good artist, it’s about being a good thinker."

With high-level sketches established it’s time to start adding some fidelity by creating some storyboards and wireframes. Hold that thought. However, I’ll return to it in my sixth article on Wireframing and Prototyping.

A Spot Of Science: UX Laws

UX might be a relatively new discipline, but it’s informed by decades of research within the field of Human Computer Interaction (HCI).

As I noted in the first article in this series, on The Evolution Of User Experience Design, we are above all designing for humans, and humans broadly share similar characteristics that we should factor in when we make our design decisions. HCI offers us numerous principles that we can apply to the field of user experience design.

Many of these principles have been distilled down in the form of ‘laws’ that we can draw from, for example:

• Hick’s Law, which stresses the need to minimize choices to ease cognitive burden and help drive decision-making;
• Fitt’s Law, which provides valuable advice on how we can ease interactions through the careful sizing and positioning of interface elements; and
• Miller’s Law, which emphasizes the benefits of ‘chunking’ to ease complex tasks.

These are principles that can be applied at both the macro- and micro- level and to improve as a designer they are well worth exploring in depth. I’ll explore three — Hick’s Law, Fitt’s Law, and Miller’s Law — but there are many more.

Jon Yablonski’s excellent site, Laws of UX, is a helpful collection of principles, which is well worth bookmarking. Not only is a lovely piece of design in and of itself, but it also provides a good overview of each principle accompanied by links to further reading.

Hick’s Law

Hick’s Law (or, in full, the Hick-Hyman Law) states:

"The time it takes to make a decision increases with the number and complexity of choices."

Named after William Edmund Hick and Ray Hyman, a pair of psychologists, the law stresses the importance of reducing the number of choices you present a user with.

You might think you’re helping your user by offering an endless series of choices, but in reality, you’re adding to their cognitive burden. The more choices a user is confronted with, the more likely they are to walk away, crippled by ‘decision paralysis.’ This can be particularly problematic in an e-commerce context, where users walking away leads to a direct impact on the bottom line.

We can apply Hick’s Law to UX design in a variety of ways:

• When creating navigation instead of providing an endless list of choices, focus on just a few. Your users will thank you.
• In an e-commerce context, instead of listing every single product, reduce the number of choices and focus. Do this, and you’ll offset decision paralysis leading to higher conversion rate.
• Distinguish essential content from secondary content. By enabling users to find a path through fewer choices, you’ll reduce their cognitive burden.

We’re often guilty of equating ‘more’ with ‘better,’ but Hick’s Law tells us to think otherwise. The greater the number of options, the longer it takes our users to reach a decision (and sometimes leads them to making no decision). Focus is what matters, not least in a world increasingly overwhelmed with choice.

Fitt’s Law

Fitt’s Law states: The time it takes to acquire a target is a function of the distance to and size of the target. Translated that means: The farther away a target is — a button on a screen, for example — the larger it needs to be for a user to be able to reach it easily.

Fitt’s Law is particularly important when it comes to designing buttons and other clickable onscreen elements. Different contexts require different approaches and will inform your design approach.

In a desktop context a user will be using a mouse and — on a large screen — traversing potentially large distances. In this context, it’s important to ensure your call-to-action buttons (CTA) are reasonably sized, easy to see and to click on.

In a mobile context, it’s critical to consider tap targets when designing interfaces. When designing for touchscreens, our fingers are lower fidelity than mouse pointers, so we need to increase our tap target sizes. (Of course, larger tap targets in desktop environments can help, too!)

We can apply Fitt’s Law to UX design in a variety of ways:

• When designing for mobile, consider your tap targets. With less screen real estate reduce the number of clickable elements and increase their size.
• It might sound obvious, but if you have a large button on screen, ensure it’s the primary call to action otherwise you run the risk of users clicking it inadvertently.
• When designing drop-down menus or other forms of nested navigation, ensure your target sizes are large enough for users to acquire.

Generally speaking, the further away something is the larger it needs to be in order for a user to hit it. When planning out your design at a high level consider important calls to action and ensure you’ve taken on board Fitt’s Law when designing these. Tiny buttons might look neat and tidy, but if they frustrate your user, your design needs work.

Miller’s Law

Miller’s Law states: The average person can only keep seven (plus or minus two) items in their working memory. In short: there’s only so much we can hold in our heads in a short space of time.

Miller’s law is particularly important when we consider how we organize and group information, and is where chunking can come in useful. Consider the formatting of the following two phone numbers (both the same, fictional number):

• 07700984964
• 07700 984 964

As a string of digits without spacing, an eleven digit number is difficult for a user to hold in working memory. Add some spacing, however, and your users’ task is considerably eased. By chunking the information, your user can retain the three groups of numbers in working memory, enabling them to complete their task.

Miller’s Law goes further than easing micro-interactions like this; it can also be used at a more macro scale. For example, when designing forms, focus on chunking information into logically organized groups: name, address and contact details; account details, like usernames and passwords; bank details; and other groupings.

We can apply Miller’s Law to UX design in a variety of ways:

• When listing telephone numbers chunk the information so that it can be held easily in working memory.
• When designing payment forms that feature credit card information, a credit card number will be easier to parse by users if it’s broken into four chunks of four.
• Reduce cognitive load by limiting the number of choices on offer.

As designers, we often have to present complex information. Miller’s Law is useful to keep in mind in this context. Where possible look for groups of information that can be broken down and chunked, enabling them to be held more easily in users’ working memory.

Look And Feel: Communicating Visual Design

With a bird’s eye view of your project’s flow established, it’s important to start to think about its look and feel, as well as its visual design. This is what I call ‘visual grammar,’ and it’s the visual approach you’ll be adopting in your design.

With an ever-increasing proliferation of devices to design for — watches, phones (from small to large), tablets, desktops and other media — the idea of developing a single pixel perfect visual has become dated.

In response to this changing landscape, we’ve seen a move towards design artifacts that move away from pixel perfection in favor of capturing the ‘flavour’ of a design. These artifacts include, for example:

• Mood Boards
• Style Tiles
• Element Collages

Everyone’s process is different, but at this stage in the process, I use a combination of mood boards and element collages to help to establish direction: mood boards help you to get into the right ballpark, element collages act as a bridge between your visual design and your user interface design.

Moodboarding

Moodboarding, as its name implies, establishes the mood, helping you to zone in on a particular look and feel that fits your overall goal. Mood boards are useful as conversation starters, acting as a focus around which you can build. As a rule of thumb, I usually put together between three and five different mood boards, each signposting different directions.

You might have a particular look and feel in mind, but — as we all know, all too well, I’m sure — your preferred option might not match your client’s point of view. I find it helps to have alternatives and often find the end result drawing together different elements from different mood boards.

The bottom line: At this stage you’re presenting a high-level visual design, not getting lost creating pixel-perfect designs, which are futile in an age of widely differing screen sizes. Detailed mockups will follow at the wireframing and prototyping stage.

This point in the process is about developing design artifacts that can be used to spark conversations. To drive that creative discussion it helps to have a variety of different mood boards — each with a different look and feel.

When putting together mood boards, it’s important to consider analog approaches as well as digital approaches. If your visual inspiration is 100% digital, you run the risk of what I call everythinglooksthesameness where one design looks exactly like another. Consider looking beyond the screen for inspiration, using old unwanted magazines for inspiration, do so, and your designs will stand out.

Element Collages

With feedback gathered on your mood boards, it’s time to start developing some design components, applying your visual direction to some typical user interface elements so that you can settle on a ‘visual grammar.’

There are a number of tools you can use to do this including Style Tiles and Element Collages. Both have their strengths, primarily acting as catalysts for edging towards a finished look and feel.

As Samantha Warren, who developed the Style Tiles methodology, puts it:

"Style Tiles are a catalyst for discussions around the preferences and goals of the client."

This emphasis — on having a discussion about look and feel — is the strength of these two methods. They save a considerable amount of time, removing the need at this stage to create pixel-perfect renderings at multiple sizes.

In my experience, Style Tiles can be misread by clients who mistakenly think they’re visual mockups. I prefer a more freeform, less template-based approach, and when I discovered Dan Mall’s Element Collage approach, I was hooked.

In an excellent post detailing his design process on a project for Reading Is Fundamental, Mall stresses the need to replace presentations with conversations, getting the client involved in the process. Element Collages are an excellent way of driving this conversational approach. As Mall puts it:

"When talking about design with my clients, I like to have as much visual fodder as I can, in order to ensure we’re talking about the same thing. My version of Style Tiles integrates my love of collaging for a different type of execution I call an ‘Element Collage.’ That particular phrase creates an expectation that what we’re looking at isn’t a final design but rather an assembly of disparate pieces without specific logic or order."

The beauty of Element Collages is that they act as a bridge between your mood boards and your (soon to be developed) UI components. They’re flexible enough to show clients to establish a feel for what we’ll be building. Above all, they’re a useful tool for helping you to gain consensus around your visual grammar before you start to develop more time-intensive prototypes.

In Closing

Before we get down to the details of user interface (UI) design and building interactive prototypes, it’s important to get the high-level flow of the design in place, establishing a skeleton around which we can build our design.

By establishing a high-level process to kick off the design phase of your projects you can work more efficiently to get a clear framework in place. At this stage in the process, it’s important not to get lost in the details, but rather to focus on getting the broad brushstrokes in place.

It’s important to get the broad brushstrokes right before diving deeper into designing UI and developing wireframes and prototypes. Focus on establishing a clear design direction, and some clear user goals, before getting into the details. Resisting the urge to focus on details without clear design goals established saves wasted work.

In short, don’t get lost in the detail until you have everything mapped out.

Suggested Reading

There are many great publications — offline and online — that will help you on your adventure. I’ve included a few below to start you on your journey.

• “How to Write Smarter User Stories,” Joe Natoli
  If you’re already familiar with user stories, I’d recommend reading Natoli’s suggested enhancements to user stories — by adding a focus on measurable benefits — are an interesting take.
• “User Stories,” Mountain Goat Software
  This guide provides helpful advice on splitting user stories into a series of smaller, connected stories and adding ‘conditions of satisfaction,’ which are worth considering.
• “Laws of UX,” Jon Yablonski
  An excellent site with helpful collection of principles that is well worth bookmarking. Not only is a lovely piece of design in and of itself, it also provides a good overview of each principle accompanied by links to further reading.
• “Psychology and UX,” Nielsen Norman Group
  With a firm grounding in the different laws that can be applied within the field of user experience, I’d recommend exploring psychology, too.
• “Element Collages,” Dan Mall
  This is well worth reading if you want to gain an understanding of how these tools can be used in the service of typical client projects.

This article is part of the UX design series sponsored by Adobe. Adobe XD is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype, and share — all in one app. You can check out more inspiring projects created with Adobe XD on Behance and also sign up for the Adobe experience design newsletter to stay updated and informed on the latest trends and insights for UX/UI design.

Further Reading

• How Accessibility Standards Can Empower Better Chart Visual Design
• Improving The Double Diamond Design Process
• Everything I Know About UX Research I First Learned From Lt. Columbo
• Writing CSS In 2023: Is It Any Different Than A Few Years Ago?

(ra, il, mrn)

Why write requirements? Well, let’s imagine you want to produce a mobile app, but you don’t have the programming skills. So, you find a developer who can build the app for you, and you describe the idea to him. Surprisingly, when he showcases the app for the first time, you see that it is not exactly what you want. Why? Because you didn’t provide enough detail when describing the idea.

To prevent this from happening, you need to formalize the idea, shape it into something less vague. The best way to do that is to write a requirements document and share it with the developer. A requirements document describes how you see the result of the development process, thus making sure that you and the developer are on the same page.

In this article, we will outline the most common approaches to writing requirements documents. You will learn the basic steps of writing mobile application requirements and what a good requirements document looks like.

How To Approach The Writing

A carefully crafted requirements document eliminates ambiguity, thus ensuring that the developer does exactly what needs to be done. In addition, the document gives a clear picture of the scope of the work, enabling the developer to better assess the time and effort required. But how do we create a good document? Below are some tips that our mobile team at Polecat follows when crafting requirements.

1. Describe The Idea In General

We believe that a proper description of the idea should fit in one sentence. The sentence may include a core feature of the application, so that the reader understands instantly what the app is about. For a calorie-tracking mobile application, it could be, “An app to track calorie consumption to help those who care about their weight.”

Hint: Gua Tabidze shares a few models that others use to describe an idea.

2. Consider The Sequence

Study basic navigation patterns, and describe your application in the same sequence that users would experience while exploring it. Once the idea part is done, describe the first steps of the application, such as the onboarding screens and user registration.

Then, move on to what goes next, such as the application’s home screen. This approach will give the reader a sense of what the user’s journey would look like.

At the end, don’t forget about basic features and screens such as the privacy policy and the “forgot password” feature.

3. Review Existing Applications In The Stores

Review existing applications in Apple’s App Store and Google Play, and refer to them when describing your app. If you like how the “forgot password” feature works in applications A and B, put it in the requirements document.

4. Abstract Away From Detail

Focus on the features of the application, and skip details such as the color of a button. Most app users do not care about such details. What they do care about is whether your application helps to solve their problem. So, when writing requirements, concentrate on things that the user should be able to do in the app.

5. Prioritize Features

Convey which features are more important than others, so that the developer knows what to focus on first. We usually follow the MoSCoW method, marking items with “Must,” “Should,” “Could” and “Won’t” levels of priority.

6. Complement Text With Wireframes

Create wireframes of the screens of the application to accompany your textual description of them. If you have more than four wireframe screens, then drawing a screen map makes sense. We’ll show a screen map later in this article.

Requirements Formats

Now that you know how to write the requirements, you’ll need to choose an appropriate format for the document. There are a few basic formats for writing the requirements for a mobile app, such as a functional specification document (FSD), user stories and wireframes.

Functional Specification Document

An FSD is probably the default format in the software development industry. It consists of a standard list of items that cover what the product should do and how it should do it.

Let’s take a simple calculator application and describe its features as an FSD:

• Application screen presents a digital keyboard with additional buttons for basic arithmetic operations (addition, subtraction, multiplication, division) and a result button (marked with “=”).
• Tapping on a digit button adds it to the display section of the screen. Each new digit is added to the right side of the number.
• Tapping on an operation button causes the current number shown in the display section to be added to the memory. It also clears the display section for the next number.
• Tapping on the display-result button combines the number in memory with the one in the display section according to the operation requested previously. The resulting number is shown in the display section of the screen.

As you can see, this format requires quite a detailed description of the product because the description will be used by both the business and the developers. It ensures that all participants are on the same page.

The person who composes the FSD should have strong experience in software development and should know the specifics of the mobile or other platform for which you are building. Also, because of the high level of detail required, creating and polishing such a document usually takes a decent amount of time.

User Stories

A user story is less formal than an FSD yet still very powerful. It lists the things that the user can do in the application and is described from the user’s perspective. The document could also briefly explain why the user would want to do it, if that’s not obvious.

Let’s take our calculator example and add a few other features, describing them as a user story:

• As a user, I want to be able to change the number notation from decimal to exponential (and vice versa), so that I can work with very small or very large numbers.
• As a user, I want to be able to export a calculation’s history as a PDF file to share with my colleagues.

Because of the explanation, such a format provides not only a technical overview of the requirements, but also a good business case for them. Thus, if a feature is identified that is not critical to the business, you could decide either to completely remove it from the scope or to postpone it to a future release.

Using this format, you can easily split one story into multiple sub-stories to provide more detail. For example, we could split the PDF-exporting story into the following sub-stories:

• As a user, I want to be able to tap on the sharing button (top right of the screen) to see my options (sharing as PDF, text, image).
• Once I select a sharing option, I want to select the calculation timeframe that will be shared, using iOS’ date picker.

Because of the simplicity and non-technical nature of user stories, in most cases, a manager cannot simply ask a developer to implement a particular user story. Turning a story into a task that can be added to a task tracker requires further discussion and detailing between the manager and technical leader.

User stories have become one of the most convenient and popular formats because of their simplicity and flexibility.

Sketches And Wireframes

Another way to outline an application’s requirements is to visualize them in sketches or wireframes. With iOS development, around 70% of development time is spent on interface implementation, so having all of the screens in front of you would give you a good sense of what needs to be done and the scope of the work.

Creating a relevant set of wireframes for a mobile application requires you to know the basics of the user experience: how screens can be linked with each other, which states each screen can have, and how the application will behave when it is opened from a push notification.

Mixing Formats

Don’t be afraid to mix formats. By doing this properly, you take advantage of the strengths of each format. In our experience, mixing user stories and wireframes makes the most sense. While the user stories describe the features of the application and provide a business case for them, the wireframes show how these features would appear on the screens of the app. In addition, putting together user stories and wireframes would take you less time than writing an FSD, with all of its accompanying detail and descriptions of the interactions.

Start by sketching out wireframes for the application. Once the wireframes are done, add two or more user stories for each screen, describing what the user can do on that screen. We’ve found this approach to be the most appropriate for mobile application development, so we use it a lot.

Let’s Practice

I’ll take our What I Eat application as an example. I’ll compose the requirements document as if we were developing the application from scratch.

First, let’s formalize the idea using Steve Blank’s XYZ pattern: “We help X do Y by doing Z.” The premise of the application is to enable users to take control of what they eat during the day and of their calorie intake. According to the XYZ method: “What I Eat helps those who care about their weight to track calorie consumption by providing functionality for a simple meal log.”

As mentioned, mixing user stories and wireframes works best for us, so why not use them here?

The next step is to describe the What I Eat app as user stories, screen by screen. We’ll begin with the application’s start and home screen:

• As a user, I want to open the app and instantly see today’s meal log and the calories consumed.
• I want to be able to quickly add new meals and calories that I’ve just consumed.
• I also want quick access to the in-app calendar to view my meal logs from previous days.

To avoid any ambiguity, we’ll create a wireframe for this screen.

As you can see, we weren’t able to put the “Add new meal” functionality on the home screen. Instead, we added a button to navigate to another screen that presents this feature. Now, we need to put together user stories for this new screen:

• I want to type in the name of the meal I’ve just had.
• Along with the name of the meal, I want to enter the number of calories.

The home screen has a button that opens the calendar. Because there are many other calendar apps, checking their designs first makes sense. We like the iPhone’s default calendar app, so we will use it as a reference.

• As a user, I want to be able to quickly select a date in the current month.
• When selecting a date, I want to see a list of meals for that date below, like in the iPhone’s calendar app.
• I want to be able to switch to the next or previous month.

We will also put a piece of the iPhone calendar’s user interface in the wireframe.

Finally, we need to add some settings to the app.

• I want to be able to enable and disable iCloud backups for my meal records.
• I want to be able to enable and disable daily push notifications that remind me to track my calorie intake.

Phew! Almost done. The final step is to put the wireframes and user stories together in one document, with each wireframe and its respective story on its own page.

In addition, we can draw a map to visualize how the screens are connected to each other. We’ll use miro for that.

In doing the screen map, we realize that there is no button to go to the settings screen, so we’ll add that to the home screen.

Conclusion

We have created two documents: a PDF with user stories and wireframes, and a screen map that complements the PDF. Together, they describe in detail what features the application should have. We can go ahead and send that to our developer. This time, the application he delivers will correlate with your vision.

Generally speaking, writing a requirements document is mostly about conveying your vision to the rest of the team. Don’t limit yourself to the methodology described above. Feel free to experiment and find the solution that works best for you.

Resources

Delve deeper into the subject with the following resources:

• Story Splitting Cheat Sheet (PDF, 0.25 MB)
• 10 Tips for Writing Good User Stories, Roman Pichler
• The Wireframe Perfectionist’s Guide, Edric Lapniramai, Smashing Magazine
• Designing Features Using Job Stories, Alan Klement, Intercom

We’d love to hear about your approach to creating requirements documents. Please share your thoughts in the comments.

Further Reading

• What You Should Know About The App Design Process
• Creating Wireframes And Prototypes With InDesign
• The Skeptic’s Guide To Low-Fidelity Prototyping
• UX Sketching And Wireframing Templates For Mobile Projects (Free Download)

(da, vf, yk, al, il, mrn)