Is Mobile Design Really That Different?

I’ll be honest.  I’ve only dabbled in the mobile app design and development space: one app for fun, one app for work (hopefully to be released in the next couple months).  At today’s iPhone Design Conference, Brian Fling argued that mobile design is totally different that web.  But I still don’t see how mobile app design and development is that different from traditional software or web development.  Mobile devices offer new capabilities and require learning new tools, but the fundamental design and development tasks remain the same.

Mobile design reminds me of designing desktop apps in the late 90s.  Multiple platforms, small screen real estate, limited computing resources (although an iPhone would probably

Back in the day, VisualAge for Java provided a way for designers and developers to jointly build "cross-platform apps." It used a drag/drop GUI editor to generate java code. In other news, I'm old.

run circles around my 486).  Each application was an island, with little or no way to share information or task flows between them. Users probably didn’t have that much experience with computers.  Your job as a designer was to understand the users key tasks and success criteria, and  iteratively perform design and development to reduce time on task or errors.  You differentiated your product by closely aligning the user interface metaphor with the users’ mental model of the task or process.  Back in the day, we called this User Centered Design, and later Usability Engineering.  Over the next decade, hard drives got bigger, screens got bigger, processors got faster, and networks and application mashups were everywhere.  Users learned what to expect on websites.  We designers stopped talking about usability — how well do people get through the task flows we have created — and started talking more about a more holistic User Experience.

Mobile application design exploded with the iPhone.  Again, we find ourselves designing around constraints of small screens, multiple platforms, and limited computing resources.  This time around, however, we’ve got some additional capabilities.  Geolocation, gesture and multitouch interfaces, photo and video streams, anytime/anywhere network availability.  We have cloud processing and data storage that we can use to offset device limitations.  Even better, we have a generation of millions of users that are eager to embrace new technologies, pretty much willing to pay for and try out whatever we can think up.

But some things haven’t changed.

The basic cognitive and physiological capabilities of people haven’t changed.  We’re still resource constrained people, who can only focus on one thing at a time, have relatively shoddy memories.  We can only get our fingers to click on something so fast.

We all have the same basic needs.

Because of these basic human traits, designers still have to take care of the same basic interaction design requirements:

• Visibility (also called perceived affordances or signifiers)
• Feedback
• Consistency (also known as standards)
• Non-destructive operations (hence the importance of undo)
• Discoverability: All operations can be discovered by systematic exploration of menus.
• Scalability: The operation should work on all screen sizes, small and large.
• Reliability: Operations should work. Period. And events should not happen randomly.

As Don Norman recently pointed out, we’re not doing a great job with this on gesture interface devices

When we build these interactions, we’re still not doing it by ourselves.  We want to continually align our designs with users expectations and developer feedback.

We still need to understand users’ mental model of the task domain first and foremost.

Mobile gives us some new tools in our design toolbox, and we lose the assumption that the user is sitting at a desk, working on a single task by themselves.  New device capabilities…natural voice control, natural human gestures, thought controlled interfaces, semantic or linked data…are in active research and will make even more things possible.  But the basic job of the UX designer is still the same…to use the resources available to make our users more efficient, effective, safe, and if we’re lucky happier.  We still need to work iteratively with developers, business stakeholders to make that happen.

Am I missing something?  Am I thinking about it at the wrong level of abstraction?

On a side note, I’ve previously discussed that UX Designer/Developers should have a strong foundation in human factors, psychology, and computer science.  I think that (and experience) gives you the background to see beyond the new shiny toys and identify the real trends and innovations.  Jared Spool seems to agree.

Agile2009 Recap

I had planned liveblog the Agile2009 sessions I attended, but ran into a couple roadblocks*.  You can see the Agile2009 sessions I DID blog.  Also, Jackson Fox went ahead and wrote a great recap from a UX perspective.  It might be more interesting for me to talk about how well I accomplished my goals for attending.

I had three goals for attending Agile2009:

1. Learn methods, tools, and best practices for improving my user experience (UX) research and design,
2. Help my department to adopt Agile practices in order to respond to increasingly demanding projects and shorter deadlines, and
3. Learn ways to more effectively team with colleagues in other parts of our organization to develop and deliver outstanding UX on our enterprise tools.

