Archive for the ‘Design Process’ Category

How to Build a Fantasy App by Using Magic (Strategic Design 4)

Wednesday, January 25th, 2012
plato-bust.jpg-tm

"I endorse this message" — Plato

The strategic design of our next app, Languages, continues apace.

In the last post we gained an understanding of our personas’ experience without an app. We now need to imagine how an ideal app could make this experience 100% better, without worrying about bothersome constraints such as money, technology, time, or reality. It’s time to build a Platonic app (Plato, as you’ll recall, thought that all physical things are fail and that their is an ideal, perfect form of all things floating in heaven). Construction materials include aether, fluffy-golden clouds, and joyful thoughts.

It is essential to have a vision of an ideal app so that we know to what our imperfect app should aspire. You have to have a clear understanding of the ideal if the real is going to approximate it.

Here’s how it works. We look at our three experience domains (solo, social, and travel), look at all of the experience nodes in those domains, and then yell out ideas for how an app could improve those nodes 100%. Jeremy then writes these ideas on a sticky and posts them in our “ideal assistance” section beneath each experience node. The aggregate of all these ideas is our fantasy app.

Right

Please pardon the calligraphy and the shaky-cam.

For example, when we examined the “social” domain, we determined that when you’re in a business meeting in Milan and an Italian colleague says “sono molto dispiacentissimo” you want to be able to nod your head and find out what that means without him knowing that you have no idea what he said. You don’t want to look like a fool. So we wrote down “incognito,” indicating that the ideal app could feed you definitions on the sly (of course this sounds impossible; but stick around). We also determined that an ideal app would feed you definitions extremely quickly, because you don’t want to spend five minutes in the street figuring out what “Achtung! Achtung! Ein Auto kommt!” means.

Once we have posted all of the characteristics of our Platonic app on the wall, we go through and draw a big, red x over all features that (1) are beyond our means or (2) would bloat 1.0. We call this step “killing the baby.”

Finallynow1

Killing the baby is a traumatic experience for some.

So, of the two feature examples above, we put a big, fat, red x on “incognito” due to technical constraints. But we kept the idea of quick definitions because we felt that it was doable and essential.

What we’re left with is the list of features that will appear in Languages 1.0.

Mapping out the User Experience (Strategic Design Part 3)

Thursday, January 19th, 2012

early_map

Back to Languages.

So we are describing the process of strategic design, in which we figure out the company’s goals, the user’s goals, and the intersection of the two. The purpose of this is to create an app that exists at that point of intersection. First, we established Tapity’s goals for the Languages app. Then we developed user “personas”—fictional users with concrete characteristics. Now we can move on to the next step of strategic design: user experience mapping.

Now that we have our personas, we need to map out their current experience without an app. This helps us create an app that is tailored to the user’s actual experience. Those who skip this step risk creating a list of features that sound helpful in the abstract, but are not helpful to users in their actual experience.

First, we need to decide what the major experience domains are. An experience domain is simply an area or realm of experience. In the case of Languages, we decided that they were (1) “solo,” (2) social, and (3) travel. Solo involves any linguistic situation in which it is just you and the language; reading a foreign book, for example. Social encompasses any situation involving discourse between you and someone else. And travel explains itself.

We put a big sheet of paper up on our Tapity-blue wall and then demarcate the three domains. We then place our personas on the far left of the paper. Now we’re all ready to map our our personas’ experiences across the three domains.

Finally1

We first turn to Emily, our student, and analyze her solo experience. She studies French. So we decide that she (1) looks up French words for her workbook exercises, (2) looks up words for writing essays in French, (3) looks up words while reading Les Misrables, and (4) uses a physical French-English dictionary. We put up stickies with drawings to represent all of this.

Finally-2

We then repeat this process for all of our personas across every domain. We try to cover all possible experiences in order to get the fullest possible picture of what we’re dealing with. The wall gradually fills with stickies.

