Recently I was approached by Hatch – a startup run by a good friend – asking if I could do some UX for them. Since working with startups has always been a great experience, I was more than happy to help. To find out how I could bring their product closer to their ambitions, I outlined a plan that allowed me to understand the product and the business vision, the current and potential customers and the environment in which they want to place themselves.
Understanding the business and defining the project goals
When I came in, Hatch was already six months in development and wanted to strengthen their focus on agencies and partners and make it a pleasant experience to build applications on top of the platform. This helped me formulate a goal for the two weeks of work: to understand the audience, to address usability issues, to create items for the roadmap and to start with a redesign for the home page.
Find potential customers to test and interview
First, I split up ‘the user’ into several distinctive roles (designer, developer, community manager) and outlined their presumed workflow. Second, I approached some people in agencies to take part in usability testing and contextual interviews. I made some short scenarios and a set of questions to create a framework for exploring and discussing the platform. The tests helped us uncover expectations and a list of enhancements. This allowed Hatch to better prioritise their road map and to immediately update the platform based on the findings.
What we found
Interviewing our participants lead to two interesting findings. First, for their own projects people prefer WordPress, a blogging platform, over specialised CMS platforms such as Drupal and Joomla (something that matches general statistics). The second finding especially useful for the communication is that the platforms agencies worked with, Sharepoint, Lithium, SiteCore, were often not their choice but a platform already chosen and paid for by their clients.
The short schedule created a strong focus, testing and interviewing users early on and during the whole process enabled us to focus on addressing the things that mattered, which were often different from those we had thought were important. The schedule of one testing session every other day allowed to test all the changes directly. The results from the interviews made it possible to outline the features and benefits our participants deemed most essential and therefore should be communicated in the site redesign.
Two weeks might not sound like much, but when you have direct access to developers and customers a lot can be done. The main thing to focus on is not the artifacts but effective communication. Since the developer was sitting next to me, creating sketches for items he was working on and enhancement and bug reports for things he would be working on in the weeks to come was enough of a deliverable to keep things moving forward.
This is a write-up of a talk I gave at Geeky
Thanks to a side project on time mapping I became interested in the design implications of a set of questions that are collectively known as the eternal questions.
1. What are eternal questions?
Eternal questions are concerned with meaning. They arise from people’s experiences with the world, and have no definitive answer. Famous questions are: what is the meaning of life? What is a good life? What makes a good person? What is beauty? What is love?
Although they cannot be answered definitively, this doesn’t mean that they cannot be productively discussed. Through the centuries countless people have come up with answers. Some believed they answered a question once and for all, others were more modest and saw their answer only as one of many possibilities.
Many of us are familiar with Douglas Adams’ answer from the Hitchhikers Guide to the Galaxy: “42″, the answer to life, the universe and everything. But there are many others:
Inspired by the simple and colourful life of Tahiti, Paul Gauguin wondered: Where did we come from? What are we? Where are we going? And came up with a surprisingly colourful answer.
In what turned out to be his final work, Dostoevsky created The Brothers Karamazov a story about three brothers and a father with very different ideas about what makes a good life.
The digital world has no shortage of big ideas: the social revolution, ubiquitous computing, exponential growth until we hit singularity, to name a few. In his talk Jason Scott warns programmers not to be too light-hearted with their creations. Although the twenty-something creators of Facebook might think that time is of no consequence, and take no particular interest in the history of their site, by being the world’s largest photo archive they have a responsibility to their users to care for this data. It’s not just a cost on the balance sheet that has to be kept under control, it is real memories of real people that we are talking about. And although start-up fans might admire the phenomenal success of a certain gaming start-up, when you build a game that “scoops the brain right out of little children” that doesn’t make it OK. Furthermore, if you create a service that allows users to save things, they give you their trust. Respect this trust and treat them and their data with respect.
James Burke warns about the opposite problem, too much focus on the details. In the centuries since Descartes wrote down his second rule of science “to divide each of the difficulties [...] encountered into as many parts as possible” science is now broken up into ever smaller compartments knowing less and less about the world as a whole. This approach brought the Western world a living standard previously unimagined, but, Burke believes, has run its course. We can no longer expect radical innovation by devoting ourselves to even smaller areas, even smaller tasks. We need to go broader, higher and wider, “innovation will come from the no man’s land between the divisions.”
It seems to be a human tendency, that, in our aim to be as exact as possible we either go too abstract or too detailed. Italo Calvino wrote about this quest: “[it] was branching out in two directions: on the one side, the reduction of secondary events to abstract patterns according to which one can carry out operations and demonstrate theorems; and on the other, the effort made by words to present the tangible aspect for things as precisely as possible. [...] I continuously switch back and forth between those two paths, and when I feel I have fully explored the possibilities of one, I rush across to the other, and vice versa.”
By connecting the tangible aspect of playing with the abstraction needed for toymaking, Tom Armitage, proposes a solution of understanding through discovery. Each toy is a little pocket universe, a small concept that can be played with, a way that allows you explore abstraction through play. His idea sounds similar to the idea of the hermeneutic circle, a reading concept where the reader admits that: “neither the whole text nor any individual part can be understood without reference to one another.” Armitage continues: “Toys are a fertile ground for creators to work in. They offer a playful space to experiment and explore. They are a safe ground to experiment with new techniques, skills, or ideas. [...] Toymaking ranges from making realistic simulations of life to producing highly abstract playthings.” Just like design challenges, toys are both defined by that what they highlight and that what they leave out. We cannot understand the world through abstract theories, nor through an endless series of tangible details. The only way is to understand is to take all that is abstract and all that is tangible and mix it in a never-ending process of creation, discovery and reflection. As Armitage ends “through toy making you end up playing yourself” and that might be the biggest opportunity we have.
When you’re working with mockups to test your ideas, speed is crucial. You don’t want to spend days working before you can gain valuable feedback. For that reason Photoshop is often ignored in favour of sketches and wireframes. Using Photoshop, however, to create high fidelity prototypes doesn’t need to be time consuming. Many of the components graphic designers use are freely available on the web and can be quickly remixed to create almost any interface. In this article I’ll walk you through a process that enables you to mock up high fidelity prototypes in a matter of hours instead of days.
Before you begin
To make this work you need:
Grids make it easy to make decisions on what to place where. One of the most popular grids in the 12 column 960 grid that you can download from 960.gs. Pick the psd file from the zip and use it as a starting point for your document.
Add a little more character to your mock-up by using one of the quiet patterns from Subtle patterns.
Bonus: how to make a pattern in Photoshop.
Use Font Squirrel to find a typeface that will give your site a bit of extra character. You can use it for the logo and important headers. The rest of the copy can be in Arial or Helvetica and you can use Lipsum to quickly generate some copy.
Bonus: more on selecting typefaces.
If you look at Dribbble you see that some people are obsessed with creating interface elements. Luckily a group of these people has made their work available for free. You can find many of these elements on 365psd.com.
If you’re looking for some great photos to add to your mock-up, the easiest thing you can do is go to Flickr’s advanced search and check the ‘search in Creative Commons’ photos box, for example these landscapes.
By using a service like InvisionApp you can easily connect your screens and click together a prototype.
Linked two screen together in the Invision app, you can try it here.
Finally you can download one zip with the grid, 5 backgrounds and 5 fonts via this link:
Download the mockup template zip here
Let me know how it goes, and leave a comment if you know more great resources.
This post originally appeared on London-IA.com in February 2012
Lean UX – getting out of the deliverable business by Jeff Gothelf
Jeff Gothelf, formerlly director of UX at the Ladders and currently principal at Proof, an innovation studio in New York, has already made some furor with his concept of Lean UX. In the past we had only his slide deckto rely on, but last Tuesday Jeff finally made his UK debut at London IA.
Jeff’s Lean UX story starts with a retrospective. If Lean UX is such a good thing, then why aren’t we all practising it? Jeff states that long, long ago, there was a world with very young information architects, where every trade had their own deliverables –some had reports, some had code and others had excel sheets– but the young discipline of IA had nothing, nothing but wireframes. In order for IA to claim a seat at the table, the wireframes were used to represent IA. For a while this approach was successful but the good times didn’t last. Web projects became more complex, and in line documentation kept on growing and growing. We now have reached a point where projects are so complex and situations so unpredictable that it becomes impossible to describe them with documentation. Something has to be done.
As a remedy Jeff proposes Lean UX, where real experiences are continuously tested and where people work together towards great experiences in a shared understanding of the problem.
Jeff explains Lean UX in 5 points:
1. Solve problems together. Business, marketing, development and design should start actively collaborating on solving business challenges. Working collaboratively leads to a shared understanding and more motivated and invested people.
2. Sketch. The common language, the thing that everyone gathers around, should no longer be spec documents but sketches. They can become the initial artifacts that spark discussion and create a shared understanding. And because they are easy to make, no-one is too invested in their own ideas, and they can be easily thrown way.
3. Prototype. In line with the Lean Start-up concept, prototypes are seen as a great way to create validated learning. Due to their interactive nature they allow for easy validation, and quick iteration.
4. Pair up. Cross-functional pairing is another pillar to the method. When designers work directly with developers they both start out with a shared understanding of the problem. Developers can start working on the things that are hard for them, whilst designers can focus on the more complex interaction challenges. Pairing creates mutual trust and deeper investment. Jeff mentioned using firebug as a tool that allows developers and designers to work together in an agile way.
5. Style guides. In order to live without massive specs, some documentation cannot be avoided. Jeff opted for the idea of a living, breathing style guide, that allows developers to quickly look up which style comes with ‘main call to action’ and designers to check if there are existing code patterns that could be reused.
Jeff continued by dealing with some of the critiques and challenges of the Lean UX approach. In order for it to work we need to get rid of this idea that designers should get it right the first time and it should be the designers and not the spec document who are in control. To create buy-in and shared understanding it’s important that everything is open and visible. For people who are used to working towards a certain amount of perfection in their deliverables the Lean method will at first feel a little uncomfortable, but as Jeff stated, how can you aim to make the best product when you don’t know if you are working on the right product? It’s successfully solving problems and creating value for our clients (and users) that should be our focus and not the creation of beautiful deliverables.
Q&A and Discussion
The second part of the evening was a panel discussion with Johanna Kollman, Leisa Reichelt, Jeff Gothelf, James O’Brien and Mark Plant, and Jonty Sharples as the host. Based on questions from the audience, they discussed how it’s possible that while everyone agrees with the premises of Lean/Agile –less waste, shared understanding, focus on the end results– a more lean way of working still seems to be far from common practice.
Several reasons were discussed.
Economical: many of the larger agencies are actually in the deliverables business and get good money for delivering wireframe decks. Also there’s an initial cost of changing to a new method. This might only change after clients themselves become more agile too; to achieve this, Johanna argues, there need to be internal stakeholders or embedded teams.
Trust: to become more agile people have to trust each other, Leisa argues that it’s almost impossible to do Agile in a situation with 3th party developers. If you haven’t build up a relationship with your client they will most likely go with a competitor who claims they can deliver on a fixed deadline and fixed budget, and will see your agile approach as too risky.
Technical: creating a living and breathing wiki style guide takes time and effort. How do you integrate such a thing in your organisation? Jeff suggests choosing someone as the owner of the wiki, and if it also includes code snippets, to co-own it with development and have a dev-owner too. James argues that instead of using a wiki, patterns should be printed out on the wall, and a css-preprocessing language can be used to store all the default styles.
Social: getting agile to work means spending more time talking and explaining things to colleagues, not everyone is up for that. Also here it is possible to start small, make some of your process or some of your team more agile, and let everyone slowly get used to shared responsibility and shared ownership.
Experience: no-one would argue getting agile to work is easy, it’s best done by people who know a rich set of tools and methods to adjust their process to the problem (and not the other way around). Mark argues that it’s impossible to force people into an agile way of working, they must want to work that way, and Johanna wonders if mentoring and show’n’tell is a good way to distribute Agile knowledge.
Psychological: Agile can be a painful process for perfectionists. Visual designers in particular protest against losing their time and ability to do large pixel-perfect design upfront. James argues that the agile process forgets quiet places and time for reflection. Developers have refactoring time, where they clean up old code, and designers should claim this time for themselves too. Another element that Jeff brought up is that designers are used to being applauded for the beauty they bring into the world. Agile, and its focus on the end product, however, has no room for individual heroes and only works well as a team sport.
Somewhere towards the end, Leisa wonders if we’re just finding endless new ways – Agile, Lean UX, goal directed design – to rename what should be known as good design? And this sentiment also resonates with others, was this evening just another version of our yearly agile versus waterfall debate or is there something new under the sun? What is certain though, is that we are moving towards a more complex and uncertain future, and that we need all the ideas we can get to stay in control of our technology. This evening at the Sense loft was therefore an evening well spent.
Prize-winner and starchitect-in-denial, Rem Koolhaas and his studio OMA have created a method and practice that is uniquely capable of dealing with an ever more complex world. Interested in what this could mean for digital designers I started digging into their design process, in this article I’ll discuss my findings.
When asked once what his goal with his practice was, Koolhaas answered: “to keep thinking about what architecture could be. What I could be.”¹ And it is this ‘could be’ that plays a defining role in Koolhaas’ career.
Rem Koolhaas studied scriptwriting and architecture and is heading OMA/AMO, an office he co-founded in 1975. You might know him from his books Delirious New York or S, M, L, XL and his practice from the CCTV HQ, Casa da Música in Porto or the Central Library in Seattle.
It is not easy to define Koolhaas. Although his buildings can be found all over the world, it’s hard to recognise a typical Koolhaas building by visual appearance alone. To define Koolhaas you have to move to his realm, leave the world of bricks and steel, and enter the world of images, models and processes, a world of ideas. Not what is, but what could be.
His buildings and his books do, however, have something that makes them recognisable as a product from OMA. A product that is very much influenced by the process of creation, a bottom up, labour-intensive, research-lead way of questioning everything. His products are assemblies, where Koolhaas refuses to give any easy answers, and instead reveals a selection of evidence and demands from spectators to form their own interpretations.
Koolhaas’s greatest achievement is therefore not a building or book, but a system that is capable of harvesting, questioning and producing ideas. What Koolhaas has built is a very large version of himself, a system that, through a method of researching and building, is capable of reliably creating beautiful and intelligent ideas on how the world could be. In this article I want to discuss the system that Koolhaas has built to get in that position and how he manages to remain at the forefront.