I was a blend of several of the conference personas: obviously Deanna the UI Designer, but I also felt some affinity for Carlos the Internal Coach, Peter the Programmer, Alex the Architect and David the Developer, even Tara the Tester.

Agile UX Research and Design

I’ve already blogged about some of the UX sessions I attended.  I would say that there were two broad categories of UX sessions (at least, that I attended): Agile UX methods and processes (guerilla user research, persona development, task analysis grids or storyboards) and experience reports (how do we do UX on an agile time schedule, with an agile development team).  The method and process talks were very high level — almost introductory, and I felt didn’t really have enough time to get into any kind of real discussion on how to really use these UX methods in real life, anymore than reading about the techniques on the web .  I did appreciate the 3 hr tutorials from Jeff Patton on Personas and Mike Cohn on User Stories.  Coming out of those, I felt like I got a bit of ‘meat,’ which I could chew on — they gave a good framework for how to think about using these tools, instead of just a technique.

From the experience reports, the main message I got was, “here’s what sort of worked for us…we had to be agile and learn, and this is what happened in our shop…good luck with yours.”  I had a hard time seeing how some of these were generalizable, or how I might use some of the lessons learned.  Clearly, everyone is feeling the time pressure for faster deliverables within Scrum sprits.  This means that UX practicioners have to be UX generalists: skilled in visual design, info architecture, interaction design, even development.  I think the best takeaway was just networking with the people giving and attending the sessions, and finding a community of people I could talk to about approaches I’m thinking about taking.