Finally3

Now the appless user experience is storyboarded.

Next time, if our app could do anything, how could it produce an ideal user experience?

Mobile Accessibility: First Impressions

Wednesday, December 21st, 2011

Accessibility Icon

On December 5-6, I attended the M-Enabling Summit in Washington, D.C. The purpose of this conference was to consider how to make mobile devices and applications accessible to persons with disabilities and the elderly. I am new to the accessibility field, and I want to share my initial impressions and take-aways from the standpoint of an app designer:

Nothing about us without us. The siren call at the conference from those with disabilities was “Nothing about us without us!” People with disabilities are used to being thrown a bone here and there so that corporations can say they have “done” accessibility. What is really needed is what good designers provide: development of apps (and devices) based on a thorough user experience analysis that is based on thorough input and feedback from actual people with disabilities and elderly people. Design of this sort comes naturally to good designers, but we do not always have clients willing to pay to do this kind of design work for people with disabilities or the elderly. For businesses who really want to do some good by these folks, have the user experience design done right for them, which also means with them.

Government mandates needed? There was a definite tension between those who want to ensure accessibility through government regulation and those who say that well-meaning government regulation in this field actually stifles innovation and progress in this area. The most sensible argument of the pro-regulation folks is that the market for users with disabilities and the elderly is too small or too fragmented for businesses to cater to it without being required to do so. The most sensible argument of the anti-regulation folks is that mobile devices themselves are a huge boon to the disabled and elderly, and we did not get them by government mandates. One thing both camps can agree on is that the more the market for users with disabilities and the elderly users can be identified and quantified, the better off everyone will be. With a reported 6 billion mobile subscription in the world and probably at least 1 billion of those held by the elderly or persons with disabilities, I think understanding this market in order to cater to it is a promising direction.

Apple, awesome. Third, Apple is way ahead in this area. Just open the Settings app on an iPad or iPhone, tap “General,” then tap “Accessibility.” Explore what is there. Amazing. Check out Apple’s iOS Accessibility Overview. To tell the truth, much of the conference was about trying to provide for Android, Blackberry, and Windows Mobile what Apple has already provided in iOS. The other mobile OS companies hardly seem to be trying in this area. One interesting comment came from Paul Schroeder of the American Federation for the Blind. He said that in a way Apple has hurt us because the other device manufacturers can now say, “they can always just choose an Apple device.” If that is the attitude (and it seems to be), the implication is that the market is not big enough to make it worthwhile to supply such accessibility features. Again, I think that perception could change. And note that the disabled community wants to have the same range of choices in mobile devices that everybody else has. Can’t blame them for that.

Got a lot more to say. Plan to follow up with some more posts.

Personas: some assembly required (Strategic Design 2)

Wednesday, November 23rd, 2011

Now we’ve established how Languages serves our business goals, identified the market, and sized up the competition. We’re convinced that the app is a good idea. The preliminary investigation ends. We can now pull out the microscope to analyze our potential users.

We first have to identify all of their relevant characteristics. We have a leg up, in this regard, because I happen to be a linguaphile. I’ve studied various languages seriously (Espanol, Italiano, Deutsch) and have dabbled in many more (Latin, Greek, Swedish, Old English). I’ve studied languages over an extended period of time and in many academic contexts. I’ve used all sorts of translation dictionaries, physical, digital, and mobile. So I basically embody many of our use-cases (not the business one, unfortunately).

After thinking about it, doing some research, and banging around ideas, we come up with a list that runs the gamut of user characteristics. It looks something like this:

Screen Shot 2011-11-23 at 1.26.56 PM

We identify which of these characteristics we should focus on. We decide to not worry about the professorial use-case, reasoning that foreign-language professors either won’t need Languages or will demand something much more academic and rigorous than we want to provide. We put asterisks beside the characteristics that we deem important.

