The UXD practice at MerryFools is something in which every team member has an active role and voice. We are constantly questioning our methodologies, refining our techniques, and evolving the practice to support and enhance our product development. I want to share how our team is leveraging user-experience design practices in our iterative/agile product design and development practice.

In the majority of my reading and research on UX Design practices I’ve spotted a pattern of an established workflow, where the conventional advice goes something like this:

  • Gather the Project Requirements / Research Audience

  • Synthesize, Ideate, and Sketch

  • Build Wireframes / Revise Wireframes

  • Design the UI and the Interactions

  • Code the Application or Website

  • Celebrate Your Awesome Success

Simpflied UX waterall diagram

Oversimplified, sure, but the point I’m hoping to make is that such a linear – or waterfall – approach to our process is not realistic. I’ve never seen a development team wait around until all the UI designs were perfect, nor have I ever witnessed a design team patiently wait until all the wireframes and flows were built and approved.
Doubly so for MerryFools – we’re too fast and rather impatient. We like to build stuff.

So, here’s how the UX, Interaction, Visual, and Application design and development is happening for our current project, which can be broadly described as follows:

  1. A distributable desktop application built on Adobe Flash technology

  2. This desktop app is highly customizable through an account-based web application (you author the application!)

  3. Having a well-designed, usable, and highly functional public-facing and account/configuration site

That doesn’t sound like a lot until you consider that we’re building a web site that also is a database-driven web application that allows you to configure and compile a desktop application that you can distribute yourself. You can even have us do the hosting too. Whew!

In the project I just described, there are a lot of moving parts. There are a lot of complicated use cases. Plus, we value simple and easy-to-use a whole lot.

The thing is, development has already begun. Design has already begun. At the time of this writing, the team is entering into the third project sprint. And the UXD “phase” isn’t finished, not by a long shot. And that’s OK, because it’s not a phase, but an ongoing aspect of the overall process.

Working from the inside-out, we’ve already begun establishing the database model, and the basic authentication and configuration tools within the web app. The desktop application and other flash-based tools are also well under way. The user-experience design is both guiding this development and simultaneously being informed-by and revised as development progresses. How? Through team communication and a willingness to accept the UX process is a parallel part of the overall iterative/agile process. We revise artifacts and deliverables with the same spirit as the developer who refactors and refines code and as the visual designer who iterates through the details of the designs.

Our current UX process goes something more like this, and so far it’s working pretty well:

UX_our_way

 

There is something interesting to note – development begins (slightly) ahead of the visual design stuff, and rightly so. The UX documents show us what we’re building, but a wireframe or a process flow can’t reveal the same user experience or data model insights that a real live interaction can. So, we sketch, wireframe, declare that chunk good idea of what, and then build it quickly. Then test, learn, update wires, talk about flows, maybe revise code, and then repeat.

Once enough of the “what” we’re building takes shape, then we have something upon which to explore visual designs. And we’ll iterate on those, too. A lot.