Experience Design project with Hatch – Case study

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.