We take the salient characteristics and click them together into several personas. These personas, on the one hand, embody the important user-characteristics; but they also help us think about how our app fits in the context of a real person’s life. Personas bring us out of the abstract and into the concrete. And we find that abstract thinking is the death of good UX. Concreteness, on the other hand, forms the foundation of good design.

We then come up with this:

Screen Shot 2011-11-23 at 1.40.58 PM

Now we’re designing for “actual” people. We can now barrel ahead into the next stage of strategic design: mapping out the user’s experience.

We’re going to need a wall for this.

DSC_0655

Our Secret Sauce

Thursday, November 10th, 2011

And now our discussion of Languages must pause for a brief interlude.

Screen Shot 2011-11-09 at 7.52.49 AMThree years ago Jeremy began blogging about how to design great iPhone apps. Since then he and we have been flailing around, trying to discover the perfect process. After three years of reading, researching, head-scratching, and good old-fashioned trying, we’ve developed the recipe for great iOS design—our secret sauce. We’ve learned many lessons from the gurus and Buddhas who went before us. But we’ve also tailored their insights to the iOS universe. And we will demonstrate this tailored process in our development of Languages.

The sauce breaks down into three steps: strategic design, interaction design, and visual design.

Strategic design

stratego-1

Long before you start placing buttons and pushing pixels, you have to ask some fundamental questions: Why in the world am I making this app and who cares? The purpose of the strategic design phase is to find answers to those two questions.

Strategic design requires that you to ask, “How does this app help me meet my personal or company goals? What’s in it for me? What’s in it for my business?” But strategic analysis also involves much more than gazing into the mirror pool of your soul. You must also survey the app’s market and pick apart the competition.

Additionally, you have to zero in on your potential users. We assemble a comprehensive list of user characteristics. We then click these together, lego-like, into several personas that cover all the most important characteristics. Next, we map out the user’s current experience without an app. Then we fantasize how an ideal app could better this experience. This leads us to a set of features, which we then whittle down to what is doable.

Interaction design

This is a TV remote.

This is a TV remote.

Once you know your app’s scope and the personas you’re designing for, you can begin wireframing. We generally use OmniGraffle to create preliminary sketches of the interface. During this process we constantly keep our personas’ goals in view. One of us takes the lead to create a rough draft. We then show one another what we did and debate and iterate, debate and iterate until we’re both convinced that we have the perfect design. We also interact with users to get further insight.

Wireframing requires a vividly experiential and empathetic imagination. This is because you have to constantly imagine how the user would experience and interact with the buttons and bars and elements that you’re cobbling together.

Visual design

Screen Shot 2011-11-10 at 10.55.09 AM

Once we are satisfied with the interaction design, we begin the process of beautification. We fire up Photoshop and create the “skin,” the graphics.

But visual design entails much more than applying makeup to the wireframes. It allows you to improve the interaction design by making the interface clearer. Color, line, shape, and texture bring certain elements to the fore, deemphasize other elements, and guide the user’s eye. This can make the interface even more intuitive.

And the other purpose of visual design, for us, is to take a functional app and make it more than that—to make it absolutely delightful. Subtle touches, neat little quirks, real-world themes, Easter Eggs—these are all things that come in during the visual design stage that add a factor of delight.

Languages: our next product

Tuesday, October 18th, 2011
poli

"Polly voos Fransay?"

In the spring of 2010 we launched Grades. In the spring of 2011 we launched Grades 2. Now the summer’s over and gone. Autumn is here. And powered by pumpkin pie we’re barreling ahead into our next big thing. It’s called Languages.

sonico-mobile-logo-blogWe’re extremely pleased to be partnering with the awesome guys over at Sonico Mobile. They won fame and fortune creating iTranslate, which has gotten over twenty million downloads and was featured as an all time top 100 app. They’ve also created other cool apps such as iRadio and Music-Quiz.

