Book Recommendation: Baymard Studies

Not every published user research study produces practical suggestions and tools. Many don’t even go into depth about why they end up at particular findings. Some publish study data without doing much interpretation of results.

With the Baymard Institute, you’ll get a practical, hands on, and well explained heuristic of the study results. While the method they use is often a bit limited and lacks quantitative support, it is incredibly detailed and useful.

Each study starts with a brief explanation of their method. Then they go through major finding by major finding, describing how severe and frequent the issue was. They then explain the issue and prove it with several of their participants. Finally, they show you what to avoid and how to improve upon it. By using real world sites like Apple or Nordstrom, you find that it isn’t just the small shops facing usability issues. They give several case studies that go in-depth on a particular site or app, demonstrating the usability strengths and weaknesses based on their findings. Finally, they end with a heuristic checklist that you can use to check your own site or app with.

At ConceptCodify, we still strongly recommend conducting your own usability tests and other forms of user research before starting to make changes, but the Baymard Institute publications is useful as a place to start the conversation about the usability of your product.

Right now, Baymard offers three reports: Checkout Processes, Mobile Devices, and Homepage and Category. To get a sense of the content, they offer samples and their blog posts are of similar style to their reports.

Checkout the Baymard Institute reports at

Stop making full-page comps

What’s your company’s design process?

Maybe a stakeholder says, I want this, or we need that. Maybe there’s some market research or looking at analytics; probably not. The designers then jump into Photoshop, making what the stakeholder asks for page by page, comping each page in full each time. The stakeholders have a few random comments, but generally approve it since its exactly what they asked for. Then its handed to developers as a complete package with little explanation, where they sort of make it look like the comps but there’s many unresolved questions about the functionality or reusability. And most of the time, too many problems arise in fleshing out requirements and getting it through testing and it never launches, or it launches months later than it should and no one’s entirely happy with it.

User experience research and using a more lean, agile model can ease these problems. Making something look good is important, but making something that helps users meet their goals and is developed and iterated on quickly is even more important.

Maybe you can’t get user experience research buy-in. Usability testing, why would we need that? There’s another way to stop the pain, and tends to be easier to get people to bite.

Stop making full-page comps.

Does this seem counterintuitive to you? Stakeholders often want to “see” the fully developed product before “handing” it off to development, because development resources are highly limited and expensive. But it costs more to do it this way in the end and is very frustrating for everyone involved. Just outline the problems this system is causing, if you are using this system I’m sure you’re already well aware of the issues it causes. Maybe 90% of people are doing full-comps still, but does that really justify the practice?

Instead, try this. Comp up a single library of reusable components and modules. Shocking! The developers will almost immediately jump onboard. Why? Because making things consistent is much easier to program.

You probably already have an existing site or project. How do you transition? First, go through the project and start just making a list of components that exist repeatedly. Need a starting place? Look at something like Twitter Bootstrap or the Mailchimp. Then, make a single styleguide and component library in Photoshop or your design tool of choice. (Or even HTML/CSS!) Then, as you add new features or change things on the site, just update the component library. For each new or updated feature, add new components, remove components no longer being used, change components and show changes that need to be made to existing to components.

But then how do the developers know how to build it, you ask? I mean, you are wireframing, drawing flow diagrams, and listing out acceptance criteria, right? If you aren’t, start getting into that practice. With wireframes, flow diagrams, the acceptance criteria, and the component library, the developers will know how to combine those things to produce the product.

But what if I need a special graphic for this situation? Okay, take a screenshot, or make a rough comp of the external elements, and build that graphic. This isn’t all or nothing, its about changing the main habit.

What if I need a change? Just add it to the component library after the ‘main’ component.

But what if a stakeholder insists on seeing a full comp? Fake it. Focus on making the component library the true source, and build out the full comp as quickly as possible. They probably don’t want to see a full comp for every page in reality, just the big pieces. So then just fake it for those parts. After all, they aren’t looking to see a demonstration of Photoshop skills. They are looking for a visual of what their idea would look like.

Cut down your own work down to a third. Cut development time down in half. Be more agile. Smooth communication. Deliver wireframes, diagrams, visual component libraries, acceptance criteria, and the occasional graphic or comp. And in the process, accidentally integrate some of  the agile and user experience processes into your team’s workflow.

Questions, comments? Let us know!

