Does your app contain, display or access third-party content?
This article gives a good description of the new question that Apple added to the app submission process, and explains why Apple is asking for this info.
Does your app contain, display or access third-party content?
This article gives a good description of the new question that Apple added to the app submission process, and explains why Apple is asking for this info.
Marvel’s iPhone app for creating prototypes from sketches is a great option for anyone wanting to design and communicate an app concept without having to do a lot of Photoshop work. Clickable mock-ups can be very effective to communicate interactive design. If you do have more polished mock-ups than just pen-on-paper and you want to make them interactive, you can use either the main Marvel solution or Flinto.
Read the original article on TechCrunch.
These days, if you’re building a stand-alone web page like a landing page, a whole web site, or redesigning part of your site, it just makes sense to build a responsive UI from the beginning.
A responsive design can make your site look great and be easy to use regardless of the screen size used to view the site – on a big 24” monitor, a laptop, a tablet, or a smartphone. This works by automatically adjusting the web page layout and element sizes, depending on the browser width. You can see this on your computer by navigating to a responsive web site such as The Boston Globe, and then grabbing the right side of your browser window and slowly dragging it to the left to reduce the browser width. You’ll notice certain parts of the page shrink in size, change their position, or even completely disappear.
Here’s how the page might look with the full-width browser:
Now, reducing the browser width to roughly the size of a tablet, notice how the far-right column disappears, and the top navigation links have changed:

Now, shrinking the browser down further to more of a smartphone width, notice that the layout has changed from a two-column layout to a one-column layout and other changes:
Notice how the text is appropriately sized such that if viewed from a mobile phone, you don’t have to zoom in to read the content or view the pictures – it’s simply presented well for a smaller browser experience.
Sites that aren’t built with this capability require visitors on smaller browsers to zoom in and scroll around to consume content or even interact with links and buttons, which significantly impacts the mobile experience.
Responsive design is actually a broader category of design methods. For example, you might have seem some sites that dynamically change their layout or animate certain features as you are scrolling down the page. In this article, I’m just focusing on adapting to different browser sizes because it’s the most commonly used feature, but just be aware there’s a lot that can be done beyond this.
Assuming you want to create a responsive page or site, you’ll need to first clarify exactly how you want your site to behave. If you’re working with a designer, first figure out how many distinct layouts your site will support, and what browser width will trigger each layout. In the Boston Globe example above, there are approximately three distinct layouts:
Then, once you’ve designed the number of layouts and various width triggers, you should create wire-frames or full designs for all of the pages on your site for each version. You might be able to cut some corners here, but if each page has different content and layout, then I’d strongly suggest having a design created for all of the above.
For example, if we were making a simple site with a Home page and an About page, we would want to see designs for all of the following:
Then, once you have this defined, the development team will be able to really match your expectations on how the site should function and behave in different browsers.
Here are a few examples of this in practice:
And here are a few sites that list out some fun variations on responsive design, including some of the more advanced features from which you can pick and choose when designing your own site:
A lot of products fail. And not just because of funding challenges or stiff competition.
Over and over, someone will have an idea for a product, spend a lot of time and money building out their vision and doing a big launch only to discover after a few weeks or months that no one actual buys or uses their product.
Essentially, they fail because the product is built based on the creator’s vision instead of solving for customer needs first.
Instead, it’s absolutely possible to be more aware during product development, arrive at a product design that people will actually want to use, and to save tens of thousands of dollars in the process.
I’ve studied and employed the Stanford Design Thinking approach to product design, and in my experience it cuts out the extraneous resource-wasting parts, and gets straight to the core of defining a product that will delight customers.
The Stanford approach consists of a cycle of five stages:
1. Empathize – interview with two people from your team, observe person in their normal routine or context, making note of what they say and do.
2. Define – in a group, unpack observations from interviews, interpret what they were thinking and feeling to determine main emotional drivers, and write/select a problem statement.
3. Ideate – in a group, brainstorm ideas for solutions, following a specific brainstorming and focusing process.
4. Prototype – in a group or individually create a low resolution prototype to use in the interview as a conversation piece.
5. Test – interview (can be combined with #1), observing the person’s reaction to the prototype by what they say and do.
To me, the biggest difference between this approach and others is observation at a very personal level, which is the “Empathy” stage. Many of the stages in this method are used in other design methods, but in this case they are combined and balanced in just the right way. This cyclic process also shares a lot with agile product development, mainly short iterations with feedback in each iteration, but the purpose and outcome here is not necessarily to end up with a functional prototype. The desired outcome is the description of a product that answers to the emotions of a small sampling of individuals who you have interviewed – maybe 3 to 8 people per cycle. Therefore, observing an individual in their regular day-to-day context to determine their emotional drivers is where this all begins. From my perspective, this is the biggest component lacking from the majority of product design today, and explains why there are so many products and features of products that just make you ask “what were they thinking?”
Keep in mind when studying this approach that we’re not talking about spending weeks building a prototype, then going out into the world and asking people “do you like this?” and “would you buy it?” This will cloud your customer observation, yield untrue answers, and mislead your product design. This applies especially during early phases of designing a new product, or designing a new feature of an existing product. Instead, you will be creating extremely “low resolution” or low-res prototypes. For a web site, this might mean a sharpie drawing on a piece of 8.5×11 paper. For a physical product, this might mean cardboard cutouts assembled with tape and rubber bands. It’s actually intentional to not have a polished mock-up or prototype initially, partly because it will get you more honest feedback when you place it in front of someone – they’re not afraid to be blunt. Instead if you put a highly polished prototype in front of someone, they will likely be thinking “well, it looks like they put a lot of time and money into this, so they must know what they’re doing, and I don’t want to hurt their feelings either.”
The other key thing you’ll have to accept is that your product is going to have to evolve during this design process – possibly pretty radically. You won’t – and shouldn’t – end up with what you originally envisioned. Every iteration you run through, you should have at least a slightly different product definition. If you’ve been through several iterations and there’s been no change, you should question whether it’s time to move on to creating a more functional prototype because you’ve done such a good job of product design up to this point and you feel the definition has stabilized, or whether you should go back and review the guidelines of the Stanford approach to see what’s causing stagnation. Either way, I’d expect to go through at least 5 to 10 (or better yet – 15 to 20) iterations before starting to feel comfortable enough to invest dollars in creating a functional prototype.
The great thing is there’s a ton of material freely available online on the d.school web site that guides you through this in detail. I’d specifically recommend checking out the downloadable PDF called “The Bootcamp Bootleg” here. There are also videos and resources to run your own course for others on your team. Of course, you don’t have to follow their guidelines exactly – you should adapt to your organization – but it’s worth following the five steps, and learning their approach for each step to choose which pieces work well for you.
It’s extremely exciting to realize that with each iteration, your design is actually becoming a more and more useful product, and that you’re saving a large amount of time and money by waiting to implement until you have really vetted the design. I’m always hopeful that more and more companies will follow this approach. It’s the natural evolution of things.