Spark

Subscribe via Email

Subscribe to RSS feed

Archives

Archive for the ‘UX’ Category

Are Two Pizzas Enough?

2 Pizza TeamsImagine being an executive for one of the largest pizza chains in the world and being invited to a meeting titled “Why Two Pizzas Are Enough”. How would you react? Would you be concerned a few zeroes had been left off? I did a contract role as an agile coach for just such a major pizza chain a few years ago. When it was time to give the executive management team an overview of Agile and Scrum (the specific methodology the company was interested in implementing) I was advised to not call the meeting Agile or Scrum. After asking why I should avoid this I was told that the business was sick and tired of hearing about both Agile and Scrum and they wouldn’t come if they knew what it was about. I used the analogy of two pizza teams to grab their attention and boy did I grab their attention! Every Executive attended the meeting.

In last week’s article “Agile and UX Design: Can they work together?” I mentioned the concept of a two pizza team. In this article I give more definition behind this concept and how it applies to agile approaches.

The two Pizza team terminology was coined by Jeff Bezos, founder and CEO of Amazon. You can read more about his concept and how it has become part of the culture at Amazon by reading the Fast Company article “Inside the Mind of Jeff Bezos”.

What is the two pizza team analogy? In Scrum, and most Agile methodologies, the team is meant to be a small, cross-functional, empowered team of approximately 5 – 9 people, depending on the project size. Therefore when your team has to work through lunch or late into the evening, as you know you do when you work on a project, the company can feed the team with two pizzas. I.e. Two pizza teams.

There is more accountability in smaller teams and they tend to avoid the issue of social loafing. According to social psychology, social loafing is the phenomenon where individuals tend to put forth less effort when working in a group than when they are working individually or coactively. Small teams in which each member is accountable for specific tasks for the project will avoid this concern and hold each other accountable on a daily basis for the work being produced.

There is, on occasion, a concern raised with the small number of team members when a project may be extremely large and require more than the recommended 5 – 9 person team. In this event, review the project goals and determine a team structure in which multiple Scrum (or whichever agile methodology is being used) can be structured reporting into one Project Manager or Product Owner (whichever role title your project is using). In many projects a quick review of the goals or epics will show a natural delineation into individual teams. These teams should be able to communicate with each other, but limit the communication paths necessary between the teams. In other words, if team A is unable to complete their work because they must first coordinate with additional teams the project will stall. Minimizing communication overhead while still encouraging communication between teams is a key strategy to the success of multiple teams within the same project.

Try the two pizza team concept when your organization on a smaller scale first. Something as simple as a meeting in which a decision or consensus needs to be reached or if there is a larger problem which you are attempting to solve, break it into smaller chunks and assign a small team to each chunk to solve. See how quickly and effectively these small teams can work. Not only will your problem get resolved, your corporate lunch bill will go down.

Agile and UX Design: Can they work together? Part One

Diet pills and Agile have a commonality – people want a quick fix to lose weight only slightly more than they want a fix to all their project management issues. Unfortunately, diet pills nor agile are silver bullets to correct either concern. It takes dedication, work and an understanding of the principles behind the body’s metabolism to lose weight. Likewise, it takes dedication, work and an understanding of the principles behind agile to improve delivery of a project. Once you understand these principles you can become a two pizza team, improve project delivery and lose weight at the same time.

This is the first part of an ongoing series attempting to not only bring clarity to what it means to be agile, but also to answer the question, can agile methodologies work during the UX design phase of a project? I have heard arguments on both sides of that debate. Many designers saying ‘no’ it doesn’t work and the more traditional waterfall methodology works best. Why? Because you have to business requirements before you can start wireframes and you have to have wireframes before you can start creative design. Before starting creative you have to have a content strategy which depends on the wireframes, which depends on the business requirements and on and on. While I am not arguing these needs I want to explore the possibility of providing these needs within an agile process.

But, before the exploration of this feasibility can begin let’s first define what agile means. I hear the word tossed about to describe a single methodology of project management or software development. Ask a project team what methodology they are following and often you hear “we are using agile”. What does that mean? Each week we change our process because we didn’t like what we did last week? Or, the client wants us to change how we are doing things because they didn’t like what we did last week? That isn’t agile, that’s chaotic and reactive. So, what is agile?

It’s difficult to define as agile is an umbrella term for multiple approaches to project management of software development projects. At the core, agile is a group of methods that enable small, cross-functional teams to quickly deliver business value in an iterative, collaborative approach. Where change is expected, not feared and where requirements can be expanded upon as the team learns more. Where conversation and collaboration are valued over strict adherence to a set plan defined before the requirements are even made clear to the customer, let alone the team.

The agile manifesto describes the values and principles of agile software development practices and I won’t take the time to reiterate them here, but if you don’t know them I suggest checking out that link. The manifesto itself is made up of four key values supported by twelve principles.