The number of cards in a card sorting study

One of the most common questions we get at ConceptCodify is, “how many cards should I put in a study?” We see studies of all types and sizes, and we can make some recommendations based on what we’ve seen so far.

The biggest mistake many researcher make is having studies with way too many cards. We’ve seen studies with over 300 cards before. Statistically, these studies get very few responses. Very few people are going to want to sit down and sort that much information. For a normal study, about a third of participants who start sorting cards will actually finish sorting the cards. For studies with over 100 cards, this number drops to being so small, it isn’t a measurable statistic.

Sometimes we also see studies with very few cards. Most of the time, this appears to be people who are just trying out the tool and seeing how the setup process works. But even a small study, of let’s say 10 cards, can give very valuable information. If you think about a product page for example, there’s really only about 10 or so major sections, but having the data about how to organize the page can dramatically increase sales.

We can estimate from what we’ve seen it takes participants about 10-20 seconds per card to sort a study. And there’s a real drop-off after a few minutes of starting a study. In general, it looks like you want participants to take three minutes or less to sort the cards. In other words, ideally, you want about 10-20 cards per study. You can extend to around 30 safely, but beyond that, you’ll have a hard time getting enough responses to make the data valuable. You can ease this a bit by using our feature to show a random subset to each participant, but you’ll still need to collect more responses to get meaningful data from the number of cards.

The biggest piece of advice I can give is, think about what if you were still conducting the card sort in person. What if you wrote each concept on an index card and handed it to someone. How large would the stack be? Would the participant run for it when looking at the size of the stack if they saw it? That’s probably a good sign that there’s a problem. Similarly, if someone came to you and said, here’s these 10 cards, how would you group them, you’d probably have no problem stopping for a minute to sort the cards. If it were 50 cards, you’d probably be less likely to be willing to commit.

Make the studies as small as you can while getting the data you need. Try to get the big picture concepts; don’t focus on getting every single detailed element. If you need to, you can start with a overview study, and then do later studies to flesh out the details. There’s no rule saying you have to get all the information in one study.

To be entirely forthcoming, ConceptCodify has difficulty calculating the result with studies with more than 150 cards. The calculation grows exponentially with the number of cards; after about 200 cards, the calculation time skyrockets. The number of participants impacts the performance linearly; the difference between 5 participants and 100 participants is very small. We’ve been working on making our algorithms more efficient, but after seeing the response rates on studies with large numbers of cards, we’re now of the belief our engineering time would be better spent elsewhere, such as new analysis options, filtering, and sharing.

We’ve noticed the hardest part of conducting studies is getting stakeholders on board and recruiting participants, based on the support tickets we get and conversations we have with researchers at events and around. We’d like to spend more time in those directions. We’re trying to think of ways to make card sorting a more social, collaborative process, as both of these issues are interpersonal. If you have thoughts or suggestions in this regard, we’d love to hear your ideas.

But to get back to the point of this article:

Design your study with the least number of cards you need to get valuable data.

Book Recommendation: The Elements of User Experience by Jesse James Garrett

The Elements of User Experience: User-Centered Design for the Web and Beyond (2nd Edition) (Voices That Matter)

One of the best books written about the user experience design process, Jesse James Garrett’s manifest provides a solid, simple structure to thinking about systematizing design. In this book, the author lays down the system in five large stages, Strategy, Scope, Structure, Skeleton, and Surface. This can also be made into five big questions that must be answered about every design project:

  • Why are we building this? Who are we building this for? What problem are we solving?
  • What exactly are we building? What are we not building? What are its parts and functions?
  • How will it be organized? What defines the architecture?
  • How will it be used? Where will it be used? How will it flow?
  • What will it look like?

By starting with the biggest, most important questions first, you frame the sequence of thought so that by the time you get to, what does it look like, you already have a solid foundation instead of making guesses. We follow a similar strategy in more detail in our Lean Launch.

If you haven’t read Jesse James Garett’s seminal Elements of User Experience, buy this book now! It’s a quick read at about 150 pages with plenty of illustrations, but it will help so greatly in framing everything else about how to design effectively and strategically.

The Elements of User Experience: User-Centered Design for the Web and Beyond (2nd Edition) (Voices That Matter)

What is information architecture strategy?

