Wireframes: Friend or Foe?

It seems like designers fall into two camps — either they think wireframes are really important OR they say they think wireframes are really important but don’t. At all. In fact, it has been my experience that those who fall into the latter group actually think that following the wireframes too closely makes them look lazy or non-innovative — that they are just coloring them in without actually doing any designing at all.

How I think these designers view wireframes:

Pic1

As stated by Dan Brown in his 2007 book Communicating Design wireframes are, “A simplified view of what content will appear on each screen of the final product, usually devoid of color, typographical styles, and images.” In this broad view, wireframes are essentially any design rendering that does not highlight the look and feel. Instead, things such as overall site architecture and content layout, labels for navigation and basic functionality are often the focus. They can be rendered as sketches or drawings, created in a wireframing software program such as Axure, or even as clickable prototypes.

At their best, wireframes represent the upfront work done to ensure what is being built, who it’s being built for, and how best to build it for those users. They are a culmination of stakeholder goals, user needs, engineering capability, timeline and budget considerations, and (of course) usability best practices. If done the right way, wireframes are researched, created, vetted, tested, and edited (repeat as necessary). Yes, it is typically the UX designer who pulls together the renderings, but the process is hardly a one-person job. Virtually everyone (or representatives for everyone) on the project team needs to be involved during this process to make sure that the wireframes represent a well thought out and feasible design.

Despite the fact that it is widely agreed that wireframes are flexible in definition, representative of up-front work, and subject to change, there still seems to be some question of how useful wireframes are during the design process…

Pic2

Of course, most of us realize that one solution can’t solve all problems and one person’s opinion is rarely all encompassing. However, since wireframes have entered into the processes of virtually all digital teams, it is worth taking a look at these questions: how useful are wireframes? How much should they be followed? How do we get the team (including designers) to invest in the work they represent?

Are They Useful?

Yes. Next quest… ok, I’ll elaborate.

Wireframes in and of themselves are not an outcome. They are representative of an outcome. They are an artifact – a way to communicate the work that has been done up to this point. Without some way of documenting how all of this up front work has influenced the design, it would be all too easy to completely forget how this work impacted the direction of the project.

Given that the wireframes are simply an artifact, it is reasonable then that the form and complexity that artifact takes might vary to meet the needs of a project or team. It’s possible that for a larger redesign project, it might make sense to create formal wireframes that can be archived, edited and shared, in order to keep track of all of the design decisions. However, for a smaller one-page refresh, a rough pencil sketch may be enough to get the designer started (if the developer cannot be involved during this process, I recommend annotating the comps to ensure functionality decisions are not lost). Or, perhaps for a new product design a prototype would help to visualize new functionality and support user testing.

No matter what decision is made, it is important not to resort to a default action. This can cause confusion, the loss of key decisions, or simply waste time.

How concrete are they?

How concrete is any deliverable? Ok, some are pretty concrete.  Wireframes, though, are absolutely subject to change — just hopefully not with the wind. As stated before, wireframes represent a lot of up-front strategic work – research, analytics, business decisions, technical constraints, etc. So if a major functionality change is proposed in design, there should be a really good reason for it. That isn’t to say that really good reasons don’t come up, but the person proposing this change should be aware of (or find out) the implications to the project and be prepared to explain why the change is worth any setback it may incur before just popping the change into the comps.

Is that too much to ask? Sometimes it is, especially when a designer is on a really tight timeline and has to make some quick decisions at 2 AM in order to make something work for a comp review at 9 AM that morning. That’s where I find collaboration can be a really handy way to make sure everyone is on the same page early on. Get the designer involved during wireframing so that when they do need to make those decisions in a silo, they won’t ignore those good reasons why a decision was made (or can’t even if they sometimes really want to…a lot).

Of course, not all design limitations (or tech constraints for that matter) can be assessed during the wireframe review, so things will still come up later. But we can try, can’t we? Let’s try.

Does anyone care?

Somebody cares, right? I mean, I have a job so that says something right there. But when wireframes are seemingly ignored it can feel as though wireframes are built for the benefit of no one (well, I do like playing with Axure. I feel like I’m coding without that pesky ‘learning how to code’ nonsense).

People care. They really do. However, a lack of understanding of what they are or should be looking at can have a profound impact on how engaged people are when looking at a wireframe. This is another argument for why it’s important to take a look at the form the wireframes are taking, per the people and project involved.

One thing we’ve recently begun to explore are the idea of wireflows – wireframes arranged into a user flow or site map.

Wireflow example:

Pic3

Image credit: http://wireframes.linowski.ca/2009/12/omnigraffle-wireflows/