Agile Manifesto Values

Agile Manifesto Values

Some agile methods which exhibit these values and principles are:

• Scrum – arguably the most popular
• Kanban
• XP (Extreme Programming)
• Lean Software Development
• Feature Driven Development
• DSDM (Dynamic Systems Development Method)
• Crystal

This is not an exhaustive list of all agile methodologies, but some of the more popular ones currently in use. Which of the approaches to use depends on the team’s knowledge and expertise in each methodology, their culture and sometimes the project goals.

Making a move to agile is a cultural change that impacts the entire organization, not just the IT department. It’s a marathon, not a sprint. An evolution not a revolution. There is compelling evidence that iterative methods reduce project risk, compared to more traditional waterfall approaches. Next time we’ll move into the discussion of bringing Agile and UX together.

In the meantime, have you been involved in a cultural shift to using agile? What pain points did you find and how did you resolve them?

Abstracting the UI Layer

Last month at the IBM Digital Experience Conference, Shyam Sunter, a Perficient Technical Solution Architect, and I presented on a method for abstracting the user interface code (HTML, CSS, and JavaScript) out of WebSphere Portal. A key part of this presentation was going over why this abstraction was important.. It’s of my opinion, that abstracting the UI code out any platform, be it WebSphere Portal, Sharepoint, SiteCore, what have you, is vital for building modern, cross channel digital experiences. Supporting an abstracted UI layer is a common practice for many digital platforms, especially in the start up space. It’s time that the enterprise world starts to consider adopting this practice as digital solutions become more pervasive and complex.

 

Diagram showing the various layers that make up a user's digital experience.

Elements of User Experience

 

For a long time now, User Experience professionals have been working in a world of abstracted layers. This is best illustrated by Jesse James Garret’s famous 2010 diagram of the Elements of User Experience. Even when the web was simply made up of two layers, structure and style, designers used these abstracted layers to map out the overall structure, information design, behavioral touchpoints, and visual design elements of a given solution. As the web matured and additional technical layers were added, such as behavior, content, and contextual awareness, these layers became more important for us to work through and support. Modern digital solutions, such as Disney’s My Disney Experience, Airbnb, Uber, and many many more, are ones built on top of these abstracted layers so that their overall solution is more scalable and maintainable.

Modern Web Architecture

Several other benefits manifest themselves as well, including:

  • Design teams being given ownership and control over the development and deployment of the user interface layer. Design is naturally an iterative process, which involves creating and testing various solutions to a given problem. Having control over the UI layer, gives design teams the freedom and flexibility to try out new solutions and to simply “play” with the overall design.
  • Publishing UI code more frequently. With the control of the UI layer living in the hands of the design team, code can be pushed out more “real time”. This doesn’t always mean to the production environment, but users and stakeholders are able to touch, feel, and play with a new design quicker and in a realistic environment.
  • Easier to support cross channel solutions. It isn’t news that the days of people being chained to a desktop computer and chair are over. But, the new world of multiple digital devices and varying resolution sizes is a still new, and it’s really complex. By supporting a stand-alone UI layer, it’s easier to contextual deliver the right design for the right environment.
  • Proper support for accessibility standards. Accessibility doesn’t just apply to UI code, but a good chunk of it does. If you don’t have a backend platform interjecting its own code or compiling code that a UI developer has written, many accessibility issues can be addressed in a more streamlined fashion.

 

Ultimately why does having an abstracted UI layer matter though? Because there is no such thing as just having a website or just having an app anymore. It’s about providing a digital service that people can interact with, play with, and enjoy at any time from any device. Many things go into ensuring that the resulting experience is a pleasing one, but taking the time to build a UI layer that isn’t, at least fully, dependent on a backend platform is one of the key methods for properly serving people who use your digital solution.

Designing From A Fresh Perspective

As a designer, its easy to fall into patterns that conform to established models. But to truly innovate, you must bring a fresh perspective to every design challenge. I was recently reminded of the value of a fresh perspective, when my 7 year old daughter took on the challenge of making a computer for her American Girl Doll. Because we all know that any self-respecting doll, has gotta be connected.

IMG_3311

American Girl Doll Using Her Laptop

However, this was not an ordinary computer. It was a Mac, which was already enough to make me proud. But it was also customized to her doll’s very specific needs. First of all, it was purple, which is the doll’s favorite color, it was also sized perfectly so that it could fit into her purse and it even had a rear facing camera to take pictures of the other dolls while she was on “Facebook.” But what amazed me the most was the keyboard layout. Yes it included most of the typical numbers and letters that you’d find on a keyboard. However this keyboard was also personalized. It had special keys for her email address, zip code, and Facebook username “in case she got tired of typing.” This really made me realize how much I hate typing in my email address all the time, especially on mobile devices. Wouldn’t it be great if I could have a single key that take care of that for me? Yes, I know most web browsers retain email inputs to support an autofill function, however mobile browsers typically don’t support that capability as well. And in mobile interactions, that capability would have most value.

