Luke Wroblewski doesn’t disappoint in this short guide on Mobile First for designers. Reading through this guide offers a wealth of advice, every second sentence it felt like another simple statement resonating within me. Here are just a few highlights (really) I particularly enjoyed, but for a few quid go and get the whole book:

Growth

• Websites and applications should be designed and built for mobile first.
• Smartphones were boldly predicted to out-ship the combined global market of laptop, desktop, and notebook computers in 2012. They did so in the last quarter of 2010 – two years earlier than predicted. 
• … even if you can create native applications for each platform, the cost of maintaining them can quickly make it prohibitive.
• The combination of mobile and desktop experiences results in more engaged users across both sets of devices.

Constraints

• Screens are small, networks are unreliable, and people can find themselves in all kinds of situations when they pull out their mobile device.
• … design is the process of gradually applying constraints until an elegant solution remains.
• … 80% of the screen space from the desktop was missing.
• … Thinking “one eyeball, one thumb” forces you to simplify mobile designs …

Capabilities

• … mobile capabilities allow you to do: reinvent ways to meet people’s needs using exciting new tools …

Organisation

• Aligning with mobile behaviors also naturally aligns your website with real-world needs.
• … content takes precedence over navigation on mobile.
• … allowing people to explore and pivot to relevant content doesn’t have to mean piles of navigation bars that bury content.
• If you need a fixed menu, better to fix it to the top, as Twitter has done.
• … fingers are imprecise pointing instruments… [ isn't that obvious?, many examples I see say not so ] bigger [not downsized] touch targets are essential.
• Destructive actions like cancel or delete can be placed outside people’s comfort zone.
• Consistency in interaction approaches and gestures more than diversity. See Luke’s detailed guide here: Common Gesture Reference.
• We are in a transition phase from GUIs to NUIs (Natural User Interfaces).
• Develop with progressive enhancement in mind

Refer to Apples guidelines for target sizes and much much more

Inputs

• Take advantage of input types, attributes, and masks to make mobile input easier.
• Select menus are pretty tap-intensive: tap the menu once to open it, swipe the list that shows up to find the answer you want to select, tap it, and then tap down or close to go back to the form.
• HTML5 input types can help people accurately answer questions that require a specific format.
• … take the height of virtual keyboards into account …
• Actively encourage input and allow people to contribute and create using their mobile devices.

Layout

• … the meta viewport tag is really useful for designing mobile web experiences.
• Forget pixels and instead concentrate on points, for example on all iPhones this is consistent at 320×480, only the pixel density changes.
• Render rounded borders & graduated backgrounds using CSS3 but not to many or performance will be compromised.
• Flexible layouts which expand and adjust to the available width of the device are essential.
• Use break points to provide differing layout rules at significantly different device criteria. See more in Responsive Web Design.
• Consider the differences between connected TVs, desktops/laptops, tablets, smartphones, and feature phones.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

How do I write a good user story?

1. Consider the user

By practicing user centered design you face a greater chance of understanding the exact requirement implementing this feature will provide. So make sure that the user story is written from the perspective of the end user in their language to achieve exactly what it is they want to achieve.

Its worth considering the difference between:

Implement a secure access 4 pin unique code which is digitally encrypted and expires after 15 minutes.

and

I need to make sure that the content is secure but easy for people to use, they have a pin number for our other systems could we use that and make sure they have to re-enter it if they walk away from the tablet.

In the first example its not clear to anyone why and what the outcome will be of implementing this. However in the second description it is clear why this is necessary and what the outcome will be. This makes it clear for everyone involved.

2. Keep them short and simple

Just enough to make it clear to everyone, no one appreciates reading too much content which could be re-formatted and presented in a way which is clear, precise and accurate. KISS!

3. Quantify the effort involved into units of a day or week

Once we have a good user story you should be in a position to work with a developer (if you are not one) to provide a robust estimation of the work involved (beware of risks and unknowns). Approach this task with a view to identifying the days and hours involved. If the task is smaller than a day consider batching a few other short tasks together. Remember to consider what else might be involved and point out that this is the time to conduct the implementation of it only.

Once you have a collection of user stories you should expect to implement between 3 and 6 user stories per a week. Of course this varies if you have more developers buts its a reasonable way of monitoring the scope and complexity of each user story if this becomes wildly wrong in reality.

4. Ensure you can verify and prove it

Once its been implemented you should be able to revisit the user story and test it. A good user story is one which when revisited you can verify that its been achieved.

Its worth considering the difference between:

Make the web site usability easier for users to navigate.

and

Adjust the user interface so that a prominent start here, navigation bar and favourites menu can be easily and consistently located on every page through-out the website.

Defining the user story this makes it easy to test and therefore prove it has been achieved.

User stories are a great way of capturing understandable information in a format more than just the analyst can work with but as Scott Sehlhurst points out you must remember to iterate and communicate often with the client to iron out the details.

Resources:

A short and rough guide to user stories however if you want to see a more in-depth explanation check out this book (it really is the 101 of user stories):

User Stories Applied: For Agile Software Development by Mike Cohn

More about Mike Cohn who is the owner of Mountain Goat Software.

Andrew Fuqua also has some good things to say on  SCRUM user stories

** Update ** And finally I found some good info comparing User Stories and Use Cases by Scott Sehlhurst

Related posts:

1. Rails3 oauth user user authentication with OmniAuth Once again over at railscasts.com Ryan Bates has done an...

Related posts brought to you by Yet Another Related Posts Plugin.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Action Plan:

1. Identify the unknowns
   How? Start simply with broad questions. Don’t be too quick to get into the detail as this will be the natural tendency. At this stage understand nothing about the detail but fully comprehending the end user environment or capabilities will give you a greater barometer for detecting where the unknowns are essential or not.
2. Questions everything, assume nothing
   I’ve tripped over this many times, combined with one this is probably the largest probably when scoping, initiating or specify an integration piece of work. I find Excel is my friend in this situation, I can capture questions and responses as the knowledge flows
3. Seek documentation but don’t rely on it.
   Documentation in what ever form is usually well intentioned, but out of date, inaccurate or just plain wrong. Typically the documentation will look grand ‘Technical Specification for X.Y.Z version 1.2′ however what tends to happen is that was written at the outset before a line of code had been written – ask yourself when you last went back and updated a specification at the end of project, yet you want to make key integration decisions based on it?
4. Get a setup of the system as close as possible to the real environment for use during development, verification testing and UAT
5. Commit, integrate and test regularly. Really if your not doing this forget it
6. Use real data not ‘lorem ipsum’ or ‘test account 1′
   Demand this especially if you have translation or localisation considerations to consider.
7. Allow your/encourage your client to come and inspect your work – they may see things your developer mind over looked.
   Coming from a developer mind I’m always surprised how easy it is to be lulled by our perspective on systems.
8. Testing
   Even with all the automated testing, eyeballs and code reviews I’m still amazed by how often I come across developers who see it as acceptable to ship code from their development computer to a production environment without any testing.

Have I overlooked anything you find works best for you? Let me have your comments and I’ll add them in.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Six Thinking Hats is the concept that innovation, judgement and thought can be better managed and facilitated within a group if the group organises their collective thinking processes around a set of specific areas.

Each hat represents a specific area of consideration or thought and for simplicities sake you often see them represented with different colours. I’ve used this personally over many years and found that with time a. you can become faster but b. it takes time to perfect. The tools are useful for innovation but they can equally be applied to strategy enabling you to flesh out and balance a strategy considering the full range of inputs and therefore logical outputs.

During a recent workshop I attempted to use this model for technical innovation, scoping and design. Much of the work I’m interested in is understanding the real business requirements and desires such that I can translate this into a process and therefore into a software solution. I stress real business requirements because in my experience what I’m presented with at the start often differs from the final needs. In effect there is a part for me to facilitate the discussion and also capturing it as it comes to light.

With any task these days time is money and being swift, focus and accurate are critical during this stage. So using the six thinking hats should work…

Hat 1:

Is concerned with questions and facts. Well that was excellent we started the discussion collecting together the initial facts/needs we had about the solution. The white board was our friend and having allowed our self with 20 minutes we finished feeling like a second pass was necessary but that we’d made a start. The nice experience was the shared concentration, each time something not to do with Hat1 surfaced it was immediately parked.

Hat 2:

Is concerned with the emotional, irrational aspects. This is not so easy simply because of the lack of time we’ve had to work together (kick off meeting) and that its not immediately obvious that this should have a relevance on our task. However after a short pause we did gather to gather our emotions and it was pleasant to find them largely similar. In this case around the desire for success, daunting hill to climb and concerns over failure to bring the essential elements out.

Hat 3:

Is concerned with judgments. Beneficial but challenging was the outcome here. The problem with this stage is that you need to criticise the solution, need, business case to unpick where there may be logical arguments which challenge the need for it. Our discussion unearthed a number of things which in Prince 2 might go onto a risk register. In our case we decided once again to not try to judge the arguments, if we felt they were valid then onto the whiteboard with the desire to return to each and ensure we had a mitigation in place at some stage during the spec phase.

Hat 4:

Is a pleasant stage where we all dust ourselves off from the previous stage and now focus on the positive points. In effect the positive points indicated a range of needs which weren’t focused on in the RFP, some of the more softer aspects such as the user experience, information architecture. As with most software RFP there is typically a lot of focus on the scope of the works with some explanation of the strategy. However its then important to tease out the needs in respect of the structure, and the representation it will take on screen.

Hat 5:

Is concerned with creativity, new thoughts and investigations. In effect this just happens as a outcome from doing each of the other hats. We confirmed in this section that the questions area of the whiteboard captured the unknowns at this point in time and quickly moved on.

Hat 6:

Is concerned with the holistic view. A moment to step back and recheck that the process followed has struct the correct chords and we are moving in the correct direction. Actually it identified that this may well be iterative. With the discussion so far the high-level areas have been considered but there remain holes to fill. Which gave us the drive to create the now and next actions plan. This gave each of us a collection of tasks to go away with and further enable us to cover off some of the more mundane aspects like who is taking on what. Probably not so ‘big picture’ as is intended but given the discussions to date have always been seeking for the big picture this was seen as no bad thing.

Conclusion:

Does it help, yes is the simple answer. More so for it being a new group of people working together and the need to channel constructive energy in a meeting to leverage a brief. However there are pitfalls and gap in terms of facilitating this as a process. Tangents appear which with excited minds can lead to new tunnels being explored which digress from the intention of this structure approach. Would I use it again – definitely given the right group and challenge.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

http://pragprog.com/magazines/download/3.pdf

The temptation is to put these design ideas in the system now because you just know you’ll need them eventually. Over-designing early leads to delaying feedback from real usage of the system, makes adding features more complicated, and makes adapting the design more difficult. By the same token, under-designing makes adding features more complicated, increases defects, and makes adapting the design more difficult.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.