The UX Shop: A UX-Friendly Development Process
Or how a designer and a developer can enjoy working together
I like to work when it rains. There’s something soothing about the tingling noise the water makes when it falls on the window. Wait! That’s not the point of this article… Last month, Cyril Schmitt introduced The UX Shop. How an idea became a tangible product. Today, I’ll formalise the way we injected UX into our development process: you’ll learn how a UX designer and a software engineer can work together in perfect harmony.
The UX Shop is a two-person project. We both work within the same city, but not in the same place. Because of that, we had to rely on tools to organise ourselves and to communicate effectively. Like most of the projects we do together, it started-out with a basecamp and a bunch of todos.
The creation process spanned over two distinct phases with different objectives and tools. Let’s call them the Vision Phase and the Development Phase. They use an agile-y tailored methodology that emerged as the project went along. Let’s explore it! Hopefully you’ll find interesting tidbits for your own projects. Ready? Go!
The Vision Phase
Otherwise known as ‘The Beer Phase.’ Because it’s best carried out around beers. You could also substitute it with tea I guess, albeit that’s less fun. That phase started the moment Cyril woke-up with the idea. The goal is two-folded: generate ideas and create excitement. The output (or artefact) is an initial set of mockups that I’ll call the Mockup-Backlog. More on that later. For now, let’s look at what happen during the Beer… sorry, Vision phase:
- We translate an idea from a thought to words
- We think about how it could look, or work
- We try to identify initial pain-points
- We sit together and talk while Cyril (the UX designer) sketches wireframes as the discussion goes forward
While looking back, it was important for this phase to be done together, because it created a common understanding of where we wanted to go; a shared vision.
After reporting the discussion we had on our basecamp, we created a slack, a project on invision, and started working on the initial mockups.
After a few exchanges over the initial sketches, we were both satisfied with what we had. Cyril used them to create our Mockup-Backlog: a lively repository of mockups that reflect the current version of our product. They live on invision and are browsable; Just like a prototype.
Now let’s move on to the Development Phase, where we bring it to life through some black magic sorcery.
Take away: Initial mockups are going to change as the project progresses. That’s why it’s important not to spend too much time on the details. Their primary purpose is to allow communication. Also, in our case, it was enough to only design the desktop version of the mockups because of the ‘refinement’ activity. Just dropping the teaser. It’s coming in the next section.
The Development Phase
Having a Mockup-Backlog let us visually scan what needs to be done. Extracting an actual Product Backlog (a list of user-stories) was a piece of cake. We used trello to create a board with three columns: Backlog, In Progress and Done. We hooked-up trello on slack using that awesome integration, And we were all set!
Now let’s look at the process. It has two activities: implementing a user-story and Integration Reviews. We didn’t think about this process before-hand. It emerged naturally. Due to the very nature of UX design, it had to be agile, iterative and consider the connection between parts. Without going deep in technical details, here’s a peek of how these two activities were carried.
Implementing a user-story
We define a user-story as a unit of work that adds value from the user’s perspective. It needs to be visually testable. It might be broken down into tasks. Here’s the process:
- Verify all the details are available, question the very purpose of the story.
- develop it, so that the whole user-story is testable: it goes from mobile version to the desktop one, and to the API Server. Then test it.
- Deploy it: It should be testable online. Remember, we didn’t work in the same office. I used another Slack integration that let us know whenever a new version of the app was online.
- Refine: we adjust the result so that we’re happy with it.
The two take-aways here are the deploy and refine steps. Informing everybody that a user-story is testable makes it easier to detect potential bugs early on, but also let people play with it. It allows refinement: another cycle of UX and development to improve the task.
After a few development cycles, we would meet for an Integration Review. A sort of acceptance test on steroids. We fire-up the app and fix each and every pixel that is off (using Linear), and decide if we are satisfied with the overall experience. Think of it as the holistic part of the process, the one that focuses on the connection between each parts.
The hub a.k.a center of operation
Using the right tools played a big part in orchestrating this workflow. We relied on specialized services such as invision; made use of trello’s board for managing our backlog but also github for the actual repository. We also exchanged lots of files, from tiny screenshots to entire documents. We couldn’t afford keeping track of all the different places individually.
That’s why slack became our center of operation. By using integration together with topic channels, we could stay organized all the way. The first integration we plugged was for invision. The other followed quickly. This was a big win. When looking for any information, we search in one place. It aggregates all the different services. Awesome, right?
The In-Betweens
As I’m writing these lines, trying to formalise the methodology we used, something becomes clear. It feels like I’m writing a program, describing a routine to be executed that’ll output The UX Shop. That’s not what happened. A lot of the things happened between the lines. So let me formalise those with a bullet point list: … just kidding. ;-)
What’s between the lines is a set of beliefs and values that we live by when we work, and also as human beings. It would probably be too hard to name them all, but communication is key. Taking the time to listen, and being positive. The goal is always to bring the best out of the product, so being open-minded surely helps.
There is no substitute for communication. That was the point of the whole tool-chain we used. By the way, I forgot to mention Google Hangout, for your daily dose of screen-sharing.
Now that The UX Shop is out, a whole new phase starts. It brings with it an exciting new set of activities: getting traction, analysing people’s behaviour, community management, interviewing and much more. Yet we learned a lot while building it. I hope this article will let you question your own process: is it holistic? does it promote communication? Small changes can go a long way!
So where are we now?
Let’s take a peek at where we are now, and where we want to go.
- 10k+ visits, bounce rate 7% (yes, we are proud of that!)
- Christmas was definitely a factor to last month’s sales result. It seems like Valentine’s day doesn’t boost UX sales much.
- We conquered Google Analytics and released our fully A/B tested newsletter: UX Empathy
- Site Of The Day on CSSWinners, Featured on One Page Awards
- Store approved on Amazon.com!
- Interview of Jeff Gothelf, author of Lean UX, and our two next influencers
March’s goals
- Ongoing efforts to sharpen our KPI and find our best traction strategies
- Grow our Twitter community (You, yes YOU! Follow us right there ;))
- Now that we have more realistic sales data, work to increase them
- Streamline our interview process, and interview more interesting designers
Wanna have a look at our project? Please visit http://theuxshop.com
Handpicked resources for/by digital designers
Interviews of people who care about users
Follow us: @theuxshop
If you want to give us a virtual hug, your can 💚 recommend this article and follow our stories on the One Side Project Challenge publication.We will be giving project updates on the 2nd of every month.