Team members (or clients) who may be getting too granular when looking at wireframes, can benefit from being able to see how the pages, transitions and interactions play into the larger whole. Communicating design clearly will increase people’s willingness to engage and provide meaningful feedback. Of course, no one can make someone care about their job (or yours) if they don’t. But hopefully that is a rare problem. And if it isn’t, well, that is an entirely different post for a different day.

Just remember, when wireframing a design: Choose form wisely, communicate purpose clearly, and collaborate with your team.

Lessons three: Public speaking

This past October, I was incredibly fortunate to be given the opportunity to speak at Midwest UX, an awesome conference that took place this year in Grand Rapids, Michigan. It was my first time speaking and I knew that the learning curve would be steep – this is something that takes time to get good at. But, I went for it and I’m so glad I did. I had so much fun, learned more than I could have imagined, and even made some new friends. The following are three of the lessons I learned through this experience.

1) This was really hard.

And not in the way I thought it would be. The amount of work I put into my talk was overwhelming. I had no idea what to expect going in because I had never done anything quite like this before beyond a class project presentation in grad school. I was incredibly nervous about getting in front of a group that would include peers and mentors, and in the very beginning this was all I could think about. What if I say the wrong thing? What if I stumble on my words, or forget what I was going to say at all? What if people disagree or ask a question I don’t know how to answer?

As I began work, I quickly realized that those were the least of my problems. Getting up in front of people wasn’t the hardest part by a long shot. The hardest part was figuring out exactly what I wanted to say, how I wanted to say it, and how to make it relevant and interesting enough to expect a crowd of people to pay attention for a full 45 minutes (at least intermittently). This is what kept me up late night after late night working on my talk, changing slides, tweaking text, practicing wording, etc. It was both physically and mentally exhausting.

2) Perfection is unattainable and (should be) undesirable.

This seems to be one of those lessons that I have to learn again and again for each new applicable context, like eye-hand coordination (I’m good at tennis, surely baseball batting will be no different…). I don’t necessarily go into an experience thinking that I will somehow miraculously achieve perfection THIS time. But, as I get deeper into a project the quest for perfection will inevitably take over without me knowing what is happening. Needless to say, I learned this lesson once again.

There is one thing about striving for perfection that I do like – the moment you realize what you are doing and are able to just let go. The times when I have been able to do this have been some of the most freeing moments in my life. While putting together my talk, I read an article by Karen McGrane entitled “Give a crap. Don’t give a fuck.” In it, Karen tells a story of a time she had to pull together a talk in very little time, during a time when she was dealing with a personal tragedy. But, by being forced to let go of perfection, Karen’s talk was one of her best.

The moral of her story is that by allowing herself to be vulnerable and not giving a fuck about looking perfectly polished to the outside world, she was able to truly put herself out there and really connect with the audience. Though I did not achieve that level of vulnerability this time, its something to continue to strive for.

3) People are awesome.

Ok, I already knew that. But the amount of support I got from my co-workers, peers, friends and family was amazing. Really, I was overwhelmed with how much people were willing to do to help me, both with the talk itself and just in providing moral support.

This experience was one I will never forget and I absolutely cannot wait to do it again. Bring it on.

Midwest UX in Grand Rapids

Wow. So many positive things to say about Midwest UX.

I’ll start with the city of Grand Rapids. As a Northern Michigan native, I’m ashamed to say that its been a long time since I’ve stepped foot in Grand Rapids and longer since I spent any real time there. Holy s$*% has it changed (at least my perception of it has changed). Its such a fun, bustling, artsy, amazing little city. From the museums, to the restaurants, to the local boutiques and shops, I absolutely fell in love. Ann Arbor is my soul mate, but I’m definitely flirting with the idea of Grand Rapids. Hmmmm…

Now to the talks. The first one I attended was Charlie Erdman’s. I was really disappointed to have missed Abby Covert’s talk because I was doing a sound and tech check for my own talk. But I heard it was awesome! Charlie spoke about the shift from online communities as a separate space to being more integrated with physical communities. It was an excellent talk and made me rethink the value I see in online communities – as a way to bring people together in more meaningful ways (not in less meaningful ways, as we have come to expect from them).

The next talk I went to was mine. But I’ll talk about that another time. After the morning talks, I was lucky enough to get to go on the brewery tour. We started at Grand Rapids Brewing Company, which was absolutely fantastic. We had an amazing lunch paired with equally tasty beer. After lunch, the brewmaster took us for a quick tour of the brewery and we got to see what makes Grand Rapids Brewing Co. special. After that, we walked over to HopCat and then to Founders. Both were excellent stops, but I was surprised by how huge Founders is! We had more excellent beer and got to go for a behind the scenes tour. Had I drunk all of the beer they gave us I would have been quite tipsy for our 5:00pm keynote. All and all a very good time.