IMG_3313

Personalized Keyboard

In designing her computer, my daughter never considered the limitations that come with a standardized physical keyboard. In her mind, a computer should be customized to meet the needs of the user. And in today’s world of virtual keyboards and personalization features, there is the opportunity to make that reality. It might even change the way we think about our personal devices. So in your next project, try injecting a fresh perspective and you may be surprised with the results.

 

 

 

 

Creativity: A Matter of Taste

What’s the #1 quality attributed to designers? Creativity. A creative director literally manages creatives… in the creative department. This isn’t just organizational, it’s procedural. For instance, Lean UX promotes design studio activities in which participants create dozens of rapid-fire sketches. Those outbursts of creativity are great, but what’s rarely discussed is taste level. I feel that good taste is as important as anyone’s ability to brainstorm. Here are some elements of taste for consideration in your designs.

Creativity: A Matter of Taste1. Aesthetics. Visual design and branding are more than creative colors and custom layouts. Studies have linked visual design to users’ perceptions of usability and credibility. The better a visual design, the more users will trust it. Good designers track trends (without impersonating them) and avoid anachronisms.

2. Simplicity. Feature sets grow bloated because teams want to add value to products. It’s much harder to explain what you didn’t do. However, creativity isn’t just about new functions and use cases. It’s about ingenuity in combining and reducing those features. For example, which sounds like a more tasteful checkout UX: a 1-click button, or pop-up ads and pre-marked checkboxes for email newsletters? When I’ve worked on the latter, they always tested poorly.

3. Social customs. Users want ethical, safe experiences. No-nos include vulgarity, invasion of privacy, and moral affronts. For instance, Google Glass is a cutting-edge technology that’s sometimes misunderstood as a 24/7 surveillance tool. Rightly or wrongly, social judgments affect purchasing decisions.

4. Metaphors. Designers often map features to a UI metaphor to leverage users’ mental models. Caution is warranted for metaphors that may look contrived or tacky. As a simple example, horizontal tab UI mimicking file folders is easily understood. But occasionally designers position their tabs perpendicular to the page to be unique. Reading sideways labels is a creative UX, but in a not-so-good way.

5. Accessibility. Small web fonts aren’t sexy, they’re hard to read. Green and red buttons for positive and negative actions? About 5% of the population can’t distinguish them. Sometimes designers fall in love with visuals; I’ve been guilty of this many times. However, it’s poor taste to trumpet a beautiful design at the expense of those who can’t use it.

I hope these ideas are useful not only for designers, but any project member who defines, reviews or implements design. Do you have additions to this list? Please feel free to add a comment.

Posted in Design, Musings, UX

Are Devices Personal?

Every day I get “targeted” emails from retailers that are designed to appeal to my personal profile and preferences. Much of the content is driven by search history, browsing patterns, shopping cart contents and the assembled profile that the retailer has created for me. Which is great in theory. I want more relevant experiences that are tailored to my unique needs and interests. However, the reality is that my profile is actually an amalgamation of my entire family. You see, when I get home at the end of the day, my phone, my laptop, and my tablet become public property. My wife and my kids each take their turn and have their own experiences online. Experiences that include, disney princesses, monster trucks, cake decorating and yoga. So now when I get an email from a retailer, it is typically reflecting a diverse set of browsing experiences. For instance, the other day I got an email from Amazon that was promoting a set of jungle gym related products (a rock climbing wall, gymnastic rings, a play tunnel, etc..). From that, I could tell that my wife was thinking about remodeling our play room. To which I replied, “you are not turning our playroom into jungle gym.” Helpful for me, but perhaps not the intended goal of the email campaign.

Targeted Email Campaign

Targeted Email Campaign

So while personalization is becoming more engrained into a variety of web experiences, some of the methods need to be re-evaluated. It is not safe to assume that devices are personal. They can easily be shared and frequently represent a group of users. Therefore, the challenge is for retailers to focus on a personalization model that supports individual interactions vs. broader profiles. This can be achieved by looking at the context of the interaction to understand the intent, mindset and ultimately the needs of the individual user. Only then can personalization become truly personal.

STLUX Recap: Practical Interaction Design for Developers

St. Louis had a user experience conference last month (yes, I am very timely) called STLUX, and I’m starting a series of blog posts to recap some of the sessions I attended.  Instead of the typical essay type of blog post, these will be a more in depth breakdown of my notes, which come in a bulleted format.  Enjoy!

