Happy employees are great but fulfilled ones are better
Happiness is a temporary emotional state that comes and goes. Perks make employees happy. Free catered lunches make employees happy, so does higher pay and unlimited vacation, until it does not.
Fulfillment comes from being part of something greater than ourselves. It comes from being part of a worthwhile cause, from being part of changing the world for the better. Fulfilled employees will stick around when things get tough because they believe in the cause. Everyone deep down inside seeks to be part of something bigger than themselves.
Happy employees are great but fulfilled ones are better. Happy and fulfilled teams change the world.
Design thinking in the product development process
Design thinking is a non-linear process that gives teams the tools to understand users’ needs, wants, and team assumptions to create solutions that can be prototyped, tested, and eventually materialized into a product.
The design thinking process has become popular with teams over the past few decades and has been highly adopted by companies like Google and Apple. In simple terms, it is a process to solve problems in a human-centric way by allowing teams to focus on what is most important for users.
Despite its popularity and effectiveness, it is hard for teams to shift traditional waterfall thinking about design and problem-solving. Particularly, teams have a hard time understanding how to use the process and where to include other members of the team.
In a waterfall approach, product managers spend time to understand the problem, the business case, use cases, and the solution. It is after those steps that designers are included in the process to materialize the idea into deliverables such as visual designs. While this process solves the problem, it is my experience that many times it leads to incomplete, difficult use solutions. It also misses the value the design process brings when used with a cross-functional team to create better solutions for users.
Working with product managers over the years I have come to understand that it is not that they don’t understand the process or that they don’t see the value, rather, it is the understanding of when to include team members in the six steps.
The rest of the article is my attempt to take the six steps and align them with the different skill sets of team members. While you can include the entire team in these steps, I understand that it is not feasible for many teams. Jake Knapp in his book Sprint, takes these steps and cramps them into a one week block. He makes a good case for why you should include a cross-functional team in all the steps, but the process is flexible enough to allow teams to benefit from it and adopt a version that best fits their team.
While reading through the different steps imagine your goal is to improve new users’ profile set up. Keep in mind that my examples are based on a team that works on a software product, but the principles still apply. The process is also not limited to products. It can be used to improve product support or services offered by a company.
Empathize
This phase is about developing knowledge of what users do, say, think and feel. This phase can be done primarily by the product team with consultation from designers, sales, support, marketing, and engineers. This is where teams would directly observe what users do and ask questions like what motivates or discourages them. Teams at this point are trying to identify the pain points in the current process users follow. It is important to document the findings to carry them over to later steps. Teams can document facts, assumptions, and opinions on sticky notes, a whiteboard, or anywhere else that these ideas can easily be seen by the team.
Define
With all the research data from the empathize step, teams can begin to identify opportunities in the process where they can innovate. At this point, the focus is not to come up with solutions. In our user profile setup example, think of what are the common pain points the team saw across different users. This step can be conducted with a broader team in the room and at the same time as the next step. Consider including designers, engineers, support, marketing, and sales if possible. Depending on the difficulty of the problem, designers and engineers may be enough. Teams can choose a set of skill sets that best fit their process. In my experience in this step and the next, the more representatives from other parts of the business are involved, the more wholistic the solution will be.
Ideate
Once teams understand the users’ needs and have identified areas to improve, teams can begin to explore solutions to solve the problem informed by the research. Ideas can come from anyone, not just designers or product managers. Anyone can wireframe an idea and share it with the team. The goal in this phase is not to scrutinize ideas on why they would or wouldn’t work quite yet. The goal is to come up with several feasible solutions that solve the problem. Once multiple ideas are in front, then the team can go through the process of identifying the pros and cons of each solution. A good result would be that in the end, one idea wins as a favorite of the team. This usually tends to be a mix of all the best parts of the ideas presented. In this step, you want to have everyone in a room. Include different members with different functions in the product development process as well as members of outside groups if it makes sense. Support can usually provide good feedback and whether an idea will help based on what they hear from customers during support calls.
If there is more then one good idea considered as a possible solution that is also fine. The next step is to build a testable prototype.
Prototype
Depending on what kind of product your team is working on, it will require different skill sets to build a testable prototype. In this article, we are focusing specifically on software products. The designer would be the primary member responsible for putting the testable prototype. The goal of this step is not to build a high fidelity prototype. It needs to be finished enough to communicate the intent to the user. It can be in the form of a Powerpoint presentation, an InVision wireframe. It needs to feel as real as possible without spending so much time on it that it cost too much to build. It has to be built with the idea in mind that it might be discarded because it was the wrong solution. This is a hard concept for teams because they may have invested so much time into it. That’s why it’s best to not build high fidelity code prototypes unless they are proof of concepts that eventually will become part of the implementation.
Test
The testing step is about putting your prototypes in front of users. In this step we are looking for the answer to the question ‘Does the solution meet the needs of users?’ Anyone can observe a usability test, but only one person should speak and moderate the interview. Everyone else should be in a separate room observing and taking notes. The goal is to test the solution, not make users feel like they are being tested or interrogated.
Implement
The final and the most satisfying part of the design process is the implementation. After all, this is the reason teams go through the process. To deliver solutions. In software development, this step is usually performed by engineers. It is an important step because teams want to make sure that all the research and effort that went into finding a solution is not missed or discarded. Introducing new concepts without going through the process again leads to hard to use products and more pain points.
Conclusion
In his book Sprint, author Jake Knapp provides a step-by-step process to cramp these steps into a one week block. Whether your team can do that or not, the goal is the same, to build products that are centered on the users’ needs and build them in a way that reduces the cost of doing so. The process is non-linear. Meaning that if at any point discoveries happen, the team can return to any of the previous steps and rethink the problem, assumptions, and the solution.
The thing about controlling the outcome is that it is not possible
It doesn’t matter how much we try, the outcome is the outcome despite of our intentions. We can’t convince the prospect to buy our product or service.
The only thing we can control is whether we did our best work at the time. Even if we followed everything by the book, the desired outcome is not guaranteed. Sometimes the book works, sometimes it does not.
All we can do today is do our work with excellence, and when it doesn’t turn out like we thought, try again.
All we can control is the input.
Nothing is for everyone, quit building your product that way
Not everyone buys iPhones, Teslas, or uses Gmail. It gets even more complicated when we build enterprise products that are used by different people for different purposes. While Gmail allows you to read, send, and respond to emails, it does not try to help you edit a spreadsheet. It has a separate product more appropriate for that use.
In product development, we invest a lot of time creating personas. Ignoring the needs of these personas and what they are looking to accomplish with your product can lead to building something that tries to be everything for everyone. It will probably lead to a very complicated feature or product.
If something is for everyone, then it is for no one.
The challenge is to identify when to break up the product or feature into multiple pieces. Anyone who has worked with personas before knows they have different needs. Knowing who is it for is a good place to start. Once we know the needs, we can ask ourselves if it is for them?
When the answer is no, we have found a way to simplify. When we find ourselves answering no more often than not, it might be time to break things up.
It starts with knowing who is it for and what they need.
Disney will not wipeout Netflix and Slack will be OK
Despite the popular belief by short-term investors, Disney will not drive Netflix out of business. Netflix is in the long tail business. Meaning they stream as much content as they can that is no longer popular in today’s week of entertainment, but it still loved. The long tail does not depend on Friends or The Office because most shows that make up the long tail are not producing the same revenue for studios as they were when they were new and fresh.
It cost Netflix an approximate $48 million to make Stranger Things. Disney spent over $300 million to make Avengers End Game. That means that Netflix can retry to find the next Stranger Things about 6 times. Even if they are successful only 50% of the time, that is 3 hit shows or movies. It’s way cheaper to play in the long tail than it is to dominate the blockbuster market.
Neither will Microsoft drive Slack out of business. 20 million users signed up, but it doesn’t mean their teams switched. The evaluation of a new team collaboration tool is not one week for the majority of teams. In the short term Slack’s stock may drop, and so will Netflix. It would be an underestimation of the impact by short-term investors to think it is the end for these companies. Netflix is the company that has innovated and ate its revenue several times by pivoting, not once, not twice, but thrice. From delivering DVDs in the mail to streaming online, to creating it’s on original content. Disney is playing catch up, not innovating.
That means they missed the next wave of innovation by a few years or what Clay Christensen calls, the innovator’s dilemma. They failed to eat their own lunch and missed the next innovation in television content. Although, they are big enough and have enough resources to catch up some.
Netflix is doing fine, they are playing the long-tail game.
Nick Fury knows how to assemble a team
“The idea was to bring together a group of remarkable people, see if they could become something more. See if they could work together when we needed them to fight the battles we never could” -Nick Fury
It starts with people who care, who want to make a difference, people who take the initiative to do the work. No one has to tell them to start the project, they start it and ask others to join.
Then, of those that care, they must possess remarkable potential. Here is a hint, if you care, you are full of potential.
The last ingredient is purpose. Once you care, once the potential is there, then you need purpose. Fury assembled the Avengers to save the world. He gave them an opportunity to channel their extra ordinary potential to do something much bigger than themselves.
They stepped up because they cared, and had potential. They stepped up when someone gave them a purpose beyond themselves.
Nick Fury knows how to assemble a team.
The constraint of quantity over quality in product development
Delivering a feature is not the same as delivering a quality feature. It may do what it is meant to, but most likely it is full of small details that make it hard to use, scale or understand.
The constraint between delivering features constantly because it adds business value “now” is one that teams constantly face. The challenge with delivering earlier by sacrificing quality is that it compounds. This is especially true if multiple teams are adding to the product simultaneously. If everyone sacrifices quality with the mantra “we will fix it later”, it probably won’t be fixed because the team didn’t see value in it in the first place. The business wants the next feature they can sell. Eventually, it adds up and probably will require redesigning the whole feature or product.
The same problem is true for engineering. The challenge with making short term solutions to deliver now is that many short term decisions hurt the long term. It may work for a start-up working on a minimum viable product (MVP), but MVPs don’t sacrifice quality, they sacrifice capability. Don’t hide your willingness to sacrifice quality behind the idea of an MVP. It’s not the same.
If you want to scale your product, you have to consider the long term over the short term benefits. What if you could have the feature 2 weeks later, but increase quality by 10%. What if you did that for every feature? Will 10% accumulate the same way over time?
I always tell co-workers that we are either making our product incrementally better or incrementally worst. It’s never a leap. One compromise is not so bad when you know you are sacrificing the quality for the capability in the short run knowing that the next step is to improve quality. When everyone is compromising quality to deliver early, it adds up.
Are you an engineer? Is your current implementation setting your team up to deliver quality later? Or does it just meet the requirements?
“Our users are old, they are not good with technology”
Said the Product Manager frustrated after hearing about all the support calls from customers with questions about how to use her product. “You haven’t spent time with them as I have” she insisted.
But is it true? Are they incapable of learning how to use a piece of software? Is it better to say that we are bad at empathizing with our users? Is it more probable that we are designing for ourselves rather than the people we are seeking to help? Could it be that we are not good designers, yet?
After all, I have seen many grandparents with smartphones using social media to post a lot of grandchild cuteness. Somehow they figured out how to use a smartphone, download an app, register an account, and post a photo.
It might be a fact that her users are older and less tech-savvy. The goal is to understand their challenges and design for them. It doesn’t matter how I use the app, it’s not for me.
No one buys an ugly car because it’s ugly
Maybe some people like ugly cars, but the rest of us like beautiful cars we can afford. We even like the ones we can’t.
Beautiful things are easier to sell than ugly ones. We maybe overlook aesthetics for performance, but all things being equal, most of us will choose the shiny object.
Of course, beauty is not enough on its own. A beautiful woman and a handsome man must deliver on their promise of being a good partner.
Beautiful apps sell better than ugly ones, but they still need to deliver on their value proposition. They still have to do what they said they would, but all things being equal, it feels good to use a beautifully designed piece of software.
Something to think about the next time developers poke fun at the designer because she makes pretty pictures. All in good fun of course. We all like beautiful things, except when they are not useful.
Developing with accessibility in mind
What is Accessibility?
Accessibility or A11Y for short, in its simplest terms, means making the content and functionality of a website or app available by anyone regardless of disabilities. When most people think of a disability, they think of someone with a permanent medical condition such as blindness or other physical condition that limits their motor or cognitive abilities. While that view is true, there are other types of disabilities that we should consider when creating software products. An individual can have a visual, motor, hearing or cognitive disability. These disabilities can be further categorized into situational, temporary or permanent. When we develop software, we have to consider individuals with permanent disabilities as well as those with temporary ones like a broken arm or situational disabilities like sitting at a café with the sun shining on their screen
Web Content Accessibility Guidelines
The Web Content Accessibility Guidelines (WCAG) was put together by the World Wide Web Consortium(W3C) as a list of best practices to provide a methodical way for developers to implement accessibility on the web. These guidelines were taken by the Web Accessibility in Mind (WebAIM) group and turned into a checklist to use during the development process. WCAG is based on the following four principles:
- Perceivable: Web Content is made available to the senses – sight, hearing, and/or touch.
- Operable: Interface forms, controls, and navigation are operable with different forms of input devices.
- Understandable: Information and the operating of the user interface must be understandable.
- Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents including assistive technologies.
Accessibility during development
Focus
The simplest place to start with accessibility is by looking at an element’s focus state. All interactive elements such as links, buttons and form controls, as well as custom interactive components, should have a focus state. You can see an element’s focus state by using the tab key on the keyboard. Different browsers style the focus state differently. Firefox uses a dotted border while Chrome adds an outline around focusable elements. It is possible to remove the browser’s default focus styles with the outline CSS property, but make sure to always add a custom visual state with the CSS sudo-class :focus when you do so.
Click here then press the tab key to focus on the buttons
Order
Browsers organize elements on a page into the Document Object Model (DOM). The browser takes all the elements rendered on a page and it creates a nested tree-like JavaScript Object, the DOM, in the browser’s memory. This object is used to determine the order in which elements receive focus while using the tab key on the keyboard or other assistive technologies. It is possible to change the visual order of elements with CSS by changing the float property or positioning an element at an absolute location on the page. Keep this in mind when changing the visual order of elements. In the example below the first set of buttons are in the same order as the DOM tree, while the second set uses CSS to change the position of the first button. When developing you want to keep the visual order and the focus order the same to avoid confusing those using the keyboard or other assistive technology to access the application.
Click here then press the tab key to focus on the buttons
Tabindex
The browser provides a default tab order base on the DOM tree for native interactive HTML elements. There are cases when it is desired to change, remove, or prioritize the order. This is useful especially with custom components that may use non-focusable elements in their implementation. For that purpose, the tabindex attribute can be used on any element that otherwise would be ignored by the focus order. Adding tabindex=”0” to any element will cause it to take on the natural focus order in the DOM. tabindex=”-1” removes an element from the natural focus order and causes it to be skipped. Both are useful when creating custom components such as a select menu or a button that uses non-focusable elements like [divs]. It is possible to add a tab index number greater than 0 causing the element to jump to the front of the focus order, but this is considered an anti-pattern and should not be done.
Click here then press the tab key to focus on the buttons
Focus 2 Div with tabindex=”0″Semantics & ARIA
Many elements give meaning to the layout of a page. It is important to use these elements because they help assistive technologies like screen readers communicate to users the structure of the page or the purpose of a piece of content.
Headings
Use the proper hierarchy when using heading tags (H1, H2, H3, H4, H5, H6). Visually making text bold may be helpful for most users, but it provides no meaning to the page. Think about these as a list of related groups like a table of contents. Based on this structure, you should be able to identify sections and sub-sections within the page. Normally there is only one H1 heading on a page and all the sub-sections would follow the perspective hierarchy. Heading on sections of the page help users and screen readers quickly identify the purpose of the section. Studies have shown that people scan a page rather than reading line-by-line. Once they find something of interest, they narrow down the focus to the details of the content. Use headings to identify your sections.
HTML5 Semantic elements
HTML5 introduced a new set of elements that behave exactly like a [div] does. They are block level elements that add no style but introduced meaning to the content they hold. Use these elements instead of a [div] when appropriate to communicate content meaning within a page or components: header, footer, nav, article, section, main, aside.
Examples of using semantic native elements include using tables to display tabular data instead of implementing a layout Use the <p> element for regular body text, an <a> element for links and a <button> element for buttons. Many of these have a special meaning for assistive technologies but also include default accessibility functionality. One simple practice is to never leave an <a> element without the href attribute because it changes how it is accessed with the keyboard. It is a better practice to use a button if there is no link and style the button with CSS if you need it to look different.
Link and button text
The text used for links and buttons should be descriptive to help people with accessibility technologies better understand what they will be doing when they click them. It is clearer for everyone to use the following text for a link; “click here to learn about accessibility” than to simply use “click here to learn about accessibility”. It would be even better to omit the “click here” text altogether and use “learn about accessibility” on its own. A screen reader would not tell a user what to expect if they click the link reading “click me”. You can also use the ARIA specifications to add meaning or change labels for screen readers and other forms of accessibility technology. It is specifically helpful for buttons and other form controls. We will cover this further in a bit.
The Accessibility Tree
Screen readers build an accessibility tree to help users make sense of a web page. The accessibility tree is similar to the DOM tree except that it takes the semantics elements and allows the user to sort, skip, or jump to different elements such as links or buttons on the page. Important elements are also known as landmark elements.
New frameworks like React and Angular have allowed developers to create custom components that don’t have the same semantic meaning as some of the native elements. To solve this problem the Web Accessibility Initiative’s Accessible Rich Internet Applications specification (WAI-ARIA or just ARIA) was created. It allows developers to use a set of predefined attributes that modify the way an element is translated into the accessibility tree. This is great for custom components because developers can use elements without meaning like the [div] to create rich interactive components and still make them accessible through screen readers or other assistive technology. It also allows you to change the meaning or add better descriptions or labels for accessibility tools.
ARIA
The ARIA specification provides a set of attributes that allow developers of accessible rich internet applications to provide screen readers with information so that they can properly interpret the elements. Examples of these include the role and the aria-label attribute. role could be used when creating a custom checkbox, slider or dialog. Assigning the attribute role=”checkbox” would communicate to screen readers the purpose of the component. [aria-label] allows developers to add a string that is used to describe an element but has no visual impact. Think of a button or link with only one word as its label text. aria-label allows you to override the text description for screen readers without changing the visual label. You may have seen these attributes in the source code of component libraries. I will not cover the ARIA specifications here; the basics alone warrant its own article. Be aware that you can use it to add meaning to your application and help make it accessible to users that depend on screen readers.
Styles, Color, and Contrast
When styling elements ensure that all interactive elements have a focus style. If the company’s branding is different from the browser’s default focus styles, ensure that a custom focus style is provided.
Beyond interactive elements do not depend solely on color to communicate element status or purpose. Red text color is great to display an error message to most users, but someone who is colorblind may not know it is an error. The same is true for someone using assistive technology to access the application. The ARIA specification can help you add meaning to these types of components and make the application accessible to a wider range of people.
Similar to color blindness, there is also a part of the population that has low contrast vision. They are not able to easily see elements or text with low contrast. When selecting a color pallet, select colors with enough contrast between the foreground and the background for people with such a condition to see it. Contrast is also an issue depending on lighting conditions. This would be an example of a situational temporary disability. Think of the earlier example of the person sitting next to a sunny window.
Responsive Web Design
Last but not least, there is Responsive Web Design (RWD). HTML5 and CSS3 made it possible to create web pages that resize and adapt the layout based on the size of the screen the user is on. RWD makes applications accessible across different devices without the need for separate source codes. This is great for reducing business costs, improve the user experience, and speed up the delivery of features across multiple devices. Avoid using tables to create the layout. Tables are meant to display tabular data.
Conclusion
Making applications accessible is not a complicated process, but it is one that has to be done with purpose. Accessibly like the user experience, is about empathy for the limitations that users face while using the software we create. Those limitations can be visual, motor, hearing or cognitive and furthermore they can also be situational, temporary or permanent. Accessibility solutions should follow the WCAG list. An interface’s accessibility can be judged by asking if the feature is perceivable, operable, understandable, and robust. These are the four principles WCAG is based on.
When implementing a feature use the following checklist to test it for accessibility:
- Ensure interactive elements are accessible without a mouse and with a screen reader. You can use a screen reader plugin on your browser to get an idea of how someone would be able to use our software with it.
- When an interactive element is in focus, make sure visually the styles change and it is obvious what is in focus.
- Maintain the visual and focus order of elements the same.
- Use native semantic elements for content and use the HTML5 semantic elements where appropriate.
- When creating custom components use the ARIA attributes to make these elements accessible to screen readers.
- Don’t rely solely on color to communicate meaning and make sure that colors have enough contrast.
- Test the application on different screen sizes, make sure that it is still accessible on different devices.