The evening keynote was Christina Wodtke. Her talk was a great way to end the day, focusing on how the places we go define our perception of ourselves and our capabilities. She started by asking us to close our eyes and think about the first house we can remember. The halls, the doors, the rooms. Thinking about this not only gave me nostalgia, but it also made me think about how that house played such an active role in defining my childhood – and therefore in defining me. She made easy parallels between the physical and digital world, and emphasized that we need to keep this idea in mind when designing spaces for people. It may become a part of our users’ lives in ways we never knew or intended.

That night there was a party. It was an incredibly fun and random night. It was at a Site:Lab, an art project that sets up temporary exhibits. It was such a cool and fun space to explore and I had an absolute ball. We spent the rest of the night at Stella’s Lounge where we drank good beer, ate fries and danced to 80′s music. Good times were had by all.

The next day started with a panel of chair designers. They talked about the various things they need to keep in mind when designing chairs, and it was not only interesting and informative, but surprisingly hilarious too. The next talk I went to was Narrative Spaces by Christian Eckels. He made some excellent parallels between the opera world and digital world, but I honestly couldn’t get past this amazing photo of an opera stage. Incredible.

Next up for me was Donna Lichaw. She talked about the future of technology being closely tied to the contexts they might be used in – for example, maybe Google glass won’t take off as an everyday tool, but perhaps as a navigation tool or as a way to get information when you need your hands free. Donna was an excellent speaker, and I really enjoyed her as a storyteller. Next up was lunch. During lunch we listened to five Pecha Kucha talks – lightning style presentations, 20 slides for 20 seconds each. They were all excellent talks and I was impressed with how the speakers were able to get their points through in such a limited amount of time.

The last two session talks of the conference that I attended were Phillip Hunter and Kerry-Anne Gilowey. Phillip argued that the context that users bring with them into a space – the thoughts, feelings and intentions – is more important than the context of the space itself. It definitely resonated. Kerry-Anne’s talk was about life in South Africa, and how it differs so much from our life here in the States. She was an excellent story teller and made her point clearly – don’t assume you know who your users are or where they are coming from.

The last talk of the day was Karl Fast. He is my speaker role-model. He has such a presence on stage and has a really amazing way of slowing down and using pauses to help make his point clear. His speaker style in and of itself could be a lesson in usability – how carefully choosing your content, presenting it in small chunks and using white space appropriately can help bring clarity to your site. Anyways, he talked about datification and how as user experience designers, we need to care about the small data that is important to our users over large data that corporations are tracking. I really liked how at the end of the talk he didn’t take questions because, as he put it, “I don’t have the answers.” That really resonated with me since my topic was all about how to support learning and thinking in a way that gets people to their own understandings – not dictating how something should be thought about from your point of view.

Overall the conference was a huge success. I’m so happy and proud to have been a part of it. Another post about my first time speaking to come later.

What UX means to me.

It’s been a year since I started my first UX position. Its been an incredible experience, and I cannot believe how much I’ve learned. The people I’ve met, the projects I’ve been a part of and the skills I’ve built on have been invaluable to me as I navigate this crazy awesome field. It is the culmination of all of these experiences that has brought me to an interesting place in my career. I finally feel confident in my own understanding of what UX means – to me.

It seems strange to be a year in and only just now feel like I know what I’m doing, or at least what I want to be doing. But, there it is. There are so many different opinions about what role UX plays in building digital products — within organizations, in the UX field, and in the digital industry as a whole. And there seems to be an influx of secondary titles being tacked on to UX — UX Strategy, UX Designer, UX Architect, UX Researcher. What does it all mean, and where do I fit in? Ah, yes. The ultimate life question. But lets just stick to answering this question within the context of UX.

I’ll start by going through a couple of key things the last year has taught me about myself. First, I am incredibly analytical. About everything. All the time. And, here is the kicker, I absolutely love that about myself. I am simply not satisfied with surface level knowledge about things. I feel the need to dig deeper, asking the whys to the whats. And I especially love doing this when it comes to understanding people. Nothing is more complicated nor more fascinating to me and I find this challenging, fun and exciting. Next, I need to be creative to feel fulfilled in my work. As much as I love being analytical and digging deeper to understand users, I wouldn’t be satisfied just doing user research. Part of the fun of analyzing user research results is getting to translate that into the UI design. Brainstorming product features, sketching interface with creative designers, playing with functionality in wireframes, testing rough prototypes with users — this has been the thing that gets me excited about coming into work every single day. I just love doing it.

