My View on “Lean UX” with Small Resources in Projects
I’ve been working in some smallish projects as a half-time UX-designer, usually with one team (most of the time an average of 3 developers doing both front and backend) and thought It would be helpful to open up a bit on the ways we have found most useful to use my limited time in the projects.
Our projects are usually run in two week sprints. At the beginning of the sprint we plan both the development tasks and the UX-tasks, they run on the same board and are visible to the whole team and project members.
In a small team with limited resources it’s usually important for the UX-designer to be able to wear multiple hats. We simply don’t have a person for user research and testing, interaction design, visual design, prototyping, etc. So it’s necessary to be able to do most of these things yourself – at a pretty advanced level.
This also needs a team that is constantly available for communication and sparring – ideally everyone sits on the same room to minimize distance. The team members must be interested in being involved in all aspects of the process and share the same simple goal to make the product as good as possible, giving whatever it takes and contributing to the shared goal instead of each one just contributing to their own ”part”. It also helps to have varied skills and interests inside the team, that skill and interest-knowledge will be shared with other people during the process when everything is done together.
The Sprint
We have a pretty good understanding of how much I can deliver in a sprint, so we usually try to get 2-4 UI/visual design tasks. 2-5 user testing tasks and bunch of smaller tasks for me per two week sprint. There is always at least one day worth of planning and communicating and one day of general maintenance, bug fixes and visual fixes to do. So with 50 % work time that leaves you with about 3-4 full days per sprint to do the actually design and testing work. Use-that-time-well.
The Work
The work from sprint to sprint varies a lot depending of what we are doing. The tasks that are in the sprint have typically been validated and researched to a large degree to be at this stage. Most UX-tasks are brought to the sprints by the product owner, who keeps track of the bigger picture and prioritizes what the team should be working on next. The UX-tasks are typically one sprint ahead of the development tasks to leave enough room to do the design and testing. Here’s a rundown how a task runs through “the machine”:
1) Sprint Planning
Go over the design task at hand with the whole team and product owner, break it up to smaller pieces if possible.
Goal: Discuss about the task at hand from all viewpoints and try to find questions and problems or better solutions as a whole team.
2) Concept Design / Wire-framing
Usually I’ll draw the task using pen and paper together with a developer, the product owner, a user or with specialist on the subject, I’ll mark all questions that arise in a separate “parking lot” and get to those at a later time.
Goal: to draw the whole task from beginning to end from the eyes of the user trying to accomplish the task at hand.
3) Test the Task
Our product owner usually has actual users for me to test the tasks and i’ll try to arrange 2-3 tests that take from half an hour to an hour, I use actual users on the tasks and people from the team/company to do simple UI-tasks that don’t necessary need an actual user. We use a common sense approach to user testing with limited time used on documentation of the results and presenting them to people. Instead we test and immediately do changes to the task at hand and continue the testing cycle couple of times and end up with a rough design that has been user tested. The most important thing is to polish the design, get out of “guessing” the design and get feedback <-> design <-> development cycle as small as possible without the overhead of the normal cycle (design › test › document › present › fix and redesign › test › document › present › ) to ( design › test › fix and redesign › test › fix and redesign)
Goal: Get real user feedback on the task, fix possible problems immediately and get the task validated
4) Design and Deliver
I try to design and deliver as much as possible with the paper prototype or a simple Balsamiq mockup – yes – our developers accept low fidelity paper prototypes as we can communicate most of the visuals by talking it over. (Most of the UI-library should be in advanced stage and ”bigger” visual styles done already) Most of the responsiveness and stuff are better off explained and tried out – instead of using the – again – limited time at designing pixel perfect images
If there is some new visuals to do, I usually use either prototyping in the browser using developer tools on small stuff, or occasionally i design from pretty much scratch. Most of the visuals are done in Illustrator and at advanced stage of projects you don’t really need to do that much visual design.
Goal: Get the task “done” for the development to start and to be completed as fast as possible.
5) Down Time – As in Stuff not Doing the Above ^
Fix bugs and visuals on the project, install developer tools and get your hands dirty, use all down time to fix stuff instead of telling people that needs to be fixed
Goal: Free developer time for more advanced and bigger tasks
What Does This All Mean for the Designer – Skill-wise?
To be successful in surroundings and projects like these, try to get into multiple areas of “ux-design” – the most important thing is to get yourself into developing, user testing and research. Start by doing Codeacademy courses (HTML+CSS+JS) and forcing yourself to do as much of your stuff in the browser ( and get into development. No one expects (or should expect)) you to be as good as the hardcore frontend guys (there’s a reason they are in the project) but try to get out of simply handing over projects and work, instead get into projects that require constant communication, sitting with developers and no deliverables.
Carry out testing and designing with real users, other members of the team and the product owner as early as possible. There is no need for the “lone designer” in modern agile software projects.
“Lean UX” in Nutshell
Pros:
+ Time feels well spent, instead of presenting and documenting stuff, you are fixing and making stuff.
+ You learn a lot by getting your hands dirty and doing a lot of stuff (try to be out of your comfort zone 90 % of the time :)
+ You meet and design with real users, get the feedback and do the corrections and fixes yourself instead of someone else.
+ With developer tools its great to fix stuff yourself instead of depending on others and you get a real idea of how things are built that you can use in the design part.
Cons:
– Doing the developing aspect for me is sometimes hard and you feel a bit lost as it is not your main expertise, but it helps to have good team members that are willing to help.
– Content switching when moving fast.
– Sometimes you lose the big picture when working in small increments.
