Links and articles about technology, design, and sociology. Written by Rian van der Merwe. Follow @RianVDM
Marty Cagan wrote one of his characteristically great posts in Product vs. IT Mindset. In one particularly harsh section he describes what happens when the people who make decisions about a product are far removed from those who make the product:
In IT mindset companies, accountability frankly is a farce. The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due. In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault. So management writes it off as yet another failed technology initiative. In contrast, in a product organization, we are measured by results.
I’ve always felt that this is the biggest challenge to companies as they grow. The further away those who make decisions are from those who build the product, the harder it is to remain customer-focused in the long term.
I try not to overwhelm you with posts about the product management book I wrote recently, but I do think this deserves a post. After a few hiccups, Making It Right is now available in paperback on Amazon, through CreateSpace Independent Publishing.
If you like papery things and margins, I’m sure you will like it.
Peter Morville’s Creating a Cultural Fit: Using ethnography with users and stakeholders is one of the most useful UX articles I’ve read in a while. He talks about the importance of understanding the cultures of both users and companies to create good products. He concludes:
In short, the right design is one that fits the company and its customers. A mismatch on either side results in fatal error. We must use ethnography with our users and stakeholders to search for a bi-cultural fit. This is tricky since culture is mostly invisible. That’s why we should start with a map.
This is a must-read.
Thank you to Mandrill for sponsoring Elezea this week! I’m a big MailChimp fan, and this is another great product of theirs.
Integrate, deliver, track, and analyze with email infrastructure from Mandrill.
Mandrill is a scalable, reliable, and secure email infrastructure service trusted by more than 300,000 customers. It’s easy to set up and integrate with existing apps. And it’s really fast, too. With servers all over the world, Mandrill can deliver your email in milliseconds. Detailed delivery reports, advanced analytics, and a friendly interface mean your entire team—from developers to marketers—can easily monitor and evaluate email performance.
Get started with Mandrill today.
Sophie Shepherd introduces some new deliverables in Rethinking Our Prototypical Process, including this one:
HTML prototypes have the potential to confuse some clients. In addressing feedback, I’ve answered questions like: Are we tied to this layout? (No.) Is this real content? (Ideally.) Is this what our website will look like? (Probably not.) The content outline strips any potentially distracting elements from the prototype: no layout, no typography, no links, no things remotely resembling design. It’s just a list of the content that will be on each page in order of its importance.
This deliverable, which she calls a “Content outline” or “Page description diagram”, seems like it fits well with my idea of Content slice diagrams. It’s great to see these new useful deliverables emerging — a sensible retreat from the “get out of the deliverables business” march of the past few years.
Craig Mod discusses single-purpose products in his product design essay There is much to learn from the paper towel:
All of these single-purpose tools or philosophies strive towards the same goal: whittle away the cruft around an idea to reveal its most base components, and in doing so, strengthen what is left.
The single-purpose lecture attendee is, in theory, a better student. The single-purpose-sized paper towel makes us happier, is gentler on the earth. Individual tools in unix are more efficient and easier to debug because of their specificity. Facebook Messenger on its own is easier to use to communicate without the deluge of Facebook notifications flying in our faces. And so on and so forth.
I really like Alex Maughan’s post In a word, Human. He discusses the dangerous gap between those who make software, and those who use it:
Successful user experiences happen when producer whims get sidelined, and primary focus is placed on that little bit of common sense shared by the majority of humans using your product or service. It’s when you empathetically put yourself in the most common psychological flow of a human using a piece of technology they know almost nothing about.
This is a topic I’m very passionate about, so I agree wholeheartedly with Alex.
Usually we use a bunch of different software for creating such things as websites, presentations, photo stories and online magazines. The truth is — it all can be done easier and with one tool.
Do design, forget about coding.
Readymag provides a simple online tool for designing and publishing all forms of content, helping to focus on the creative process, rather than interface complexity and code. Among the main Readymag’s features:
- Viewport: Easily create responsive layouts for mobile deviсes.
- 1500+ free web fonts: From Typekit, Webtype and Google Fonts.
- Password protection: Create private publications and share with specific audience.
- PDF-export: Save and view your work offline.
- Ready-to-use templates: Made by talented designers from around the world.
- Plus: Free hosting, custom domain and analytics.
Stay creative. Try Readymag now for free.
Sponsored via Syndicate Ads
Just as my 5-year old exits her Dora the Explorer phase (to replace it with “Let it go! Let it gooooo!”), my 2-year old enters hers with the force of a thousand purple monkeys. So, look, I read a lot of Dora books these days. Recently Penny the Pony’s Big Race has been quite the hit. It’s about Dora trying to get her horse to… wait, who am I kidding. I’m sure you care about the plot as much as I do.
Anyway, there’s one part of the story that irritates me way above my average annoyance levels with these books (which is already quite high). Dora, Boots, and Penny are trying to cross a mud pit, but Penny is a bit scared. This is where we pick up the narrative:
Let’s reflect on this for a moment. Penny is scared of jumping across the logs, because she thinks she might slip and fall into the mud. Dora’s proposed solution is infuriating:
Uh-oh! Penny is afraid that the logs might be slippery. Let’s count the logs as she walks across so she won’t be worried.
How is that a good solution? There are a number of things you could do to solve Penny’s fear of the slippery logs. They could walk around the mud pit. They could make sure the logs are more secure. They could give Penny special horse-shoes that increase friction. Look, I don’t know, I’m not an expert at horses jumping over logs, but I’m sure there are people who are, and who could come up with a good solution for the problem. Counting the logs to distract Penny is a pretty superficial and condescending approach to address this particular problem.
The thing is, this is all too often how managers operate in the context of their teams. Oh, you’re unhappy with the culture of the company? Let’s throw a company BBQ. On a Sunday afternoon. You’re concerned that the product development process is not optimal? Let’s hire another development manager. Instead of spending time to understand the cause of the anxiety communicated by team members, managers often rely on distraction or easy answers that give the illusion of a solution, but is nothing more than a way to check a box to say that they “did something.”
I read two really good management articles recently that are relevant here. The first is Gregg Satell’s What To Do While You’re Waiting For Steve Jobs (beware, that’s a Forbes link, so you’re going to have to do a lot of clicking around to dismiss all the things that try to distract you from reading it). He says this about treating people with respect:
If you expect your employees to be motivated to do their jobs well, you’d better treat them with dignity. Leadership is not the art of getting people to do what you want, but inspiring them to want what you want.[...] While many leaders believe that they can bend the organization to their will, that’s rarely true. Being a jerk doesn’t make you Steve Jobs, it just makes you a jerk.
The second is Lindsay Holmwood’s It’s not a promotion — it’s a career change. It’s a great post and you should read the whole thing, but I want to quote most of the opening in full, because it’s great:
Your job is not to be an engineer. Your job is not to be a manager. Your job is to be a multiplier.
You exist to remove roadblocks and eliminate interruptions for the people you work with. You exist to listen to people (not just hear them!), to build relationships and trust, to deliver bad news, to resolve conflict in a just way.
You exist to think about the bigger picture, ask provoking and sometimes difficult questions, and relate the big picture back to something meaningful, tangible, and actionable to the team.
You exist to advocate for the team, to promote the group and individual achievements, to gaze into unconstructive criticism and see underlying motivations, and sometimes even give up control and make sacrifices you are uncomfortable or disagree with.
You exist to make systemic improvements with the help of the people you work with.
If I could summarize the advice in these articles, and what I’ve personally experienced about good managers vs. bad managers, I’d say this. If someone on your team complains that they’re worried about slippery logs across a mud pit, don’t tell them you’ll count loudly as they jump to distract them from the fear. Instead, take the time to understand the cause of their fear, and help them solve the real problem behind that fear.
In other words, don’t be like Dora. She’s a terrible manager.
A while ago I wrote about expanded customer journey maps as a way to plan for device-agnostic design. But that document is only half the story. Expanded customer journey maps are great because they force us to plan what content will be needed before we move to page layout. That provides a great starting point, but crossing the chasm between knowing what content should go on a page, and how to design the best layout for that content can still be quite difficult.
What we need is an effective way to make content hierarchy decisions across all pages so as not to lose sight of the overall consistency of a site. Enter Content Slice Diagrams as a way to accomplish three fundamental tasks:
- Get an overview of the content across a site to make sure nothing is missing and there is consistency in layout where appropriate.
- Design the right size and hierarchy of each of the content chunks on a page, and see how it affects the page as a whole, as well as related pages.
- Provide any guidelines that writers may need to keep in mind as they create the content for the site.
Once the content slice diagrams are completed, designers and writers should have the following information:
- A clear understanding of the hierarchy of each page, which leads seamlessly into mobile first layout design.
- What the structure and nature of the content in each chunk will be.
That’s everything you need to start working on layout. As an example, let’s say you’ve worked on the content plan (see my post on expanded customer journey maps for an example), so you know what type of content needs to be on a page — but you’re not sure how to lay it out. A Content Slice Diagram can help:
What we have in the image above is a list of pages that goes from left to right, with rectangles representing content chunks on the page. Calls to action and optional modules are given a different color so that they’re easy to differentiate. When we did this for a travel site we realized that we sometimes had the call to action in a different spot, so we were able to get consistency across pages. We also moved the content chunks around until we arrived at a hierarchy that made sense.
You’ll notice that this looks suspiciously like the layout for a mobile screen… That wasn’t the original intent, but it ends up being a welcome side effect of doing content slice diagrams: it’s a great blueprint for mobile first design.
Once the hierarchy is set, you can create content guides for writers to give them the structural information they need to start writing:
When I brought this technique to HealthSparq, my colleague Allan White had a great idea. He rightfully commented that OmniGraffle doesn’t make it particularly easy to drag content chunks around quickly. So he decided to use Trello instead. It allowed him to have collaborative meetings with the Marketing and Development teams as they discussed the hierarchy of each chunk:
As I’ve mentioned before, I hate needless deliverables as much as the next person, but I really like deliverables that help us design better products. And I think Content Slice Diagrams make for a great addition to the tools we have at our disposal to design device-agnostic, content-first experiences. Use at will, make it better, and let me know how it goes!