It is the duty of the machines and developers to understand people and how they think. We can absorb the pain, so our users have a better experience.This is the first in the series, covering the session by David Ortinau called “Practical Interaction Design for Developers.”

  • Interaction design is defined as the structure, behavior and the meaningful relationships between people and products.
  • In interaction design, people are the focus, not the code.
  • EVERYONE (on the team) needs to be informed about what the design is trying to do.  Designers and developers need to work together.
  • Developers don’t know everything, and should constantly be questioning themselves and their solutions.
  • “How did I come up with this answer?” Question yourself. Your brain can often trick you with your first answer.
  • It is the duty of the machines and developers to understand people and how they think. We can absorb the pain, so our users have a better experience.
  • Bill Verplank’s Three Questions (for interaction designers to answer in regards to their users)
    • How do you do?
      • Push that button
    • How do you feel?
      • I messed up
    • How do you know?
      • Way finding
  • Don’t make your user figure out and understand how your product’s system works.  Your system should understand how your user thinks and expects the system to work, and your system should work accordingly.
  • Slow is a bug
  • Cognitive dissonance is a bug 
  • Cognitive dissonance is when the user expects one thing to happen, and something else happens instead.

All in all it was a great presentation.  I always enjoy listening to David speak, because he has a fantastic presence and passion for the topics he presents.

Stay tuned for my next session summary on fixing your website’s performance!

The Dynamic Customer

At the recent Adobe Summit in Salt Lake City, one of the most interesting presentations I saw was delivered by John Bollen of MGM resorts. As the Chief Digital Officer for MGM, John is responsible for supporting the guest experience through technology. During his presentation, John brought up an interesting challenge. At MGM, they realize that their guests are never the same guest twice. What that means, is that a single customer might visit an MGM resort multiple times under different circumstances. For example, they may visit on an outing with their friends, then again on a business trip with colleagues, and later on a leisure trip with their family. The key to delivering a great experience for each visit, is understanding which mode a guest is in, and providing the appropriate interactions. 

The challenge John described is what I refer to as The Dynamic Customer. While you may have a good understanding of your customer’s needs, behavior and motivation, you can’t expect them to engage with you in the same way every time. Customers are people. And people are dynamic. They are emotional, sometimes irrational and largely influenced by their environment. To provide the right experience at the right time, you need to take into consideration the customer mindset and provide interactions that are appropriate for the situation.

Take for instance, my experience with our local drugstore. I always seem to find myself running to the store with my kids to pick-up a gallon milk, a prescription, or whatever last minute item I need. However, when I have a sick child with me, the last thing I want to do is get them unbuckled, drag them into the store and then try to get them back into the car. On one such visit earlier this year, I was going to the drugstore to buy some Motrin for my son, who was with me in the car. I thought, wouldn’t it be great if I could just get the medicine that I needed through the pharmacy drive-thru window? Surely that makes perfect sense. So I tried to do exactly that. Unfortunately, my store did not offer any OTC medicine through the pharmacy window. Needless to say, I was not a happy customer that day. The drugstore did not consider my situation and provide an appropriate experience. On the other hand, all of their other customers did get to experience a sick, screaming child being carried through their store…

In this instance, it seems that my situation was not unique. The drugstore has recently added some of the most common over-the-counter medicines to drive-thru pharmacy window, including children’s Motrin. Now they’re thinking about The Dynamic Customer, and so should you.

 

Barbie’s Dream House: Engaging with Simple Design

I took my daughters to The Barbie Dream House Experience at Mall of America the last weekend. The experience is a 30,000 square foot life size doll house created with 20 pounds of glitter and 100 gallons of pink paint.

Barbie Dream House Experience
Read the rest of this post »

Posted in Design, UX

Three Lessons Learned from HealthCare.gov

I have been following the rollout of the federal governments HealthCare.gov website and the subsequent healthcare exchanges. I have been reading many articles outlining the challenges that the team has faced with such a massive implementation, in a limited timeframe. There are many lessons to be learned from the HealthCare.gov story, but I would like to share three take-a-ways that struck me as important for EVERY software deployment, no matter how big or small.

goodfastcheapLesson #1 – Good, Fast or Cheap: Pick Two

It would appear from statements made from both HealthCare.gov contractors as well as the secretary of health, that there were a number of issues that should have either held back the deployment of the website, or a reduction in scope should have been applied, and possibly, additional team members should have been added to the project.

This reminds me of a simple project management quote:

“We can make it good, fast, or cheap. Pick two.”

Expert project managers know that very few real-life projects stay on track throughout the entire project cycle. A good project manager also understands how to make all three project constraints adjust to each other in order to maintain project quality. Some of the methods to keep projects within constraints are purely political: preventing stakeholders from changing the scope and maintaining boundaries around financial and human resources. Other solutions require classic project management techniques: keeping team members focused and adjusting milestones when necessary.

Read the rest of this post »