This is where I feel really lucky to be in this field because this past year has also taught me that the same person doing the UX design should absolutely be doing the user research. Some may disagree with me on this saying that design and research are two different skill bases and that its too much to ask to have one person do both. I completely disagree. Designing interface or site architecture is how we manifest our findings in our research. Some researchers are also writers. Others are also photographers or filmmakers. We are interface designers or information architects. It is our responsibility to know how to research our users, just like it is our responsibility to know how to translate those findings into our designs via sketches, wireframes or prototypes. Moreover, the person who does the research will have the most thorough understanding of who the users are in order to best inform the design. Likewise, the person doing the design will have the most thorough understanding of the project to determine what needs to be known of the users in order to move forward. It makes sense then that this should be the same person.

I realize that there are those out there who may not need convincing of this. I also know that there are those out there who strongly believe that designers should not be researchers. There are different kinds of designers that take different approaches and do different things. My approach to my job is and will continue to be user-centered. What this means to me as a UX professional is that I must be skilled both as a user researcher and user interface designer. Where that leaves me in terms of a UX title, I have no idea.

Templates are not one size fits all.

Let me start by saying templates are insanely useful things. Not only for saving time and money in design and development, but also for users. Websites staying within pre-defined templates across similar pages allow users to quickly develop mental models that they can draw from across their experiences on the site. They are able to navigate the site easier so that ultimately they are able to get to the content faster, which is likely the reason they came to the site in the first place.

So when should you deviate from this tried-and-true model? That depends. What are the business goals? What are the user goals? How is success going to be measured? These questions need to be answered before a decision can be made. If the answer to these questions match-up with an existing template, then the template should be used in order to create consistency across the site. If, however, they do not, then a new experience created to achieve these new goals should be highly considered. For example, if the goal of a new experience is to create buzz around a product reveal and the measure of success will be centered on social media shares and mentions, creating an experience within a template that was created to drive users to a particular CTA (i.e. Add to Cart) may not yield the best results.

Of course meeting user needs is absolutely paramount to the success of any site. So it is imperative when deviating from a template that user research be done throughout all phases of the project. By deviating from what users expect to see based on the mental model they may have already created while visiting your site, you have to expect that they will likely lose their bearings when first coming to this new experience. Testing should be done to ensure that users are able to quickly find their way around the new experience and are able to find their desired information quickly and easily.

Templates should be used whenever possible when business goals, user goals and measures of success are aligned so that users are able to gain a sense of expertise when navigating your site. However, when goals do not align, templates may get in the way of creating something new and innovative, and better suited to the goals specific to that experience.

Lessons three: card sorting

I am starting a new series I’m calling lessons three. This is meant to be a quick digestion of three major lessons learned during a ux exercise.

I recently conducted a card sort in order to get a grasp on how to optimally organize a large amount of video and image content for our users. It went really well and the results have been implemented to everyone’s satisfaction. But I wanted to take a second to analyze what I learned from the experience. There were three major take-aways.

1) This is incredibly easy.

I think the hardest part was the content write-ups and then cutting and taping the cut-outs onto the physical cards, though maybe thats because I couldn’t find a tape roll dispenser and found myself wrapped in tape within the first few minutes. Those are more important than you would think. Doing the analysis was a bit more time consuming, but I found it fairly easy to do using the excel spreadsheet I downloaded from here: http://rosenfeldmedia.com/books/cardsorting/content/resources/

A card sort can be done fairly quickly, depending on how much time the team has to devote to the planning. We scheduled our sort two days after we decided we wanted to do it and though we were maybe a bit crunched, we were able to do this with no problems. For planning there isn’t much that needs to be done in terms of writing scripts or specific questions or tasks. A short intro to the project and a description of what the users are expected to do during the sort is all that is necessary.

Recruiting users and scheduling times could be the wild card, but as long as you have a system already in place for getting users, this is just a numbers game. Call or email until you find enough people to come in during the times you’ve already allotted. If all else fails, grabbing people from HR or another part of your organization not involved in your project could be your fail safe.

2) Organizing several small groups is better than testing individuals.

In the interest of time, we decided to schedule three groups of four people, so 12 total users, as opposed to scheduling users individually.  We scheduled half hour sessions with a little wiggle room in between sessions in case they went over. I was initially a bit concerned doing it this way in case we didn’t get accurate results. Past card sorting I had been a part of tested five or six individual users. What if they weren’t engaged with the task or didn’t know how to work well in groups? What if one person took over and the rest of the team members were drowned out?