After the success of Grades 2, Sonico contacted us. They wanted to know if we were interested in helping them bring one of their ideas to life. We were honored and happily obliged. In the coming weeks and months we will reveal more about what the app is and does. Suffices to say it has something to do with language, but is different from iTranslate.

We are currently strategizing, in coordination with Sonico, about what kind of app this will be specifically (personas, use-cases, and all that jazz). Then we will design it, Sonico will build it, and we will both market it together. We will be documenting the process with blog posts and videos, recording our app development process from strategic design through launch. We’ve learned a lot since the last time around and we hope these scribblings will be of interest and maybe even of help to app designers and developers everywhere.

So pull up some pumpkin pie, snag an apple spice latte, throw another log on the fire, and stick around for this new and exciting story.

Charrette, cha-what?

Sunday, September 4th, 2011

In my previous work in mixed-use land development, one of the most valuable things I learned was how some of the best urban designers use a process they call a “charrette” to design places. The urban design charrette typically brings together all of the stakeholders in the design of a new place—say a new community—for an intensive design effort over a period of 2 to 5 days to establish the essential design of the new place. The urban design charrette has the following key characteristics:

An urban design charrette

An urban design charrette, process and product

  • It is lead by a professional designer.
  • It includes all of the major stakeholders in the project and people with critical expertise for the project: the owner of the project, government officials, nearby residents and business owners, civil engineers, architects, etc.
  • It is collaborative and interactive, with everyone present being able to participate.
  • Pieces of the design go through multiple iterations quickly, typically using see-through sketch paper to redo designs based on previous iterations.
  • The atmosphere is collaborative, collegial, and fun!
  • Once the design is worked out at the sketch level, the designers take an initial crack at bringing the design to life with conceptual architectural elevations, and even a 3-D perspective rendering of part of the plan.
  • The result is that in a very short period of time, the basic design of the project is produced, multiple design problems have been solved through the participation of all necessary parties, and  all the key players have a thorough buy-in to the design that was produced with all of their participation.

The charrette process itself is delightful for everyone involved. It creates such a sense of mutual accomplishment and collegiality by the end that it sets an incredibly positive tone for the design and development work that lies ahead. It produces visual products that are used not only to direct the further design work, but that can begin to be used to market the project to banks, investors, and even the end users (retail and office tenants, homebuyers, etc.).

As we launched Tapity, I wondered if such a process could be useful in digital design. We have begun to incorporate this kind of process into our practice, and we have had fantastic results with it. We want to refine our techniques to make the process as efficient, productive, and delightful as possible, but we really believe we are onto something. If you translate the list above into characteristics of a digital design charrette, they look something like this:

  • It is lead by a professional designer (this is the role that Tapity plays).
  • It includes all of the major stakeholders in the project and people with critical expertise for the project: the client, the IT people responsible for back-end architecture, potential users, interaction designers, visual designers, etc.
  • It is collaborative and interactive, with everyone present being able to participate.
  • The design goes through on-the-spot review by the stakeholders, using sketches and post-it notes to represent design decisions and changes.
  • The atmosphere is collaborative, collegial, and fun!
  • Once the design is worked out at the sketch level, the designers take an initial crack at bringing the design to life with wireframes of key screens and even preparing some initial Photoshop mock-ups of the visual design theme.
  • The result is that in a very short period of time, the basic design of the project is produced, multiple design problems have been solved through the participation of all necessary parties, and  all the key players have a thorough buy-in to the design that was produced with all of their participation.

I was delighted to discover, just a few days ago, an article in UX Magazine by Will Evans where he describes what he calls “design studio methodology” as a process that “originated in architecture and industrial design schools.” He states that he believes that Todd Zaki Warfel “was the first to apply it to collaborative design of complex software systems.” Then, the first comment to Will’s article by Matt Nish-Lapidus points out that “[t]he method outlined in this article is traditionally called a charrette and has been used in industrial design and architecture for decades.” Who knows, maybe the charrette methodology will find an enduring place in the world of digital design.