I was a bit saddened and disillusioned at the perceptible distance between the UX and Agile Development community.  The developers are still saying, “I’ve gotta get this code feature out the door, I’ll let you know when I need to talk to a designer), and the UX people are still asking, “how do I get the working respect and integration with the development team.”  One concrete example of this: Todd Warfel and others did a set of three sessions on the whole ‘Agile UX process: Performing User Research, Distilling and Communicating Research Results (mainly via personas, and finally developing wireframes.  I noted that the user research sesssion was sparsely attended and almost solely by UX people, the session on personas had a few more, and the session on wireframing was jam-packed.  I think this is another example of developers trying to see how to get straight to the design, even though designers know there’s a process involved in getting to the design.  Not sure how this dichotomy will play out.  I don’t think anyone does yet.

Overall, definitely a positive experience, though.  I was really impressed with the LiveAid stage…several UX designers did some agileux methods (guerilla user research, personas, wireframes), then teamed with several agile developers at the conference to create an iPhone app for a non-profit: http://www.manoamano.org.  In addition to raising nearly $5000 for the charity at the closing banquet, the exercise of doing UX research and design, development and shipping a live app in 3 days was inspiring.

Agile in our Department

At my company the webteam is undergoing a bit of an evolution, where are roles are changing from simply maintaining the public static websites to designing and developing some mission-critical web applications.  Our internal clients are asking our team to provide new (to our company) types of online interactivity and functionality, and the demand for us to be a mini-IT department are increasing.  What agile tools/options should we look at in order to keep with the demand and still deliver outstanding webapps?

One way I think we can improve is to better integrate unit testing, acceptance testing and continuous integration into our team workflow.  I went to a couple talks on CI – I think mostly by CI software vendors.

I went to a couple agile coaching sessions to get a sense for how to ramp up teams, and get people started doing things an ‘agile way.’  I was impressed by some of the coaching start up team strategies shared Lyssa Adkins. The session on user stories from Mike Cohn was again a great example of how to collect/gather/uncover requirements.  In the OpenJam, I poked my head in on some people review Kanban project management.

One takeaway here is that ‘agile software development’ is more of a mindset change.  It’s a set of principles, from which several methods, tools, and best practices have been developed.  But as warned on numerous occasions, just adopting some or all of the methods without understanding the principles often leads to poor results.  I think the key here is to focus on the core principles, and adopt the set of practices that make sense for your team wherever they’re at.  I like the idea of the Scrum style — setting a sprint timebox for a delivery of something of business value, and then meeting afterwards for a retrospecting and planning of the next sprint.  I’m planning on experimenting with a WIP board for a short sprint on a project this week.

Another takeaway is that, at the end of the day, all these agile documentation and project management methods and tools (user stories, personas, work in progress boards, pair programming, Scrum, Kanban, Blitz Planning) aren’t really rocket science.  They all center around creating externalized, shared visualizations of the problem and solution spaces.  The goal, it seems, is to extract the implicit knowledged wrapped up in each team members’ head as simply as possible, put them in a shared accessible place as simply as possible.  This allows the whole team to see the whole picture, and allows communication and ideas to flow as quickly as possible.  That’s why agile emphasizes small, co-located teams over large distributed teams — fewer barriers to communication.  That’s why agile emphasizes user stories on index cards, simple personas, and face to face communication over documentation — its easier to exchange ideas and information, to re-arrange and update the knowledge-base.  Agile emphasizes working code as documentation because the working code is a clear concrete thing that the entire team can gather around and say, “yes, this is right” or “no, it should be some other way.”

Agile in our Enterprise

I’m going to hold this for a future blog post…this one is long enough as it is.

Other Conference Observations

• I thought I’d be hearing lots of people at this conference saying, “do it in Rails” or “Django” or <name your new-fangled web framework>; I was surprised at all the java and .NET technical talks.
• I loved the Musick Masti sessions over lunches and at night.  I got to go down a jam on a sax they had there, as well as play various percussion and other instruments.  That was a lot of fun.  That seemed to be a theme the conference organizers were going for…things should be fun!  The Monday night social/networking event was a good example — various wiis and other games were strewn about the vendor hall providing opportunities to interact with other people through games.
• SO…MUCH…SWAG.  Wow…I brought home almost a whole suitcase full of free books, balls, silly putty, race cars, planning poker cards, t-shirts.

* 1) dodgy conference wi-fi access.  You’d think ubiquitous wi-fi access would be a given at a techy-geek conference like this.  It was great in the Open Jam area where people could congregate and talk about whatever, but it wasn’t as good elsewhere, 2) my Airport wireless card has been giving out for the last few weeks, and finally died at the conference.  Luckily, the Chicago Apple Store is not far from the conference venue — they sent it in and fixed it for free, even though my AppleCare expired in April (I love Apple’s customer service, and the fact they know that I’m pro

Pragmatic Personas

by Jeff Patton

Pragmatic personas can be fast, based on user research, but can also draw on your own experiences (according to Don Norman)

Identify User Types or Roles

• Different kinds of people are user types (student, professional)
• User Role describes the relationship a person has with your product (thing-doer, eg late night pizza buyer, daytime lunch seeker)

Profile User Types

Personify User Types to Create an Example User

Consider Product Design Impact

User Stories

Mike Cohn – (slides)

Software requirements are a communication problem; balance is critical.  If business side dominates, functionality and dates mandated with little regard for constraints.  If tech dominates, we make them speak technical jargon and we lose the business need, drivers.

We cannot perfectly predict a software schedule.

So…we make decisions based on the information we have, but do it often

We spread decision-making across the project, rather than making one set of decisions…

Stories

Stories are (Three C’s, Ron Jeffries)

• Card (Note card) – Most visible part
• Conversation – Promise from dev team to product owner: “We will come talk to you before we start”
• Confirmation – Acceptance criteria

Short story about a system feature told from the perspective of a user.

As a …<user> I want to…<goal> so that…<reason>

Sometimes, you need more detail about a story.  You can:

• Create new, smaller, more specific stories.
• Define ‘conditions of satisfaction,’ which are really acceptance tests.  “What does the product owner need to see so that we can know this story is done?”  This basically becomes the ‘script’ for the Sprint review.

User Roles

Broaden scope from looking at one user

• Allow users to vary by:
• What they use the software for
• Hwy they use software

This is different than a persona, where personas are about a specific user (based on research), designed to induce empathy in the design team.  User roles are more broad, describe types of users.

Can do user role brainstorming to identify different roles:

Thinking about your product, everyone writes a role on an index card.

• Brainstorming, no judgement on what the roles are
• Put related roles near each other
• Combine, consolidate, remove

Advantages of using roles

Avoid saying “The user”.

Can also have system and programmer users.  “As a payment verification system, I want all transactions to be well-formed XML…”

Stories, Themes, Epics

User Story – Description of desired functionality told from user perspective
Theme – Collection of related user stories
Epic – Large User Story

Themes, Epics don’t really imply size…Themes aren’t necessarily bigger or small than Epics.  They’re just labels.

Mission Possible

This is the followon session to the previous Guerilla User Research session.  The theme here is taking the insights learned from User Research and turning them into actionable design.  The goal of this series of talks is to demo an application on Thursday this week.

Communicate Design

• Personas
• Workflow Stories / Scenarios
• Task Analysis Grids

Personas

• Quote
• Day-in-the-life story.  Contextual/specific to what the person is doing right now.
• Goals
• Pain Points/Frustration
• Opportunities
• Activities

Design tool

Storytelling

Way to build empathy on users

Based on user research

Todd talked about the DNA chart…

Workflow Stories

Scenarios are stories that happen in the day of a life of a key user.  A narriative form that tell a story of people using the system.  Tasks are the granular items, connected to how important it is to different users.  This can be used to prioritize possible features.

Empathy is one of the key points of why we do user research.  This is a bit of contention with the Agile methodology and ‘user stories.’  User stories may refer to ‘average user,’ which often means ‘me.’

Good to use multiple points in order to generate personas:

• Project Stakeholders
• Customer Representatives (Customer Service Reps)
• Actual Customers
• Someone you know

Task Analysis Grids

Work back and forth between personas and Task Analysis Grids.  The idea is to get a holistic view of what the system is supposed to do overall.  Then go back to figure out the order/priority in which features are built/released.

• Scenario Based
• Incorporate personas
• Prioritized

Persona Creation and Critique

We broke into several groups.  Each group created a persona based on the user research generated in the previous session.

Guerilla Research Methods

Russ Unger, Todd Zaki Warfel

Traditional barriers to UX research: Time and Money; customer/stakeholder perceived value, and the attidude that “We don’t have time and money to do this.”

Argue, “We don’t have time and money to NOT do this…”  Spend a few hours doing some research, in order to allow you to make data driven design decisions

Each methods have strengths and weaknesses.  It’s good to combine multiple methods

The Burrito Lunch

• Send out an email, if you fit a profile, come do this, and we’ll give you lunch
• Chocolate snacks are a helpful way to get people to fill out surveys

Crowd Sourcing

• Using social media, other tools to get people to give feedback.  E.G.  Twitter, Facebook
• Coupled with web analytic data

Man on the Street

• Simply just going out and asking people, note trends.

User Research: “You never ask the question you really want answered.  If you ask the question you want answered, you’ll miss all kinds of rich information.”

User Research…one of the benefits of the agile UX methods is that you can bring prototypes to user research sessions: gives you access to users, do validation of current design, and research for future sessions.

Designing the Box

• Get people together, some Sharpies, paper, ask people to design the box the product, tool, service would come in.

If this was a COTS product, what are the key features that need to be front and center.  As a UX designer, gives you insight into the thought processes involved in prioritizing features, etc.

Guidelines for asking better research questions

• Provide context: “Did you have coffee yesterday?  How much coffee did you have yesterday?  Was that a normal day?  How about the day before that?”  It’s our job as researchers to ask questions and identify trends, amounts, etc, rather than asking them directly?
• Helpful to start with a most recent or most memorable experience.
• Start broad and open ended
• Funnel and narrow questions

People want to tell you about their lives.  If you can facilitate in a way that allows them to tell their own stories, people are willing to talk.  Another way to help people talk: “I’ll share a story about me, then you share a story about you.”

Servicing Technical Debt

I’m heading to the Agile2009 conference next week, and looking forward to it.  It’s sort of fun watching the twitter chatter about the conference.  Some ads/pimping products and services, but also some of the conference presenters are talking about how they’re getting ready, and even posting their slides!

Someone retweeted this video from Ward Cunningham (yes, the one that invented the wiki) about the metaphor of ‘technical debt.’  Basically, when you are coding short term solutions that you know don’t completely address the core problem your code is designed to address, you are incurring ‘debt,’ similar to the way you incur debt when you borrow money.  Until you repay that debt, more and more of your effort will be consumed servicing the debt.  You’ll spend all your time patching holes, and won’t have any time to address new features or take on new projects.

This metaphor is directly applicable to one of my work projects.  It turns out that when we originally designed the system, we ‘missed’ a requirement.  After the product went live and business users started seeing it, they realized that there was something else it needed to do in order to align with their business rules and customer contracts.  Since then, we’ve had to build certain workarounds in order to address this discrepency.  Cunningham would argue we’ve incurred technical debt, which we need to repay by refactoring and revising our code in order to reflect our current understanding of the business processes. 

That refactoring/revising is a key part of Agile development.  We have a few challenges with that.  First, I don’t think we have enough unit test code coverage to be confident our refactoring doesn’t break anything.  Second, it’s difficult for us to find time to go back and fix things because all the new things people are asking us to do are piling up, and of course those are higher priority.  I think agile people would say we need a Kanban process.  Third, the powers-that-be don’t see the value in going back in reorganizing something that ‘works,’ so it’s hard to argue for the need to service our technical debt.

I’m hoping to learn more about how to address these challenges at the conference.

ICWSM Paper Titles – Wordle

ICWSM Paper Titles – Wordle

Originally uploaded by fitzgeraldsteele

This tag cloud was generated from all the paper titles that were presented at the ICWSM ’09 conference (http://www.icwsm.org). I don’t think anyone is surprised that ‘social’ is the major term.

ICWSM Liveblog – Wordle

ICWSM Liveblog – Wordle

Originally uploaded by fitzgeraldsteele

This tag cloud was generated from my liveblog of the ICWSM conference (http://fitzgeraldsteele.wordpress.com/tag/icwsm). I think it is interesting that people shows up as the biggest term here, where it hardly registers in the paper titles.

Tagcloud generated by http://www.wordle.net

ICWSM Keynote: Jon Kleinberg – Meme-tracking, Diffusion, and the Flow of Online Information

Intersection of news media, technology, and the political process.  Modern SM technology is a disruptive technology, similar to radio/TV in the 20th century.  How does information transmitted broadly by the media interact with the personal influence arising from social networks?

SM erases difference between global and local influence, making more of a continuum.  Speed of media reporting increasing, contributing to a 24 hour news cycle.  “A Challenge to healthy discourse.”  Online media also adds complexity to how political info flows through social networks.

The dynamics of the global news cycle

Examined if the ‘news cycle’ is a metaphorical construct, or is it visible in data.  If it’s visible, can we measure it, describe it?  Used data from Spinn3r, looked at 1M news articles and blog posts per day, 20K sources.

What basic “units” make up the news cycle?  Need some aggregate of articles, vary over the order of days, and handles half-terabyte of data.  Look for “memes”, identify text fragments, phrases, quotes that travel through many articles.  They create a weighted, directed, acyclic graph of mutational variants, that delentes min total edge weight such that each component has a single “sink” node.  This problem is NP-hard, but can apply heuristics based on selecting a single edge out of each quote.  Produces a neat stacked histogram graph that shows the relative frequencies of stories related to a particular quote over time.

Use some analogies to describe temporal variations: eg species competing for a resources in an eco system, or biological systems that synchronize to favor a small number of individuals at any point in time.  A model to describe this might include: imitation term, recency term.

Found a 2.5 hour gap between peak intensity of the story in mainstream media, vs when it peaked in the blogs.

Can also use the data to find stories where blogs lead the media.

The spread of political messages through social networks

Might look at Chain-letter petitions as ‘tracers’ through global social network.  These are good because 1) they are viral – only get via email, 2) comes with its own tracer (signatures on it).  Can’t see the full tree, but copies get posted to mailing lists, which can be found by search engine.  So they can build a partial tree, compensating for the mutations in the signature tree.

It turns out genetic mutation analogies are good…all kinds of mutations happen (people erase names, put funny names in the middle, etc).

Built the tree from two chain letters, and it looked funny.  If we’re in a small world network (six degrees of separation), why is the tree very deep and narrow, like a depth-first search tree.  Why?  Possible timing effects, assuming that nodes act on messages according to some delay.

So we can make some initial analogies like mutation, biology.  But these are really complex, global phenomena, that require richer models and knowledge of human behavior.  Ideas from computing and online media will be crucial to the next steps.