Mission Impossible: Shrinking the UX Process

This past winter, there was some unique work happening at AnyClip, a web start up in New York City. Although less than a year old, AnyClip was preparing for their public re-launch at South By Southwest. Our team (Lis Hubert, a user experience consultant, and Gabi Moore, in–house designer at AnyClip) was tasked with formulating an appropriate strategy to guide that process. The only caveat? Our deadline was in three weeks.

AnyClip wanted to bring both user research and interaction design to their development cycle; it was up to us to modify their process. We naturally began with discovery—collecting user and business perspectives as well as analyzing the competition—but what should we do next? In this post, we’ll trace our footsteps. As you’ll soon see, some of our methods worked, some didn’t; overall, however, it was a rewarding experience for everyone involved.

What is a UX Strategy?

For our purposes, a UX Design Strategy was seen as a holistic, research-based plan of feature implementation that enables the business to move from intuitive ideas to objective reality. In laymen’s terms, a UX Strategy is a compass that guides both design and development. The direction of that compass is based on user research and existing knowledge about users, business, and competition.

The creation of a UX strategy included:

  • Stakeholder Interviews
  • Stakeholder Meetings
  • User Interviews
  • User Surveys
  • Persona Creation
  • Content Audit
  • Heuristic Analysis
  • Competitive Analysis
  • User Research
  • Ideation/Brainstorming
  • Sketching
  • User Stories Creation and Prioritization

Adapting a plan

We began with a fifteen-day plan: five days for user research and persona creation; five for business research and goal definition; and five for scenario creation, brainstorming, sketching, and scoping. Even with proverbial lines in the sand, though, we knew our plan would have to change.

Why? Simply because users and stakeholders are human. Human behavior is unpredictable. For example, some days we scheduled brainstorming activities, but weren’t particularly in a creative mood. Instead of trying to force inspiration, we switched to other tasks that didn’t require as much creative thinking.

Schedule shifts, changes in the development environment, and even the general mood of the team all mandate that a project’s plan be flexible. If nothing else, just choose the tasks that best match the skills available that day. As long as you pay attention to the amount of time dedicated to each task, individual ones can be spread across multiple days; multiple tasks can be worked on simultaneously. As you allot time to various tasks, be sure to differentiate between those that are essential and those that your project could potentially do without.

In our case, we elected to modify our sketching/wireframing process. Originally, we created digital wireframes for our offshore development team. Once we saw how time-intensive this was, however, we decided to simply sketch and email photos of our work. In the end, we saved a huge amount of time and were still able to think through each scenario.

The bottom line? If something isn’t working well or goes off schedule, keep moving forward. Either find alternate ways to get results or switch to a task that you’re better suited for at the time.

Collaboration

Collaboration played a huge role in our success at AnyClip. The two of us—a visual designer and a UX designer—worked together on every task in person. In general, we’re big fans of working remotely, but we felt that truncating the process as we did mandated that we work together, in the same room, every day. In-person collaboration helped us to avoid going down the wrong path when the results weren’t what we’d hoped for.

Another crucial part was having unfettered access to our stakeholders whenever we needed it. Luckily, our stakeholders not only understood the process we designed, but played a key role in sketching and conceptualizing solutions. This made sign-off a non-issue, allowing us to move more quickly through the design process.

A final strength came from our team’s diversity. Our stakeholder came from a Product Development/Management background; Gabi came from Visual Design; and Lis from and Interaction Design/User Experience background. This enabled us to both generate more creative ideas as well as appropriately prioritize them.

Tools and Documentation

The following tools worked best for us because they’re lightweight; they don’t generate much in the way of documentation. This is because our team explicitly followed the agile mantra of working software over comprehensive documentation.

  • PowerPoint — for quick notes and to organize our thoughts. It forced us to be concise due to the limited space and the huge default font.
  • Omnigraffle Persona Templates — We used existing templates to save time.
  • Google Docs — to share documentation with the internal team, and the offshore team as well, so we could all stay on the same page.
  • Dropbox — to ensure documents were always in sync. This was specifically for documents that we didn’t create in Google Docs (e.g., Personas done in Omnigraffle, previously created documentation, etc.)
  • Whiteboard — to sketch out our ideas. We also used it to take notes and brainstorm.
  • iPhone — with the whiteboard, we used the iPhone camera to document our sketches and electronically share them with the team.
  • Skype & Google Video Chat — to communicate with the offshore team (especially stakeholder interviews) as well as conduct user interviews for our persona creation.

Lessons learned

Everyone makes mistakes, and we’re no exception. One thing we could have done better was to keep our entire team (especially our developers) informed and up to date on the current state of the project’s design. Without close collaboration, the transition to development wasn’t as smooth as it could have been—we missed out on gaining more comprehensive research data to help drive our design.

Our tight timeline was to blame for the oversight, but we realize now we should have given the development team access to our artifacts, interview notes, sketches, and thoughts, so they’d be more aware of what was going on and where the project was headed. Any type of involvement, however small, is better than no involvement at all.

How you can do it

To reiterate the key factors that made us successful:

  • Prior knowledge on the part of the company of what UX is and why it’s important.
  • Access to a key stakeholder who can sign off in real time.
  • No strict requirements regarding deliverables and tools. Letting the process guide what gets produced.
  • High degree of in–person collaboration.
  • High–level plan of what the team needs to do in order to create a user experience strategy.
  • Realization that your high level plan is subject to change.