As I watched the users I got so excited with how well it was going. First, they were so into the project. It reminded me of when I was a teacher (for a second) and I would give my students group work. Almost all of them, even the introverts, would come alive. Suddenly they were excited about the subject matter, no matter how boring it seemed to them before. A bit of facilitating is definitely necessary to make sure that everyone is participating and that no one decides that the group needs a dictator. You may also need to prime them if they get stuck on something or you feel they are misunderstanding the content.

Another benefit of using groups is that the resulting discussion that occurs during the sort is a much fuller experience than individuals alone. With individuals you may find that you have to ask them to think aloud several times since this may not be natural for them to do on their own. However, in groups, voicing what they are thinking is much more natural, and is in fact essential in order to communicate their ideas to the group. I found these discussions to be invaluable during the analysis because I knew why the group chose to organize the content in that way.

3) Schedule a meeting to share results. Do not email.

I was very pleasantly surprised when I suggested doing a card sort to the team at how open everyone was. We had been going back and forth for a couple days trying to figure out how to sort the content, driving the project manager crazy, and not feeling very good about where we were heading.  When the idea to conduct a card sort came up, it seemed like the group breathed a collective sigh of relief. Not only would we get a way to organize the content directly from the users themselves, but we would also likely save time having meeting after meeting to try and do this ourselves.

After the card sort, I emailed out my analysis. I included the spreadsheet I used, as well as my overall recommendation. I wanted to be transparent as to how I came to my conclusion in order to hopefully give the recommendation more weight. I was quickly reminded that people do not read emails. They graze them. People were confused about what was in the spreadsheet, and why I was recommending one thing when the spreadsheet showed varying results. I had to re-explain in another long-winded email how I did my analysis and came to my recommendation. In the future to avoid any confusion, I will send out the results only in an email and schedule a meeting to review the details of the analysis with anyone who is interested.

Experiences like this remind me not only how important user research is, but how easy it can be to do quick-and-dirty tests that still add so much value.

Going against the grain.

Being the sole voice of disagreement in a room filled with people all on the same page is really hard. Really. Hard. How do you know that you are in the right if everyone else seems to think that everything is in order? Moreover, I am new still and in most situations the people in the room are far more experienced than I am in their own fields. It’s intimidating to speak up and also can feel like you are holding up the process by voicing a concern or issue you have with some aspect of the project. So how do you determine when its worth it to speak up?

Everyone in the room represents a different part of the project. The team is relying on each individual’s expertise in their given area to achieve the overall goals for the project. As the UX designer in the room, my expertise is in user behavior and my goals for the project are centered on ensuring the usability of our site for our target user base. Though other’s in the room may have goals that overlap mine, and hopefully the organization as a whole is always thinking about the user, this is my primary concern. If something is happening that is going to negatively impact the user, it is my job to speak up, even if that means standing out on a limb all by myself.

It is not enough to be clear in my convictions. Yes, I represent the user, but that doesn’t mean that I represent the user correctly. It is my responsibility to do whatever I can to gain knowledge of the user, both for the site I am working on and for that particular project. This can be hard. I have been on projects where I am handed an SOW with two sentences about the target market and that is all I have to go on. That is not enough. It is up to me to either propose additional research be done or find whatever nuggets I can in past research that has been done if new research isn’t possible. There are things that I know from conducting usability tests are universally bad experiences. But making assumptions about users without any knowledge of who they are is risky business.

The other tool I need in my tool belt when speaking up in meetings is confidence. This may go without saying, but being confident goes deeper than knowing my concerns are valid and having the courage to speak up. I also need to reconcile myself with the possibility that members of the team may disagree with me or even get defensive if it was their decision, idea or work that my concern is addressing. By choosing to speak up, I am opening myself up to possible push back and that is ok. It can even be beneficial to be questioned because it provides additional opportunities to further explain the concern and hopefully explore some solutions to addressing them.

If all else fails and speaking up about a concern just isn’t going to happen for whatever reason (e.g. too many voices in the room or you need to do a bit more research to be sure that the concern is valid) it is ok to table something until later. If a decision needs to be made, tell the team you need to mull it over and will send your feedback later that day. You may lose out on the in-person discussion in the meeting, but it is at least better than staying silent and can give you time to put your thoughts together more coherently or discuss your concerns with fellow ux team members.

One final thought, being diplomatic when going against the grain is imperative. This is a topic for another day, but I felt like I couldn’t sign off without saying it.