Sometimes all you need is to know how to layout a navigation. Other times though, you have thousands and thousands of concepts and ideas for very large sites and projects that need to be organized coherently and efficiently. This is when we evolve from conversation about information architecture and we add strategy to the element. No longer do we just think about how to arrive at the best organization for our information. Now, we are in the realm of thinking about organization information as a process and not as an result.

Often, content strategy and information architecture are closely related. After all, content is a type of information. So we can borrow some ideas from content strategy as well, including some the overall big steps and components.

Establish your goals and outcomes. The way to start any project, and this goes for information architecture as well, is to define what the results look like. Where do you want to be? Start the conversation with the biggest, broadest picture. You’ll refine your goals as you go.

Consider your content. Having lists of what your content entails is a good process to go through. Audit what you now have and will need to have. Avoid organization the information until you have a thorough collection. The business goals can help to clarify what the content is.

Consider your users. Who is consuming the content? What are their goals, expectations, motivations, resources, and attitudes toward this information? Create personas about who will be consuming this information. Use user research techniques such as qualitative surveys, usability tests, and card sorts.

Consider your context. Context is where content meets users. Where does this information get presented? When would someone be looking at this information? What other information would go with? Write down various scenarios where the content would be consumed.

Visualize. Develop taxonomies, vocabulary, maps, flows, and analytics. Chart, graph, wireframe, and sketch ruthlessly. Create flow charts of strategic processes. Create broad road maps. We can process far more information visually than verbally. Use this to help take something overwhelming and bring it into something tangible.

Work from big to small. Start with big ideas and work your way to the details. The big picture will help set a framework which will set up the more detailed picture.

Integrate. Information architecture is part of the process of developing a product. It helps no one to have information architecture strategy performed, only to go unused. Strategically consider how to integrate the information architecture process into design and development. Make alliances and get people involved.

Thoughts or questions? Let us know in the comments!

Organizing and structuring creative projects

Here at ConceptCodify we focus our efforts and tool set for web designers, developers, project managers, user researchers, and others who are primarily building websites and desktop and mobile applications. We come from this background so it’s a good fit for our professional experience.

But in reality, almost any creative project can benefit from information architecture work early in the game. Ultimately, any form of design is about communicating information. Communication is key to any form of creative project. Just think about how information architecture strategies can apply to the following:

  • Music composition
  • Film or television production
  • Animation
  • Photography
  • Drawing, sketching and painting
  • Architecture
  • Writing articles
  • Books, novels, and screen plays
  • Choreography
  • Video game design
  • Business systems and processes
  • Poster design

Any creative project is ultimately going to center around communicating information to the user. How could card sorting and other information architecture strategies be applied to these endeavors?

Let us know what you think in the comments, or on Twitter or Facebook!

A winning strategy to accomplish any big goal

We’ve covered our process for launching projects and getting them out the door in our article series, the Lean Launch. Today we’re going to cover a more generic architecture, similar to a top down approach, that could cover nearly any project from a very high level down to the details.

1. State your mission.

Always start by defining what your goal is for the project. This will take some refinement. Here’s some questions to ask yourself to find your mission statement.

  • How would you describe the project to someone else?
  • What are the major functions?
  • What are the priorities of the project? How do they rank?
  • Who is going to be involved? What parts will be involved?

2. Determine the outcomes.

What are the requirements for your project? Again, start at a high level, a use your mission to determine what outcomes you expect your project to have. What will be included? What will not be included?

3. Arm yourself with information and resources.

How have things been in the past? Where are things going in the future? Do you need to conduct a survey or usability test? Gather information. Also, collect your resources. Who do you know who can help you with the mission? Who do you need to get on board? What tools do you have to complete your project?

4. Establish the system and processes. Get organized!

The next step is to form your plans to carry out your mission. We recommend keeping a high level few of things further out, and saving a more detailed approach for things upcoming soon. How will you use your resources and information? When? Set expectations for yourself and your team.

5. Work top down, back to front.

Start with the highest level and biggest, deepest ideas. Get feedback as quickly as you can. Iterate your way to your desired outcomes. Start with the deepest part, if that’s your database, or your users, whatever the core of your project is, and mind-map your way out as you work to carry out your goal.

6. Polish

Once you have the goals largely accomplished, spend the time it takes to get the details right. Get everything looking great, and consider each user. Get feedback on the smallest details, but only after you have a sound big picture.

Thoughts? Questions? Suggestions? Let us know!