We realize that it’s pretty rare to get a dedicated stakeholder, a lack of deliverable requirements, and access to someone you can collaborate with all at the same time. It may not be possible to recreate everything we mentioned. Instead, consider your project’s goals and appropriately apply tasks that worked for us. Some user experience is always better than no user experience.

In short, talk to users. We did this directly for 45 minutes a piece. If you don’t have the time or budget, consider sending out a survey or sitting in a coffee shop for an hour and talking to people that might use your product. Maybe you can interview friends or colleagues if they are potential users. Whatever it is, involving your user is the number one input into building your strategy.

Second, evaluate the product. We made sure to perform an heuristic evaluation that enabled us to create a baseline for our work. Perhaps you have a list of current system bugs that you could review and analyze? Or maybe you have usability test results that are still relevant?

Third, make competing objectives known. We made AnyClip aware of internal discrepancies with regards to their site’s goals. Even if you can’t get all the stakeholders in a room at the same time, find a way to get their individual points of view and try to make each of them aware of the differences.

Your process?

There are several ways you can create a User Experience strategy for your product. Hopefully there are some insights and takeaways that you can glean from our story and use to create your own. We found what worked for us, and we would love to hear about what worked for you.

About the Authors

Gabi Moore is a Web Designer who left sunny Rio de Janeiro, Brazil to move to exciting Brooklyn. She’s worked mainly as a Visual Designer and Front–end Developer, but she’s also extremely passionate about IxD and UX. Gabi is currently Senior Designer at AnyClip, a startup company based in New York and Jerusalem.

Lis Hubert is a UX Consultant based in exciting NYC. Her passion lies in helping people and companies of all types make their websites easier and more enjoyable to use. Lis has worked with clients such as RAPP, Critical Mass, Weight Watchers and AnyClip and has recently signed on as a strategic partner at Simply Interactive.

Write for UX Booth

Contribute to UX Booth
Contribute

Contribute a guest post to UX Booth and let the community know what's important to you!



Comments

  1. Steve May 11, 2010

    I think it’s really smart that brainstorming was further down in the process. That can help eliminate ideas for content or usability don’t jibe with the audience needs. For wireframes, I’ve been using cacoo.com

    • Steve – thanks so much for sharing cacoo.com. I checked it out and this is a perfect tool for simple and quick wire framing. It also is great for quick wire framing.

  2. I get why a lack of deliverable requirements made your process quicker, but it would probably also hinder communication. I guess speed was of the essence in this task…

  3. It’s amazing how often clients want me to skip the hours it takes for proper UX design and get right the LAUNCHING…

    • I know exactly what you mean, however, the company I currently work for tend to take that place (cutting design hours, when they are needed for proper UI design and proper UX planning)

  4. Brilliant use of B-plans as far as adapting the original working plan goes. It also strikes me the important role of in-person collaboration, indicating that technology will never be enough. Hallelujah!

  5. Irina May 12, 2010

    Great post, Liz! Thank you for the info.

  6. Derrick May 16, 2010

    Great article

  7. Benxamin May 17, 2010

    I love how development is the last consideration… I’d be interested to know what the “more comprehensive research data to help drive our design” was… It _sounds_ like “we came up with a crazy idea that’s not technically possible within the scope of our time frame or our current architecture.”

    • That’s a valid concern, and a lot of times that gap between design and development is indeed huge. Fortunately, that wasn’t the case with us. I do a lot of front-end development, and Lis was a programmer for many years at the beginning of her carrier. So that prevented us from coming up with crazy ideas that were technically impossible. Our problem was mostly the fact that the development team didn’t really know what was coming, and didn’t have time to digest the changes, give us feedback, and start thinking about technical solutions.
      At the same time, I believe there is great value in designing without having development in mind at first. If you are constrained by technical limitations at the beginning of the the design process, you might never come up with innovative ideas. And let’s not forget that a lot of solutions that used to be technically impossible, are now very possible, probably because there are a lot of brilliant developers out there who won’t accept that something is impossible. It’s usually a matter of accepting the challenge, figuring out how to it, or coming up with a totally new solution.
      What do you think?

  8. Thanks for contributing an article Gabi and Liz! Your “agile” UX process sounds very similar to the one that I initially practiced at Hashrocket last Summer.

    • Thanks for letting us share our ideas! I’d love to hear more about your process and how it worked some time.

  9. Fritz June 8, 2010

    Kudos Lis & Gabi good read. Autopsying your process is brave and extremely generous I wish more people would do it, it’d benefit the entire industry.

    For me working within an Agile (Scrum) framework for the past few months hias been truly eye opening. One key thing was to call in developers at the end of each sketch session (ideally even have them participating) to ensure we’re all on the same page. Barring that the other key concerns include user recruitment, time for testing and maintaining design integrity thru to development (much more difficult than most think), I could go on. Any way kudos ladies good read.

    In the spirit of full disclosure I know Lis personally and am indeed a fan.

    http://www.twitter.com/fritzism

  10. Great read guys! I’m currently trying to “shrink” my UX process too, for clients who can’t have me spend a lot of time on UX. Its sad to not get enough time upfront, but hey, some research is better than none at all! I’ll let you guys know how it goes!

Related Posts